Pull to refresh

Comments 116

а в чём сложность перехода на сборку под 2010?
незаметно могут всплыть баги оптимизатора
100500 ошибок из-за разности компиляторов
Однажды перешли на 2010 на середине проекта. После месяца исправления багов очень радовались, что можем вернуться к работе по проекту без еженедельных сказок и оправданий перед заказчиком.
А какого типа и насколько крупный проект?
Интеграция нескольких систем, для чего пытались использовать сначала стандартные очереди, потом самописные реализации очереди. Также постигло большое разочарование с мылом, в результате чего мыльная часть была частично написана без библиотек типа net.mail, а частично с ними. Вобщем-то использовали, если ничего не перепутал, только smtp отсылку из этой библиотеки, остальное самостоятельно реализовавали, и долго правили из-за этого.
А почему не допилили существующие решения?
Именно что допилили, но это заняло время.
Лет через 10-20 для тех-же операций не будет хватать миллионов терабайт памяти.
> миллионов терабайт
эксабайтов
тысяча тысяч тысяч тысяч тысяч тысяч байт!
Тысяча двадцать четыре тысячи двадцати четырёх тысячи двадцати четырёх тысячи двадцати четырёх тысячи двадцати четырёх тысячи двадцати четырёх байтов.
Вообще-то не совсем правильно, т.к. Гигабайт это 10^9 байт, а не 2^30.
Ну и все последующие после гигабайта это степени основания 10, а не основания 2.

Хотя та же википедия говорит о разночтении начиная с мегабайта.
В сущности это всего-лишь несоответсвите терминологии ГОСТа, по которым производят и маркируют накопители. Единицы измерения информации
Оперативная память измеряется в степенях двойки.
Именно потому эксабайт неравен тому, что вы написали.
В этом самом ГОСТе 8.417-2002 написано следующее: «Исторически сложилась такая ситуация, что с наименованием „байт“ некорректно… использовали (и используют) приставки СИ: 1 Кбайт = 1024 байт, 1 Мбайт = 1024 Кбайт, 1 Гбайт = 1024 Мбайт и т.д. При этом обозначение Кбайт начинают с прописной буквы в отличие от строчной буквы „к“ для обозначения множителя 10^3». Хотя да, особые педанты могут продолжать настаивать на мебибайтах, гибибайтах и прочих причудливых словах.
Как бы то ни было, Мегабайт не равен Мбайту. Тут или математика или слэнг, выбирайте сами.
Это не обязательно написанный руками код. Что-то может генерироваться автоматически, что-то — результат инстанцирования шаблонов в C++.
прямо как компиляция сетевых библиотек буста (Boost) там влегкую за пределы памяти можно выйти на 32 битах)))
В современных браузерах строк исходного кода больше, чем в ядрах современных ОС…
Современные браузеры стремительно становятся современными ОС.
UFO just landed and posted this here
Интеграции с браузерами, для обеспечения максимально комфортного симбиоза?)
Похоже скоро стоит ждать первенца как результат этого симбиоза )
И действительно, правда есть мнение что он какой-то недоношенный получился.
Я ставил, да сыроват, а если запускать не с харда, а с флэшки, так еще и тормозит ужасно. Как говорят, первый блин комом.
Кто-то на Микрософт за это в свое время в суд подавал. А они оказывается все заранее предвидили!
К любви и гармонии
А что не так с переходом на х64 платформу?
Нарвеное чтобы проверить скомпиленное нужно будет переходить в 32-битную ОС.
Я думаю в мозилле не дураки сидят, и у них в виртуалках целый зоопарк ОС.

Правда с Mozilla 3.0 у них вышел былинный отказ. Самая первая 3.0 версия не хотела стартовать на Win7 x64.
даже у x64 msvc линкер 32х битный. а проблема как раз в нем
Судя по одному из предложенных вариантов «перейти на MSVS 2010» — там линкер уже 64х битный?
Нет, просто он чуть бережнее обращается с памятью.
Во первых линкер есть и такой и такой. Во вторых, они уперлись в предел 3Гб адресного пространства, а wow64 процессам (32-битные процессы на 64-битной системе) отдаются вообще все 4Гб адресного пространства (если бинарник говорит о том, что он согласен с тем, что старший бит в указателях может быть ненулевым — а link.exe имеет поддержку больших адресных пространств испокон веков — собственно это тот же флаг, который включает поддерку /3GB для процесса). В общем на полгодика б хватило — а там все равно весь девелопмент переводить на x64. Хоть так хоть эдак. Ну или отключать PGO
Нет, эт все понятно — не хотят переводить билдеры на 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.
Это откуда цитатка (интересно посмотреть на уровень неадеквата)?
Вот это из VS2010 (есть подозрения, что и в более старых версиях все так же, но проверить мне сейчас негде — старых версий нигде не осталось)


