Comments 116
а чем он сейчас собирается?
+2
MSVC 2008, вероятно.
+3
судя по логу — 2005.
+4
а в чём сложность перехода на сборку под 2010?
+1
незаметно могут всплыть баги оптимизатора
+11
100500 ошибок из-за разности компиляторов
+28
Однажды перешли на 2010 на середине проекта. После месяца исправления багов очень радовались, что можем вернуться к работе по проекту без еженедельных сказок и оправданий перед заказчиком.
+4
А какого типа и насколько крупный проект?
0
Интеграция нескольких систем, для чего пытались использовать сначала стандартные очереди, потом самописные реализации очереди. Также постигло большое разочарование с мылом, в результате чего мыльная часть была частично написана без библиотек типа net.mail, а частично с ними. Вобщем-то использовали, если ничего не перепутал, только smtp отсылку из этой библиотеки, остальное самостоятельно реализовавали, и долго правили из-за этого.
0
Лет через 10-20 для тех-же операций не будет хватать миллионов терабайт памяти.
-23
> миллионов терабайт
эксабайтов
эксабайтов
+22
тысяча тысяч тысяч тысяч тысяч тысяч байт!
+1
Тысяча двадцать четыре тысячи двадцати четырёх тысячи двадцати четырёх тысячи двадцати четырёх тысячи двадцати четырёх тысячи двадцати четырёх байтов.
+21
Вообще-то не совсем правильно, т.к. Гигабайт это 10^9 байт, а не 2^30.
Ну и все последующие после гигабайта это степени основания 10, а не основания 2.
Хотя та же википедия говорит о разночтении начиная с мегабайта.
В сущности это всего-лишь несоответсвите терминологии ГОСТа, по которым производят и маркируют накопители. Единицы измерения информации
Ну и все последующие после гигабайта это степени основания 10, а не основания 2.
Хотя та же википедия говорит о разночтении начиная с мегабайта.
В сущности это всего-лишь несоответсвите терминологии ГОСТа, по которым производят и маркируют накопители. Единицы измерения информации
-4
Оперативная память измеряется в степенях двойки.
+1
В этом самом ГОСТе 8.417-2002 написано следующее: «Исторически сложилась такая ситуация, что с наименованием „байт“ некорректно… использовали (и используют) приставки СИ: 1 Кбайт = 1024 байт, 1 Мбайт = 1024 Кбайт, 1 Гбайт = 1024 Мбайт и т.д. При этом обозначение Кбайт начинают с прописной буквы в отличие от строчной буквы „к“ для обозначения множителя 10^3». Хотя да, особые педанты могут продолжать настаивать на мебибайтах, гибибайтах и прочих причудливых словах.
0
Надо же было столько понаписать…
+38
прямо как компиляция сетевых библиотек буста (Boost) там влегкую за пределы памяти можно выйти на 32 битах)))
+3
В современных браузерах строк исходного кода больше, чем в ядрах современных ОС…
+8
Современные браузеры стремительно становятся современными ОС.
+64
UFO just landed and posted this here
А что не так с переходом на х64 платформу?
+1
Нарвеное чтобы проверить скомпиленное нужно будет переходить в 32-битную ОС.
-1
даже у x64 msvc линкер 32х битный. а проблема как раз в нем
+2
Судя по одному из предложенных вариантов «перейти на MSVS 2010» — там линкер уже 64х битный?
0
Во первых линкер есть и такой и такой. Во вторых, они уперлись в предел 3Гб адресного пространства, а wow64 процессам (32-битные процессы на 64-битной системе) отдаются вообще все 4Гб адресного пространства (если бинарник говорит о том, что он согласен с тем, что старший бит в указателях может быть ненулевым — а link.exe имеет поддержку больших адресных пространств испокон веков — собственно это тот же флаг, который включает поддерку /3GB для процесса). В общем на полгодика б хватило — а там все равно весь девелопмент переводить на x64. Хоть так хоть эдак. Ну или отключать PGO
+1
Нет, эт все понятно — не хотят переводить билдеры на x64 и там кросс-компилить. Но как тогда быть с этим утверждением? Или оно ошибочно?
>> Microsoft is not going to provide us with a 64-bit linker in any reasonable timeframe. We cannot switch wholesale to any other linker because we need the optimizations (including PGO) in Microsoft's.
Так и так линкер упрется в 4Гб адресного пр-ва на PGO.
>> Microsoft is not going to provide us with a 64-bit linker in any reasonable timeframe. We cannot switch wholesale to any other linker because we need the optimizations (including PGO) in Microsoft's.
Так и так линкер упрется в 4Гб адресного пр-ва на PGO.
0
Это откуда цитатка (интересно посмотреть на уровень неадеквата)?
Вот это из VS2010 (есть подозрения, что и в более старых версиях все так же, но проверить мне сейчас негде — старых версий нигде не осталось)
Ну и на всякий случай, вот так выглядят загруженный в этот процесс модули:
Вот это из VS2010 (есть подозрения, что и в более старых версиях все так же, но проверить мне сейчас негде — старых версий нигде не осталось)
Ну и на всякий случай, вот так выглядят загруженный в этот процесс модули:
+1
Так дело в кросскомпиляторе. Им все равно, нужно собирать бинарники для x86, но с помощью линкера и компилятора, которые сами работают на x64. (Кстати, линкер вызывает компилятор для некоторых задач в режиме PGO, так что нужны обе вещи). Microsoft сейчас такую возможность не предоставляет.
+1
Да, я действительно не подумал, что для LTCG нужен бекэнд компилятора, а для генерации x86 кода он есть только в x86 варианте. Ну в таком случае им нужно серьезно подумать о рефакторинге одного монолитного бинарника в несколько более меликих.
Ну или попрофайлить и выяснить где получается наибольший выигрыш от PGO (наиболее «горячие» участки кода) и оптимизировать только эти места, а не все подряд.
Ну или попрофайлить и выяснить где получается наибольший выигрыш от PGO (наиболее «горячие» участки кода) и оптимизировать только эти места, а не все подряд.
0
Прошу прощения за оффтоп, но что это за программа, скрин которой был представлен?
0
Это Process Hacker. По большей части дублирует функционал Process Explorer Руссиновича, но в некоторых вещах превосходит его.
0
> Так и так линкер упрется в 4Гб адресного пр-ва на PGO.
Пока что он уперся в 3Гб, а в прошлый раз (начало 2010) — в 2Гб. Так что один дополнительный гиг доступных адресов дал бы им возможность оставаться в прошлом еще год-два.
Пока что он уперся в 3Гб, а в прошлый раз (начало 2010) — в 2Гб. Так что один дополнительный гиг доступных адресов дал бы им возможность оставаться в прошлом еще год-два.
0
А я рад что и разработчики тоже испытывают сложности связанные с потреблением памяти их поделки.
+112
А какая связь с потреблением памяти самим firefox???
+2
Как связаны потребление памяти линкером при использовании PGO и потребление памяти самим Firefox?
+7
Отвечаю всем, связь такая что это рыжее чучело, после для работы (все вкладки закрыты), может кушать 1.5 Гб. Так вот, я рад что у разработчиков лисы тоже есть проблемы с памятью, мне пофиг какого они характера проблемы, но так они лучше поймут пользователей.
PS все равно его люблю )
PS все равно его люблю )
+19
… дня работы…
0
Разработчики выкрутятся, Вы даже не сомневайтесь — и тот метод, которым они выкрутятся (будет ли это разбивка на модули или компиляция под х64) нифига не поможет конечному пользователю с его проблемами потребления памяти браузером.
+4
UpTime рыжего чучела 8 версии порядка полутора недель, открыто в среднем около 20 вкладок в трёх группах вкладок, кушает 400 метров с фаербагом и адблоком, может проблема не в самом чучеле-то?
0
Используете ли вы в разработке что-то подобное ExtJS, например? :)
+1
Нет, я бэкэндщик по большей части, а что там с ExtJS? Из-за него хромает только лиса?
0
firebug при активной работе с ExtJS показывает чудеса текучести памяти. того и гляди сам firebug за пределы памяти вылезет)
+1
Ну вот, один серьёзный и огненный баг в огненной лисе нашёлся, осталось быстренько пофиксать его! :)
0
А если добавить сюда Illuminations, то становится все чудесатие и чудесатие. Хотя, если честно, в последее время лиса ведет себя лучше. :)
0
Так может всё-таки firebug течёт, а не firefox?
+1
Зайдите на сайт с детскими играми — как делает каждый день мой трёхлетний сын — и будет гигабайт минимум. Вроде всего-то простенькая аппликация, а память летит только так.
+1
Игры же на Flash скорее всего?
+1
да, но памяти тем более течь не должно.
0
Как будто во флеше не может быть утечек, особенно если писано индусами.
+1
Мне казалось, что после закрытия странички с флэшем утечка памяти, вызванная флэш плагином, должна пропадать. Не пропадает же. Значит не индусы виноваты, как Вы думаете?
0
about:memory посмотрите сначала. И сколько ест plugin-container в процессах. Если вы флешку закрыли — это не значит, что там по волшебству вся память осободилась.
0
Если вы флешку закрыли — это не значит, что там по волшебству вся память осободилась.
А куда же она девается-то, если не освободилась? Зачем лиса её держит, как сыр?
А куда же она девается-то, если не освободилась? Зачем лиса её держит, как сыр?
-1
Всё что угодно может быть. Начиная сборщиком мусора (который и у флеша тоже есть) и заканчивая невозможностью освободить участок памяти (хотя последнее скорее выдаст run-time error).
+1
Учитывая, что FireFox ориентируется на плагины сторонних разработчиков, он должен сам следить за тем, чтобы эти плагины хотя бы после прекращения работы не потребляли память. Раз не следит — это вина разработчиков FireFox. Тут можно спорить только если поставить целью во что бы то ни стало продвигать тезис о непогрешимости FireFox.
0
Смеётесь что ли? Это как если бы вы просили Microsoft следить за всеми программами сторонних разработчиков для Windows.
0
Рыжее чучело Iceweasel 3.6.24, полсотни вкладок, четыреста мегабайт. Временами доползает до пятисот-шестисот. Аптаймы многодневные, а то и многонедельные.
0
У меня хром с ~20-25 вкладками ноут с 6 гигами памяти в своп уводит иногда :(
Так что далеко не только у лисы проблемы.
Так что далеко не только у лисы проблемы.
+1
Да ладно бы, пусть кушает хоть два гигабайта, но пусть не тормозит «за эту цену»!
Тормоза Firefox вымораживают гораздо больше, чем потребление памяти.
Тормоза Firefox вымораживают гораздо больше, чем потребление памяти.
+1
Не хочется разводить холивар, Firefox отличный браузер, и навсегда останется в памяти, но лично мне больше по душе Chrome, и основной причиной перехода (причем почему-то довольно сложного для меня было), это именно из-за того, что он на маке сильно долго грузился (да и не только на маке).
-19
При чем тут вообще Chrome и Mac, когда речь идет о проблемах компиляции?
+17
>Firefox отличный браузер, и навсегда останется в памяти
Звучит угрожающе.
Звучит угрожающе.
+75
Не хочу показаться «хромоебом», но вроде как по последним данным он сдает позиции Chrome, да и если Google откажет Firefox-у в материальной поддержке, тоже не сильно весело будет для Mozilla Foundation.
Хотя если вы имеете ввиду что он на текущий момент зависает в памяти надолго, то тогда да — звучит более угрожающе, грозит перезагрузкой. :)
Хотя если вы имеете ввиду что он на текущий момент зависает в памяти надолго, то тогда да — звучит более угрожающе, грозит перезагрузкой. :)
-7
Звучит похоже на сообщение Windows ;-)
+5
новая услуга: очистка памяти от сторонних программ.
0
> навсегда останется в памяти
Если памяти хватит =)
(извините не удержался)
Если памяти хватит =)
(извините не удержался)
+22
Может я чего-то не понимаю, но по-моему самый идеальный вариант на сегодняшний день — разбить части кода на библиотеки. Это и оптимальней, и время компиляции сократится (не придётся компилировать лишний раз то, что уже скомпилировано), и отладка проще.
0
0
«Firefox не вмещается в 32-битное адресное пространство»
Может всё-таки, компилятор Firefox не вмещается? У самого продукта с памятью пока запас есть.
Да и (3) решение выглядит слишком очевидным. В-общем, моё субъективное мнение: проблема не стоит даже того, чтобы в баг-лист добавлять.
Может всё-таки, компилятор Firefox не вмещается? У самого продукта с памятью пока запас есть.
Да и (3) решение выглядит слишком очевидным. В-общем, моё субъективное мнение: проблема не стоит даже того, чтобы в баг-лист добавлять.
+10
PAE и серверная версия виндовса для компиляции?
Вобще, у проблемы масса решений, и она скорее не является чем-либо серезным, а просто забавным случаем.
Вобще, у проблемы масса решений, и она скорее не является чем-либо серезным, а просто забавным случаем.
0
Заголовки ализара не вмещаются в здравый смысл.
+22
Вот то что SPDY выпилили это фигово. Интересно было бы повозиться
0
растолстел окончательно.
0
Сенсация!
+1
Не вмещается линковщик, а не сам Firefox, расходимся!
+40
А почему 3 ГБ в Win32? Я бы сказал 4 (2^32) минус выделенное пространство под устройства, ресурсы етц.
0
Кто будет жрать дофига оперативы, получит по наглой рыжей морде.
0
Sign up to leave a comment.
Firefox не вмещается в 32-битное адресное пространство