Pull to refresh

Comments 71

… а для мака все не было 64 битного Хрома…
UFO just landed and posted this here
Качается версия 32 бита.
Не вижу причин почему бы ей не обновляться. Если такой вопрос и мог возникнуть — то с 32-х битной системой :)
Вы бы хоть указали в заголовке, что речь только про Win версию.
Вернулся на 32-битную версию только потому что плагин quicktime не работает в x64
а мне жуть как надо gsm файлы в браузере слушать
Эта проблема будет решена примерно к концу года, когда плагин quicktime перестанет работать и в 32 битах.
А как насчет MSI, чтобы в профиль пользователя не устанавливаться?
1. Совсем другие фонты (и размеры фонтов)
2. Иконки расширений какие то гигантские (и потом нерезкие)
Это не из-за x64, а новый механизм рендеринга (или что-то типа того), который называется DirectWrite. Его можно отключить в настройках
Фонты может и нормально. А вот гипертрофированые иконки расширений напрягают. Они зависят от того же DirectWrite?
Попробуйте отключить chrome://flags/#disable-direct-write Мне помогло со шрифтами, были ужасные.
4-я блин статья об этом мегособытии…
Если кто-то захочет написать 5-ю, пишите в заголовке сразу «для Windows», не пугайте людей.
они тут не исправили кривое масштабирование и приделали его к 32бит стабильной версии сегодня. Молодцы.Вот ссылка на баг code.google.com/p/chromium/issues/detail?id=395425 И на временное решение на реддите www.reddit.com/r/chrome/comments/2en8j0/just_got_chrome_37_its_resolution_is_really_low/ck16jbq

start parameter.
«XXXXXXXX\chrome.exe» /high-dpi-support=1 /force-device-scale-factor=1
Не пугайте так. Параметры в хроме задаются через минус.
именно так задаются параметры в ярлыке на запуск в в виндоуз
Оффтоп.

Достали тормоза Crome под OS X (что x86, что x64). Недавно решил навести разведку в браузерах и обнаружил, что Firefox Nightly (ver 34, x64) летает, по сравнению с хромом, с той же пачкой расширений. Даже флеш не так грузит комп. Удивительно.
А я после этого же шага еще и встроенный Сафари попробовал — и опечалился совсем :(
Да фаерфокс вообще няшка, я вам так скажу.
У меня вот после последнего обновления Chrome перестал открывать vSphere, причем наотрез. И памяти стал жрать как не в себя.
Что удивительно — опера12 летает шустрее хрома, особенно при открытии страниц.
Полгода назад на хром мигрировал, теперь вот жру кактус :(
Поправьте заголовок что это касается только win desktop версии. Вызывает смущение и прочтения топика который не касается какой-то части аудитории хабра.
То есть теперь хром может сожрать не 4 гигабайта оперативы, а замахнуться на 64 экзабайта?
Адресное пространство современных процессоров ограничено 256 Tb.
Хром в сумме всегда мог сожрать больше 4 гигабайт оперативы — он не монолитен, плагины запускаются в отдельных процессах, каждый из которых может сожрать свои 4 гигабайта.
Теперь каждая песочница chrome может выделить более 4-х гигабайтов на процесс.
Чего долгожданного-то? Кроме того, что теперь Хром может жрать еще больше памяти, никаких профитов нет.
x64-код работает быстрее вообще-то, чем x86
UFO just landed and posted this here
Ну хотя бы потому что x64 использует больше регистров общего назначения, а значит компилятор может сделать больше оптимизаций.
UFO just landed and posted this here
Еще раз, дело не в 64-битных числах, а в дополнительных регистрах, которые x64-код может использовать. Любой код состоит из процедур. В каждой процедуре есть временные значения. Эти временные значения надо куда-то класть. Чем сложнее процедура, тем больше временных значений. Если регистров мало, то компилятору приходится класть неуместившиеся в регистры значения в стек, а чтение/запись в стек намного медленнее, чем чтение/запись в регистр. Чем больше регистров, тем меньше приходится класть значения в стек.
Есть MMX, SSE, AVX и все они доступны из 32-х бит, так что прирост производительности будет только для целых чисел, а вот памяти жрать будет больше, ведь так, ничего не упускаю?

Просто для примера, открываем вот эту ссылку www.buyincoins.com/s/windows--tablet_c356_s-arrival_DESC.html и Chrome падает по достижении лимита для 32-битного приложения потому, что внутри движок хреновый и не умеет тормозить отдельный скрипт в отличие от Firefox. Теперь вопрос что будет с 64-битной версией, ОС плохо станет? Заодно прошу отчёт о падении отправить, может, подумают, что надо бы порядок в движке наводить.

P.S. из-за кривого управления ресурсами в Chrome я уже сейчас вынужден был порезать ему приоритеты на память средствами системы, что будет с 64-битной версией даже представить страшно.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\chrome.exe]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\chrome.exe\PerfOptions]
«IoPriority»=dword:00000001
«PagePriority»=dword:00000001