Ну и на всякий случай, вот так выглядят загруженный в этот процесс модули:

Так дело в кросскомпиляторе. Им все равно, нужно собирать бинарники для x86, но с помощью линкера и компилятора, которые сами работают на x64. (Кстати, линкер вызывает компилятор для некоторых задач в режиме PGO, так что нужны обе вещи). Microsoft сейчас такую возможность не предоставляет.
Да, я действительно не подумал, что для LTCG нужен бекэнд компилятора, а для генерации x86 кода он есть только в x86 варианте. Ну в таком случае им нужно серьезно подумать о рефакторинге одного монолитного бинарника в несколько более меликих.

Ну или попрофайлить и выяснить где получается наибольший выигрыш от PGO (наиболее «горячие» участки кода) и оптимизировать только эти места, а не все подряд.
Прошу прощения за оффтоп, но что это за программа, скрин которой был представлен?
Это Process Hacker. По большей части дублирует функционал Process Explorer Руссиновича, но в некоторых вещах превосходит его.
> Так и так линкер упрется в 4Гб адресного пр-ва на PGO.
Пока что он уперся в 3Гб, а в прошлый раз (начало 2010) — в 2Гб. Так что один дополнительный гиг доступных адресов дал бы им возможность оставаться в прошлом еще год-два.
А я рад что и разработчики тоже испытывают сложности связанные с потреблением памяти их поделки.
А какая связь с потреблением памяти самим firefox???
и тот и тот едят много памяти
Это почти синонимы, к сожалению, но слышал что ведется работа в этом направлении, и осчастливить нас хотят уже через несколько месяцев (в 10й версии вроде как).
Как связаны потребление памяти линкером при использовании PGO и потребление памяти самим Firefox?
Это что-то вроде метафоры.
Отвечаю всем, связь такая что это рыжее чучело, после для работы (все вкладки закрыты), может кушать 1.5 Гб. Так вот, я рад что у разработчиков лисы тоже есть проблемы с памятью, мне пофиг какого они характера проблемы, но так они лучше поймут пользователей.

PS все равно его люблю )
Разработчики выкрутятся, Вы даже не сомневайтесь — и тот метод, которым они выкрутятся (будет ли это разбивка на модули или компиляция под х64) нифига не поможет конечному пользователю с его проблемами потребления памяти браузером.
Конечно выкрутятся, на то мы и разработчики :)
Просто сам факт того что им придется выкручиваться доставляет. Даже вспоминается недавняя проблема с госдолгом США, отложат еще раз (не проведут глубокий рефакторинг), всплывет снова через годик.
UpTime рыжего чучела 8 версии порядка полутора недель, открыто в среднем около 20 вкладок в трёх группах вкладок, кушает 400 метров с фаербагом и адблоком, может проблема не в самом чучеле-то?
Используете ли вы в разработке что-то подобное ExtJS, например? :)
Нет, я бэкэндщик по большей части, а что там с ExtJS? Из-за него хромает только лиса?
firebug при активной работе с ExtJS показывает чудеса текучести памяти. того и гляди сам firebug за пределы памяти вылезет)
Ну вот, один серьёзный и огненный баг в огненной лисе нашёлся, осталось быстренько пофиксать его! :)
А если добавить сюда Illuminations, то становится все чудесатие и чудесатие. Хотя, если честно, в последее время лиса ведет себя лучше. :)
Так может всё-таки firebug течёт, а не firefox?
Проверено, однозначно firebug. Но они тоже вроде исправляются. Совсем недавно научились очищать память при обновлении страницы, уже вперед.
Зайдите на сайт с детскими играми — как делает каждый день мой трёхлетний сын — и будет гигабайт минимум. Вроде всего-то простенькая аппликация, а память летит только так.
Игры же на Flash скорее всего?
да, но памяти тем более течь не должно.
Как будто во флеше не может быть утечек, особенно если писано индусами.
Мне казалось, что после закрытия странички с флэшем утечка памяти, вызванная флэш плагином, должна пропадать. Не пропадает же. Значит не индусы виноваты, как Вы думаете?
about:memory посмотрите сначала. И сколько ест plugin-container в процессах. Если вы флешку закрыли — это не значит, что там по волшебству вся память осободилась.
Если вы флешку закрыли — это не значит, что там по волшебству вся память осободилась.
А куда же она девается-то, если не освободилась? Зачем лиса её держит, как сыр?
Всё что угодно может быть. Начиная сборщиком мусора (который и у флеша тоже есть) и заканчивая невозможностью освободить участок памяти (хотя последнее скорее выдаст run-time error).
Учитывая, что FireFox ориентируется на плагины сторонних разработчиков, он должен сам следить за тем, чтобы эти плагины хотя бы после прекращения работы не потребляли память. Раз не следит — это вина разработчиков FireFox. Тут можно спорить только если поставить целью во что бы то ни стало продвигать тезис о непогрешимости FireFox.
Смеётесь что ли? Это как если бы вы просили Microsoft следить за всеми программами сторонних разработчиков для Windows.
Я Вас сейчас насмешу: Микрософт это и делает. И это делает любая операционная система, это её профильное занятие. Программа запустилась, нагадила в отведённой ей памяти, закончила работу — память вернулась в систему.
Рыжее чучело Iceweasel 3.6.24, полсотни вкладок, четыреста мегабайт. Временами доползает до пятисот-шестисот. Аптаймы многодневные, а то и многонедельные.
У меня хром с ~20-25 вкладками ноут с 6 гигами памяти в своп уводит иногда :(
Так что далеко не только у лисы проблемы.
Да ладно бы, пусть кушает хоть два гигабайта, но пусть не тормозит «за эту цену»!
Тормоза Firefox вымораживают гораздо больше, чем потребление памяти.
А может тормоза следствие того что его разжиревшее пузо по земле таскается )
Не хочется разводить холивар, Firefox отличный браузер, и навсегда останется в памяти, но лично мне больше по душе Chrome, и основной причиной перехода (причем почему-то довольно сложного для меня было), это именно из-за того, что он на маке сильно долго грузился (да и не только на маке).
При чем тут вообще Chrome и Mac, когда речь идет о проблемах компиляции?
>Firefox отличный браузер, и навсегда останется в памяти

Звучит угрожающе.
Не хочу показаться «хромоебом», но вроде как по последним данным он сдает позиции Chrome, да и если Google откажет Firefox-у в материальной поддержке, тоже не сильно весело будет для Mozilla Foundation.

Хотя если вы имеете ввиду что он на текущий момент зависает в памяти надолго, то тогда да — звучит более угрожающе, грозит перезагрузкой. :)
новая услуга: очистка памяти от сторонних программ.
> навсегда останется в памяти

Если памяти хватит =)

(извините не удержался)
Может я чего-то не понимаю, но по-моему самый идеальный вариант на сегодняшний день — разбить части кода на библиотеки. Это и оптимальней, и время компиляции сократится (не придётся компилировать лишний раз то, что уже скомпилировано), и отладка проще.
Сорри, гуглоплюс не отдал картинку :(
Похоже на волка из мультика:
— Сы-па-сы-ба… Ну ты заходи, если шо!..
собрала операционка все браузеры и говорит: — того, кто будет безмерно жрать память — буду бить по наглой рыжей морде. (с)
«Firefox не вмещается в 32-битное адресное пространство»
Может всё-таки, компилятор Firefox не вмещается? У самого продукта с памятью пока запас есть.
Да и (3) решение выглядит слишком очевидным. В-общем, моё субъективное мнение: проблема не стоит даже того, чтобы в баг-лист добавлять.
Вы забыли про автора топика
Мне кажется, или в каждом посте вышеозначенного автора есть такой коммент? :)
PAE и серверная версия виндовса для компиляции?
Вобще, у проблемы масса решений, и она скорее не является чем-либо серезным, а просто забавным случаем.
PAE позволяет всей системе адресовать больше физической памяти. Процессу будет выделяться всё равно такое же количество виртуальной памяти.
По большому счету да, хотя, насколько мне известно существуют хаки. А википедия вот говорит, что с PAE процессу выделяется 4 гигабайта.
С PAE в одном процессе можно адресовать 4 гигабайта, как и везде на 32-битных процах x86.
Вопрос только в том, что гигабайт зарезервирован под нужды системы.
Заголовки ализара не вмещаются в здравый смысл.
Вот то что SPDY выпилили это фигово. Интересно было бы повозиться
Не вмещается линковщик, а не сам Firefox, расходимся!
Посмотрите на имя автора статьи. Потом на заголовок. Дальнейшие комментарии излишни.
А почему 3 ГБ в Win32? Я бы сказал 4 (2^32) минус выделенное пространство под устройства, ресурсы етц.
А ядру в каком пространстве работать? Будешь урезать память для ядра — проиграешь в производительности.
Кто будет жрать дофига оперативы, получит по наглой рыжей морде.
Sign up to leave a comment.

Articles