P.P.S. вопросы большей безопасности 64-битного приложения не поднимаю ибо это отдельный разговор, но вот с производительностью будет хуже.
Ubuntu 14.04, Chrome 37.0.2062.94 (64 bit). При загрузке страницы потребление оперативки процессом росло примерно до 2х гигабайт, после чего вкладка просто крашнулась. Остальные вкладки в порядке. Забавно было наблюдать за тем, как процесс перебрасывается между ядрами.

Содержимое крашнутой вкладки
image
Вы пишите: «Бла-бла-бла-бла… бла-бла-бла…… но вот с производительностью будет хуже». Причем в «бла-бла» нету никакой логической цепочки, из которой потом вытекает финальное утверждение, что производительность хуже. Это что, новый тип логики какой-то, мне незнакомый?
Ну я ещё и вопросы задаю. А так — да, просто констатирую на основе своего и не только опыта, что увеличение производительности, описанное Вами выше, будет лишь у части кода, использующей 64-битные целочисленные вычисления, ибо их теперь можно будет считать не в столбик, а сразу. У участков 32-битного целочисленного кода, которые можно группировать при сборке тоже будет увеличение скорости. В остальных же случаях, к примеру, для чисел с плавающей запятой (почти всё мультимедиа и очень многое в CSS и JS), для работы со строками и уже даже для криптографии в процессоре есть расширения со своими регистрами, которые доступны любому коду. Да и помимо регистров в процессорах уже давно есть мегабайты кешей различных уровней. Ах да, забыл — для мультимедиа ещё есть аппаратные декодеры в видеокартах, да и для рендеринга Chrome вовсю использует GPU (убедиться для конкретного экземпляра приложения можно тут chrome://gpu ).

Так вот, а с производительностью будет хуже поскольку потребление памяти вырастет, видимо, я слишком криво эту фразу написал для такого сокращения по смыслу. Насколько сильная будет разница — не знаю, для этого надо тестировать обе релизные версии в одинаковых сценариях. Однако, многие чисто технические вещи, к примеру, все memory typed типы (указатели, многие счётчики и т. д.) теперь будут занимать не 32 бита каждый, а 64. Ну а скептицизм «но вот с производительностью будет хуже» вызван тем, что для архитектуры Chrome расточительное потребление ресурсов проблема и переход на 64 бита только ухудшит ситуацию поскольку теперь потребуется больше памяти. В общем, ИМХО, единственный, действительно значимый, плюс от перехода Chrome на 64 бита это увеличение безопасности, но значительному росту производительности там взяться просто неоткуда.

P.S. да, эти «бла-бла» действительно никому не знакомая последовательность логических рассуждений, да ещё и основанная на точном ощущении, что все вокруг мысли читать умеют. Благодарю, что обратили на это внимание. В общем, спать мне надо почаще в соответствии с тем часовым поясом, в котором живу, а не работаю, ну или переезжать пора :)
Ладно, похоже, что дело идёт к тому, что нужно уже смотреть конкретные примеры кодогенерации. Если найду время, то попытаюсь запостить сюда примеры ассемблерного кода, сгенерированного для x86 и x64 приложений. Может, в течение следующих нескольких дней. И вы убедитесь, что он отличается.
Увеличение производительности, если очень повезет, будет до 5%. Уверен, есть тысяча и одно более узкое место, что разрядность.
Ладно, не вижу смысла спорить с людьми, которые не понимают, как работают компиляторы
Да все мы понимаем. Раскидать локальные переменные, используемые функциями, по регистрам, а не по оперативке, что быстрее и лучше. Только в реальном мире, в 99% случаев, это не дает почти никакого прироста. Ну 1-5%, как я писал выше.
Сколько-нибудь серьезные цифры можно ждать на традиционных конвертациях мультимедийных форматов и архивировании, но, полагаю, на Хром тут особо не при делах.
Откуда цифра 1-5%? Мы недавно тестировали производительность нашего приложения и выяснили, что x64 версия работает быстрее в 2 раза, чем x86. Правда, это Java-приложение, но там все равно тот же принцип, просто компиляция происходит во время работы приложения.
Получена эмпирическим путем (как на собственном софте, так и на стороннем). GCC, MSVC.
Решил погуглить по этому вопросу, по первой же ссылке результаты похожие. Т.е. на сильно математических задачах (мультимедиа, криптография) выигрыш может быть очень существенным, но в целом же чуда ждать не приходится.
В Хроме ведь есть мультимедиа и криптография, правильно?
Правильно, но, очевидно, это довольно малая часть всей работы браузера.

В общем, на мой взгляд:
1) Хорошо, что появилась 64-битная версия (что-то действительно можно немного оптимизировать);
2) Конечный пользователь не получит значительного увеличения производительности в повседневной работе.
3) На уменьшение потребляемой памяти (что на мой взгляд, важно) в лучшем случае это не скажется никак.
Где можно почитать актуальное сравнение потребления ресурсов Хромом и ФФ?
Не знаю где почитать, но по моему опыту Chrome жрёт слишком много ОЗУ и это не исправить, кроме как сторонними костылями (у меня сейчас вот такой костыль применён habrahabr.ru/company/eset/blog/234713/#comment_7922237 ).

Какие есть проблемы в Chrome, которых в Firefox нет:

— нет даже опциональной ленивой загрузки вкладок, это критично особенно для устройств с батареей или при лимитированном трафике (привет мобильному интернету). Помимо этого активная загрузка вкладок Chrome может привести к бану на некоторых ресурсах или ошибкам при открытии сессии с большим количеством страниц. В Firefox есть отключаемая ленивая загрузка вкладок, вплоть до того, что вкладки не будут грузиться до тех пор, пока пользователь на них не перейдёт. Такое поведение FF, очевидно, благотворно сказывается на времени работы от батарейки.

— chrome очень плохо отдаёт ресурсы системе назад, видимо, это расчёт на то, что так будет быстрее. В итоге при открытии туда-сюда пачек вкладок выедается вся память на компьютере, при этом совершенно неважно сколько её будет. Помимо этого в Chrome нет механизма выгрузки данных из памяти, поэтому адекватного расширения для их выгрузки нет, а все, что есть замусоривают историю своими внутренними ссылками. Для примера — 8 ГБ для нормальной работы Chrome очень мало, на 16 уже можно работать ибо сейчас есть лимиты на 32-битный процесс. При переходе на 64-битные процессы я не берусь предсказать сколько памяти будет достаточно. У себя я эту проблему решил средствами системы — заставил её выносить в своп Chrome в первую очередь (см. ссылку на комментарий выше в начале этого). Теперь, через несколько часов работы подтупливает только Chrome, а не вся система (Core 2 Q9550 + 8 ГБ ОЗУ). Firefox же быстро отдаёт ресурсы системе назад ибо ограничен в них из-за своей архитектуры. Помимо этого в FF есть адекватное API для выгрузки вкладок и есть расширение addons.mozilla.org/ru/firefox/addon/unloadtab/?src=userprofile, позволяющее корректно выгружать фоновые вкладки из памяти и тем самым использовать минимум ресурсов при длительной работе. Фактически FF можно при такой схеме работы не закрывать вообще.

— движок chromium не умеет тормозить отдельный скрипт на странице. Из-за этого в тех случаях когда Firefox может открыть страницу с потерей части функциональности, Chrome не может этого сделать (см. ссылку на комментарий выше в начале этого).

Какие есть проблемы в Firefox, которых в Chrome нет:

— при большом количестве одновременно активных вкладок Firefox работает значительно медленнее поскольку имеет однопроцессную архитектуру 32-битную архитектуру, а потому по памяти он ограничен. В Chrome эта и следующая проблема решены многопроцессной архитектурой.

— по причине однопроцессной архитектуры в случае серьёзного сбоя падает весь браузер, а не отдельная вкладка.

— FF поддерживает немного меньше функциональности HTML5 чем Chromium.

Производительность у них +- одинаковая, фактическая разница есть в синтетических тестах, но в практической работе её нет.

P.S. я бы в принципе мог написать пост на эту тему, приложив ещё и скриншоты с кучей тестов, но особого смысла в этом не вижу ибо браузеры развиваются и через полгода что-то может поменяться. Однако особенности подхода к использованию ресурсов постарался максимально описать в этом комментарии и они не меняются уже длительное время.
Сколько у вас обычно открыто вкладок в Хроме? У меня всегда около пяти, максимум десять-двадцать, при этом общее потребление оперативки системой редко переваливает за 4 гб. Может у вас слишком много расширений?
Дело точно не в расширениях. Вкладок открыто бывает сильно по-разному и частенько сессия может достигать нескольких десятков, больше сотни точно никогда не было. Это действительно необходимость если что-то пишется или анализируется, поскольку для этого нужно просматривать параллельно много материала. Множество открытых вкладок необходимы для сохранения позиции в тексте на странице, к примеру. Такая сессия почти статично может быть открыта несколько дней, т. е. пока не будет дописано всё требуемое по этому материалу. Так вот, в Firefox я такую работу могу выполнять без сторонних костылей и всё чудно работает даже на устройстве с 1 ГБ памяти, а вкладки после долгого простоя быстро подзагружаются на то же самое место. В то же время для реализации аналогичного сценария в Chrome нужно уже 16 ГБ, ибо даже на 8 он люто-адово тормозит при переключении между вкладками. При этом если не применить финт ушами с приоритетами, то начинает тормозить не только он, а всё подряд ибо системный кеш не может корректно работать поскольку почти всё ОЗУ отдано хрому.

Кстати, на Android у Chrome те же самые проблемы, в ситуациях где Firefox нормально работает на моих железках с несколькими вкладками, примерно до 5–10, Chrome ели ползает уже с 2–3. При этом Chrome не умеет нормально выгружать вкладки и даже не сохраняет данные в полях ввода. То есть на Chrome велик шанс не успеть дописать комментарий, к примеру. Собственно на Android я уже полностью отказался от Chrome в пользу Firefox. На десктопе этого сделать всё ещё не могу. Не хватает некоторых расширений и функциональности, которым, пока ещё, не нашлась замена. Ах да, ещё пароли в Firefox мне пока не удалось перенести автоматом, что то же создаёт проблемы.
А есть способы корректно заменить 32 на 64 не теряя профиль и открытые вкладки?
Закрыл все процессы 32 битного хрома в диспетчере задач, на всякий случай сохранил все открытые вкладки (меню-закладки-закладки для открытых страниц..). Запустил установку — успешно обновился до 64битной версии, браузер сказал, что предыдущая работа завершена некорректно и предложил переоткрыть вкладки, профиль никуда с расширениями не делся.
Никаких проблем.
У меня он теперь сразу зависает при открытии. И не понятно как его доунгрейдить.
У одного меня трабла со шрифтами? (х64 слева, х32 справа)
Можно добавить следующие параметры старта chrome "****/chrome.exe" /high-dpi-support=1 /force-device-scale-factor=1 возможно поможет. Затем перезапустить chrome.
Спасибо, но не помогло. Тем более, никаким HighDPI у меня и не пахнет.
Тогда можно просто попробовать отрубить DirectWrite (это экспериментальный движок рендеринга шрифтов)
Перейти на страницу chrome://flags/
Активировать пункт «disable DirectWrite»
Хм. Отключил (помогло, спасибо). Включил снова. Отключил и еще раз включил.
Вы во мне смуту посеяли)). Вроде да, полужирный стал яро широким. Но выглядит-то сглаживание лучше! Вот и что делать?
А Вы чередуйте, немного работайте в браузере со сглаживанием, немного без. А там глядишь привыкните к сглаженному шрифту :) и все будет нормально восприниматься. Новое всегда привносит смуту.
У меня после установки x64 версии, в окне «О программе» отображается «Версия 37.0.2062.94 unknown-m (64-bit)».
Обновился тоже нормально, x86 версию не удалял, просто закрыл браузер и запустил установку x64 версии. Все закладки и профиль сохранены. Полет нормальный!
Понятно, значит не пофиксили. Хотя было упомянуто что это пофиксят в 37M, но как видим наименование канала так и остается странным.
Обновил на х64 — дичайшие просто тормоза, первый запуск хрома муть не 5 минут. «Хром не отвечает на запросы, закрыть?»
Вернулся на 32 — а тормоза остались… теперь профиль чистить, блин…
Sign up to leave a comment.