Comments 104
А обновить текущий нельзя до 64-битной?
В заголовке нужно явно указать, что это для ОС Windows. А то я уже было испугался…
$ file /opt/google/chrome/chrome
/opt/google/chrome/chrome: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=0x86b11e2c8d00caf4b88067a7ba0391ebd460d525, stripped
Ну а что с 64-битной версией под макось?
Пожалуйста, поясните, за что минусуете. Я уже давно жду 64-битную версию под Mac OS. Это важно из-за невозможности обновить Java, которая доступна только в 64-битной версии.
Это хабр, им лишь бы заминусить
А объясните мне, идиоту, что у вас за проблемы с Java? Она к концу года в Chrome перестанет работать всё равно, так какая вам разница — произойдёт это сейчас или чуть позже?
Это для того, чтобы он мог отожрать ещё больше памяти?
Вы оказались правы. Поставил х64 версию, запустил вкладку с Gmail, откушал ~500 Мб. Переставил обычный хром ~256 Мб.
Не знаю как для вас, но у меня давно больше претензий к софту не в плане потребления памяти, а в плане производительности. Тот же Firefox на двух Core2Duo компах тормозит страшенно (кстати не стесняясь при этом кушать полтора гига оперы).
Да пусть жрёт хоть 2, хоть 3 гига, лишь бы летал (как хром).
Да пусть жрёт хоть 2, хоть 3 гига, лишь бы летал (как хром).
2...3, эх, у меня он почему то отжирает ВСЮ память (её правда всего 8 :) ), и при этом, мало того, что начинает тупить сам, так тупит ещё и всё остальное, включая ОС и остальные приложения. Приходится с интервалом в несколько часов в диспетчере задач хрома убивать все вкладки, а раз в сутки перезапускать его целиком, ибо 2-3 ГБ начинает занимать только хром с одной «пустой» вкладкой.
Вчера поставил себе. На моем слабеньком компе такое ощущение, что только для браузера оперативка существует.
Наконец-то мне под маком для интернет-банка с его «только-64-бит-явой» не придётся ходить в другой браузер…
Для OS X качнул:
Я думал он давно 64-битный :(
$ file /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome/Applications/Google Chrome.app/Contents/MacOS/Google Chrome: Mach-O executable i386$ file /Applications/Google\ Chrome\ Canary.app/Contents/MacOS/Google\ Chrome\ Canary /Applications/Google Chrome Canary.app/Contents/MacOS/Google Chrome Canary: Mach-O executable i386Я думал он давно 64-битный :(
К сожалению, запрос висит уже 5 лет как, но прогресса пока не видно :( code.google.com/p/chromium/issues/detail?id=18323
Это круто, конечно, но зачем? Чтобы браузер мог теперь съесть всю оперативку?
Или там какая-то хитрая ассемблерная оптимизация V8?
Или там какая-то хитрая ассемблерная оптимизация V8?
Во-первых, 64-битный код при должной оптимизации быстрее. Во-вторых, это позволяет создать полностью 64-битное окружение. Начертей держать в ОЗУ второй комплект DLL?
Не говоря уже о том, что новых 32-битных систем на Windows уже не нет.
Не говоря уже о том, что новых 32-битных систем на Windows уже не нет.
этот второй комплект DLL в озу в разы меньше, чем то, что кушает браузер :D
Странная логика. И чего? Давайте жить на 32 битах?
И, кстати, метров 400 минимум 32-битная подсистема отъедает.
И, кстати, метров 400 минимум 32-битная подсистема отъедает.
ну я живу на 64 битах давно.
а в случае винды — да, давайте жить на 32 битах. потому что эти 400 метров на все приложения лучше, чем по 500-600 метров лишнего на каждом.
а в случае винды — да, давайте жить на 32 битах. потому что эти 400 метров на все приложения лучше, чем по 500-600 метров лишнего на каждом.
Не обязательно. Конечно, родное х64 лучше. Но говорить о 25% увеличении производительности… ну это то же самое, что сказать, что на оптимизацию х86 версии мы тупо забили и не смогли.
>> новых 32-битных систем на Windows уже не нет
На восьмидюймовых виндовых планшетах обычно 32-битная винда.
На восьмидюймовых виндовых планшетах обычно 32-битная винда.
Единственная реально полезная фича перехода на 64 бита это увеличение безопасности (почитайте про различия в механизмах защиты для 32х и 64х битных версий приложений). Что же касается производительности, то гораздо больший прирост можно достичь за счёт векторизации (наборы SSE, AVX). По поводу оперативки Хром и сейчас уже имеет паскудную архитектуру, которая просто выжирает ресурсы, одна только невозможность запретить автоматом загружать фоновые вкладки чего стоит, в том же FF гораздо лучше, более того FF уже штатно учат полностью выгружать долго не используемые вкладки из памяти, и освобождать все ресурсы, хотя и сейчас это для FF можно сделать сторонним плагином. Для Хрома выгрузку, и запрет загрузки даже с помощью плагина нормально не сделаешь, ибо начинается загаживание истории псевдо ссылками от расширения, и т.п. косяки, а всё потому что нормально апи для работы с вкладками в Хроме нет.
«Немного более безопасным».
Больше лучше одеваться, ей-богу.
Больше лучше одеваться, ей-богу.
Интересно, улучшение стабильности на 50% как-то связано с тем, что 32 — это 50% от 64?) Хотя в таком случае это на 200%, а не на 50%
— I have 32-bit Windows 7. I need 64 bit to game. How to get 64 bit? Will I get it if install twice?
— Yes install twice. You’ll also get Windows 14.
— Yes install twice. You’ll also get Windows 14.
Улучшение стабильности ИМХО связано с тем, что они вынужденны были провести ревизию и рефакторинг кода, который для 64х бит мог начать криво работать, и переписали эти биоразложимые участки по нормальному :)
Они сравнивают с той же самой версией Chrome, собранной из тех же самых исходников, так что — мимо.
Да, мимо, однако это всё равно приводит меня к той же причине — не переносимый или кривоватый код, который по разному работает в зависимости от внешних условиях… хотя, может у них 32 битная версия падала просто от того, что на одну страничку не хватало 2 ГБ, в таком улучшении стабильности я вообще не сомневаюсь, ибо часто такое у себя наблюдаю, особенно на сайтах с «бесконечной» разметкой :)
Вот скажите мне, кто заметил разницу при использовании 64-бит по сравнению с 32?
UFO just landed and posted this here
Не хочу, просто хочу понять смысл всех заморочек если это никак не влияет на конечный результат.
Смысл прост. Если улучшение не видно на глазок, это не значит, что это никак не влияет на конечный результат. Если результат нужен сию секунду, то может улучшением и можно пренебречь, но нужно же смотреть в будущее :-)
Лучше улучшать маленькими итерациями, чем никак…
habrahabr.ru/company/host-tracker/blog/224431/
Лучше улучшать маленькими итерациями, чем никак…
habrahabr.ru/company/host-tracker/blog/224431/
Честно говоря, я первым делом провел тест 64-битного на Peacekeeper. Он выдал на моем железе 4663 попугая.
Для сравнения: когда я только купил себе комп, уйдя с ноутбука на стационарник, я решил проверить как новое железо повлияло на производительность браузера. Тогда у меня стоял Chrome 34.0.1847.92, 32 бита естественно. Выдало это чудо 5527 очков.
Это уже не на глазок, но не обнадеживает.
Для сравнения: когда я только купил себе комп, уйдя с ноутбука на стационарник, я решил проверить как новое железо повлияло на производительность браузера. Тогда у меня стоял Chrome 34.0.1847.92, 32 бита естественно. Выдало это чудо 5527 очков.
Это уже не на глазок, но не обнадеживает.
Как то жалко пользователей стало. Неужели совсем всё так плохо?
По словам разработчиков, новая версия Chrome на 25% производительнее обычной версии. Мне кажется Хром скоро будет загружаться быстрее чем компьютер :)
Прикольно, что даже Flash и Silverlight используются 64-битные. И 64-битным является не только главный процесс (как это по дефолту у ИЕ, например), но и все дочерние, включая процесс рендеринга. Т.е. всё это можно воспринимать не как эксперимент, а как действительно полный переход на х64.
Сколько теперь оперативки сожрёт Хром, прежде чем упасть на просмотре галереи в Dropbox? Сейчас падает после примерно 200 картинок и 3.7Gb сожранной оперативки.
Надо переставать пользоваться галереями Dropbox. Мало того, что сам Dropbox в разы дороже подобных решений от других вендоров (сегодня только у себя в блоге опубликовал сравнение), у него реализация галереи по-моему скомунизжена из Adobe Photoshop 1.0 — там какой-то жуткий HTML, который при любом раскладе показывается в махонькой области в центре экрана. Я клиентам фото отправляю либо в zip файле (и тогда Dropbox — отличное решение), либо в виде галереи (и тогда ничего лучше Picasa еще не нашел).
Хром, конечно, не без недостатков, но в данной конкретной ситуации проблема у Dropbox. 1000 картинок в Picasa/Google+ отображается нормально.
Хром, конечно, не без недостатков, но в данной конкретной ситуации проблема у Dropbox. 1000 картинок в Picasa/Google+ отображается нормально.
Столько глупых и нелепых комментариев я еще ни у одного топика на Хабре не видел.
Филиал ВиО мейл.ру прям.
Филиал ВиО мейл.ру прям.
Подскажите, как достоверно убедится что запускается именно 64х битная версия?
Через сколько под мак будет? И можно ли надеяться, что он будет меньше сажать батарейку, чем 32 версия?
Если что, по вот этой ссылке можно скачать 64-битный Хромиум, верхняя папочка содержит самый новый снепшот.
Поставил Chrome dev. Получил кривые шрифты в интерфейсе и размытые иконки расширений. HTML-страницы тоже корявато отображаются.
Переключил масштаб в настройках экрана со 125 на 100 процентов и всё стало ок.
Но для меня совсем не вариант — FullHD на 15-дюймовом буке вынуждает вернуться к прежнему масштабу.
Переключил масштаб в настройках экрана со 125 на 100 процентов и всё стало ок.
Но для меня совсем не вариант — FullHD на 15-дюймовом буке вынуждает вернуться к прежнему масштабу.
О! Есть повод перейти обратно (сейчас сижу на Waterfox).
Прошло 11 лет после выпуска настольного 64-бит процессора, 13 лет после того, как на него портировали Линукс, и лет 10 после того, как портировали движок рендеринга KHTML. И вот Google начала тестировать AMD64-сборку своего форка KHTML под Windows.
Это показатель того, насколько 64-битность большинству приложений совершенно не нужна. Я не убеждён, что и Хрому нужна. Комментарии выше про отжирание памяти тому в подтверждение. А учитывая, что цена на память взлетела и не опускается, тем более.
А он один фиг делает кучу процессов на каждый чих, так что проблемы с ограничением выделенной памяти под программу ему не грозят. А оптимизация не настолько заметна, чтобы бросить все и срочно делать 64-бит версию.
Если бы AMD64 было большинству не нужно, Intel не делала бы бюджетных AMD64-процессоров. Atom и Core i3 были бы 32-битными, например, а i5 с i7 — 64-битными.
Но нет, процессоры — 64 бита, ОС — 64 бита (даже Windows XP c 2005 года), прикладные программы от производителя ОС — 64 бита.
То, что люди продолжают ставить на компьютеры ОС для старой архитектуры, программы для старой архитектуры — это ненормально и вредно для развития отрасли. То, что программисты продолжают создавать код для старой архитектуры — это ещё более ненормально и вредно.
Всё это сродни нездоровой любви нашего общества к Windows XP и IE6.
Но нет, процессоры — 64 бита, ОС — 64 бита (даже Windows XP c 2005 года), прикладные программы от производителя ОС — 64 бита.
То, что люди продолжают ставить на компьютеры ОС для старой архитектуры, программы для старой архитектуры — это ненормально и вредно для развития отрасли. То, что программисты продолжают создавать код для старой архитектуры — это ещё более ненормально и вредно.
Всё это сродни нездоровой любви нашего общества к Windows XP и IE6.
ОС 64-битная нужна — просто потому, что сейчас 4 гигов оперативной памяти (включая, к слову, и видеопамять!) уже мало. Другое дело, что вот конкретно прикладным приложениям эти 64 бита не нужны совершенно! Если одно приложение кушает больше 4 гигов оперативной памяти, это либо какое-то специфическое приложение, вроде автокада или 3д макса, либо что-то очень неоптимизированно потребляющее память (вроде, ИМО, того же Хрома). Даже суперсовременные игры умещаются в эти 4 гига оперативной памяти и собраны в 32 бита!
Более того, даже для оси 64 бита не так уж нужны, если оставаться в рамках 64 гигов для всех и 3 гигов для одного приложения. Адресация за пределами 4 гигов возможна и на 32 битах. Другой вопрос, что в МС почему-то решили искусственно ограничить 32-битные винды 4 гигами (ну, тремя с половиной), просто подкрутив числа в «лицензии» и оправдавшись «дрова не очень хорошо работают».
Если это единственная причина — то нет, не нужна.
32-битные ОС могут адресовать до 64 ГБ оперативной памяти (Линукс, например, с 1999 года), столько на домашних компьютерах всё ещё нет.
32-битные ОС могут адресовать до 64 ГБ оперативной памяти (Линукс, например, с 1999 года), столько на домашних компьютерах всё ещё нет.
Хром на момента релиза (5 версия) и до сих пор всегда был и остаётся 64-битным. Неужели есть большие сложности сборки разных архитектур на m$ windows/macOS? И почему такого бардака (кроме проприетарного skype от m$, конечно) с битностями нет на линуксах?
Вы как бы сами себе ответили. Или даже не поняли?
Под Linux'ом нет «такого бардака» потому что под него вообще мало что есть. Ни PhotoShop'а, ни AutoCAD'а, ни сотен (а то и тысяч) корпоративных творений с NPAPI модулями. А под Windows — всё это есть и это и является её главным преимуществом. Но вот всё это переводить на 64 бита — долго и сложно. Потому и не торопились.
Поскольку Chrome собирается отказаться от NPAPI, то сейчас острота проблемы совместимости снизилась, так что да, теперь — можно. Вот и всё.
Под Linux'ом нет «такого бардака» потому что под него вообще мало что есть. Ни PhotoShop'а, ни AutoCAD'а, ни сотен (а то и тысяч) корпоративных творений с NPAPI модулями. А под Windows — всё это есть и это и является её главным преимуществом. Но вот всё это переводить на 64 бита — долго и сложно. Потому и не торопились.
Поскольку Chrome собирается отказаться от NPAPI, то сейчас острота проблемы совместимости снизилась, так что да, теперь — можно. Вот и всё.
Слишком много эмоций, нельзя так.
Вопрос по другому — в чём конкретно принципиальная сложность перевода на 64 бит? Да и брать тот же хром — он изначально под линуксы был 64 бит и гугл как-то не жаловался на проблемы совместимости и оптимизации. Что же самому гуглу помешало сделать 64 битнй хром для маков/вин сразу?
Вопрос по другому — в чём конкретно принципиальная сложность перевода на 64 бит? Да и брать тот же хром — он изначально под линуксы был 64 бит и гугл как-то не жаловался на проблемы совместимости и оптимизации. Что же самому гуглу помешало сделать 64 битнй хром для маков/вин сразу?
Вы снова и снова пропускаете нулевой пункт («а нафига оно вообще кому-либо нужно?») — и потому ищите ответ не на тот вопрос. Вы спрашиваете: кто мешает перейти — но ведь ответ на этот вопрос очевиден даже не на 100%, а на все 200%! Перейти нельзя пока у пользователей есть 32-битные OS! А ведь и сейчас ещё продаются железки с 32-битной Windows!
Всё, что можно сделать — это добавить 64-битную версию, то есть добавить ещё одну платформу — и как и с любой другой платформой этого «просто так» никто делать не будет, нужны взвесить все за и против (причём вариант «ничего не делать», понятно, — умолчальный как требующий минимум затрат).
Под линуксы Chrome изначально пришлось поддерживать и 32-бит и 64-бит, потому что разработчики оных линуксов забили на поддержку 32-битных программ в 64-битной OS (по иронии судьбы сейчас с ней всё гораздо лучше) и 32-битную программу в 64-битной OS просто было сложно использовать. Потому 64-битная версия и была выпущена — чтобы облегчить жизнь пользователям.
В случае же с Mac'ом и Windows таких проблем никогда не было (и там и там 32-битные версии программ отлично работают в 64-битных операционках), а зато проблемы совместимости с NPAPI plugin'ами, наоборот, были.
Сейчас потихонечку ситуация меняется (у меня на рабочем компе, скажем, 64GiB оперативки стоит) и уже возникает потихоньку желание перевести сам Chrome в 64бита чтобы можно было использовать больше памяти — что, собственно, и осуществляется. Но главное — планируемый отказ от NPAPI развязывает руки: если поддерживать NPAPI-plugin'ы мы больше не собираемся, то нас уже не волнует тот факт, что бо́льшая их часть не имеет 64-битных версий.
Баланс сил изменился и было решено 64-битную версию всё-таки выпустить. За счёт отказа от одной из Linux'овых платформ, кстати (раньше версии для ChromeOS и обычного Linux'а сильно отличались: ChromeOS был построен на Aura, а обычный Linux'овый Chrome — на GTK… сейчас от версии на основе GTK отказались).
Всё, что можно сделать — это добавить 64-битную версию, то есть добавить ещё одну платформу — и как и с любой другой платформой этого «просто так» никто делать не будет, нужны взвесить все за и против (причём вариант «ничего не делать», понятно, — умолчальный как требующий минимум затрат).
Под линуксы Chrome изначально пришлось поддерживать и 32-бит и 64-бит, потому что разработчики оных линуксов забили на поддержку 32-битных программ в 64-битной OS (по иронии судьбы сейчас с ней всё гораздо лучше) и 32-битную программу в 64-битной OS просто было сложно использовать. Потому 64-битная версия и была выпущена — чтобы облегчить жизнь пользователям.
В случае же с Mac'ом и Windows таких проблем никогда не было (и там и там 32-битные версии программ отлично работают в 64-битных операционках), а зато проблемы совместимости с NPAPI plugin'ами, наоборот, были.
Сейчас потихонечку ситуация меняется (у меня на рабочем компе, скажем, 64GiB оперативки стоит) и уже возникает потихоньку желание перевести сам Chrome в 64бита чтобы можно было использовать больше памяти — что, собственно, и осуществляется. Но главное — планируемый отказ от NPAPI развязывает руки: если поддерживать NPAPI-plugin'ы мы больше не собираемся, то нас уже не волнует тот факт, что бо́льшая их часть не имеет 64-битных версий.
Баланс сил изменился и было решено 64-битную версию всё-таки выпустить. За счёт отказа от одной из Linux'овых платформ, кстати (раньше версии для ChromeOS и обычного Linux'а сильно отличались: ChromeOS был построен на Aura, а обычный Linux'овый Chrome — на GTK… сейчас от версии на основе GTK отказались).
Сейчас от gtk отказались и он стал страшен как адовый рекламный баннер, что очень печально, а совместимость с нативными движками тем оформления так и не допилили — тянет только цвета и иконки (мне должно быть всё ровно как оно работает, но выглядеть стало гораздо хуже). В линуксах нет никаких проблем с битностью, просто все нужные библиотеки придётся дублировать в x32 варианте (точнее это будет делать пакетный менеджер), что не есть гуд по идеологическим и эстетическим соображениям (в вин это решается запихиванием всех либ в одну программу, не красиво, но решает проблемы совместимости). Да, понимаю, что софта таки мало (он есть, но мало), тем не менее в битности никто не обделён (кроме, опять же, скайпа) — ни всякие свободные редакторы, ни майя, ни вообще что-бы то ни было. То есть с появлением x64 наличие сборок под 32 и 64 является само собой разумеющимся (да и серверные системы сбрасывать со счетов не будем, там свой софт). Интересует почему эта «культура» не затронула другие системы. Действительно ли имеют место быть серьёзные технические проблемы, увеличивающие траты на поддержку архитектур?
Интересует почему эта «культура» не затронула другие системы.Может, просто потому, что для них есть куча более не поддерживаемого производителем 32-битного (если не 16-битного) софта без исходников?
А даже если и есть исходники — что с того? Поймите: принцип «работает — не трогай» он основополагающий. Как выход новой версии какого-нибудь Civic'а (или Bentley) не приводит к тому, что все кидаются обновлять весь парк, так и к софту люди относятся. Любое изменение где-угодно требует обоснования.
Программистам (да и не только им) очень тяжело это понять (потому что не хочется), но это простая экономика. Конечно гораздо «веселее» и «приятнее» заменить в доме всё сантехнику, вместо того чтобы ковыряться в полусгнивших трубах, но, увы, это заметно дороже, так что приходится ковыряться.
То же самое и с программами: там, где их делают за деньги (а не «для души») никто не будет переписывать что-либо только потому, что у них появился новый расчудесный 64битный процессор. Вот когда кто-то скажет какая от такого переписывания будет польза — вот тогда и только тогда этот вопрос начнёт обсуждаться. Да и то — результат может оказаться далеко не в пользу переписывания.
Программистам (да и не только им) очень тяжело это понять (потому что не хочется), но это простая экономика. Конечно гораздо «веселее» и «приятнее» заменить в доме всё сантехнику, вместо того чтобы ковыряться в полусгнивших трубах, но, увы, это заметно дороже, так что приходится ковыряться.
То же самое и с программами: там, где их делают за деньги (а не «для души») никто не будет переписывать что-либо только потому, что у них появился новый расчудесный 64битный процессор. Вот когда кто-то скажет какая от такого переписывания будет польза — вот тогда и только тогда этот вопрос начнёт обсуждаться. Да и то — результат может оказаться далеко не в пользу переписывания.
С исходниками кто-нибудь мог бы и перенести, если бы это было выгодно, тем более, что где-то весь перенос, возможно, заключался бы в простой перекомпиляции. А без исходников единственный вариант — переписать заново. И да — с исходниками и «забесплатно» часто делают, если речь о FOSS.
P.S. Поддержка устаревшего железа, для которого давно не выпускают комплектующих — она тоже, знаете ли, не бесплатная и выходит заметно дороже поддержки современного. Взять, скажем, стоимость SIMM-модулей памяти.
P.S. Поддержка устаревшего железа, для которого давно не выпускают комплектующих — она тоже, знаете ли, не бесплатная и выходит заметно дороже поддержки современного. Взять, скажем, стоимость SIMM-модулей памяти.
В линуксах нет никаких проблем с битностью, просто все нужные библиотеки придётся дублировать в x32 варианте (точнее это будет делать пакетный менеджер)Если бы это было так, то никто бы не стал городить огород с 64-битным Хромом. Увы и ах, но нормально заработало это только в последние 3-4 года. До этого многих 32-битных библиотек ваши любимые «пакетные менеджеры» не предоставляли и, главное, не было ну никакой возможности поставить пакет от 32-битной системы на 64-битную на системах произведённых от Debian'а (в первую очередь Ubuntu)! Сейчас эту проблему вроде как разрулили, но так как 64-битный Chrome для Linux'а уже есть, то убивать его не стали.
Действительно ли имеют место быть серьёзные технические проблемы, увеличивающие траты на поддержку архитектур?Не знаю насколько эту проблему можно назвать технической, но да, есть, разумеется. Называется Q&A. В «классическом» Linux'е на него, зачастую, просто забивают (почему он и обречён прозябать на уровне 1-2% рынка и никогда за эти пределы не выйдет), а на других платформах — это существенная часть затрат. Даже если у вас код для двух разных систем совпадает на 99% все неавтоматизированные проверки при введении поддержки 64-битных систем (и неотказе от 32битных) придётся делать дважды.
Потому настоящий переход на 64бита на других платформах случится не тогда, когда появятся 64-битные процессоры, а когда исчезнут 32-битные! А до этого — ещё несколько лет.
Ну и фиг с ним с этим линуксом, пускай не выходит из процента, а ответ на вопрос я так и не увидел. Упоминание первого у вас явно вызывает сильные эмоции.
Ну хорошо. Давайте я переведу ваш вопрос с русского на русский: «почему после выхода нового «вкусного» 64битного железа никто не ринулся выкидывать деньги на ветер и не стал переписывать программы, которые и в 32битном виде отлично работают?» — неужели этот вариант ещё требует какого-то ответа, кроме риторического?
Да потому что это не нужно никому нафиг! Вот и всё. Зачем делать работу, которую можно не делать? Что тут непонятного-то? Будут причины перейти на 64 бита — перейдут.
Да потому что это не нужно никому нафиг! Вот и всё. Зачем делать работу, которую можно не делать? Что тут непонятного-то? Будут причины перейти на 64 бита — перейдут.
Дополню khim: сложилась ситуация, что софт, который требовал работы с большими числами уже очень и очень давно использует наборы SSE и др. спец инструкции, для примера можно взять видеокодеки, декодеры и т.д. По этой причине для большого количества софта даже эффекта от переписывания на 64 бита нет никакого, или он близок к нулю, а проблем с совместимостью с внешними либами и затратами на тесты тьма.
Единственные кому реально нужны 64 бита это программы способные утилизировать память в больших объёмах, всё остальное уже давно переписано с использованием векторизации и чудесно работает.
Единственные кому реально нужны 64 бита это программы способные утилизировать память в больших объёмах, всё остальное уже давно переписано с использованием векторизации и чудесно работает.
Вопрос к тем, кто попробовал: только у меня верхний край вкладок немного уехал за границу монитора? Как можно починить теперь? Переустановка stable версии не помогла, багрепорт написал…
blogs.technet.com/b/srd/archive/2013/12/11/software-defense-mitigating-common-exploitation-techniques.aspx
Интересные данные по энтропии
DLL images based above 4 GB: 19 bits of entropy (1 in 524,288 chance of guessing correctly)
DLL images based below 4 GB: 14 bits of entropy (1 in 16,384 chance of guessing correctly).
EXE images based above 4 GB: 17 bits of entropy (1 in 131,072 chance of guessing correctly).
EXE images based below 4 GB: 8 bits of entropy (1 in 256 chance of guessing correctly).
Нашел показатели энтропии непатченного ядра linux (патчами можно еще увеличить)
Anonymous mapping randomisation test: 28 bits (guessed)
Heap randomisation test (ET_EXEC): 14 bits (guessed)
Heap randomisation test (PIE): 28 bits (guessed)
Main executable randomisation (ET_EXEC): 28 bits (guessed)
Main executable randomisation (PIE): 28 bits (guessed)
Shared library randomisation test: 28 bits (guessed)
Stack randomisation test (SEGMEXEC): 28 bits (guessed)
Stack randomisation test (PAGEEXEC): 28 bits (guessed)
Arg/env randomisation test (SEGMEXEC): 20 bits (guessed)
Arg/env randomisation test (PAGEEXEC): 20 bits (guessed)
Randomization under memory exhaustion @~0: 28 bits (guessed)
Randomization under memory exhaustion @0: 28 bits (guessed)
А какие данные у других платформ?
Интересные данные по энтропии
DLL images based above 4 GB: 19 bits of entropy (1 in 524,288 chance of guessing correctly)
DLL images based below 4 GB: 14 bits of entropy (1 in 16,384 chance of guessing correctly).
EXE images based above 4 GB: 17 bits of entropy (1 in 131,072 chance of guessing correctly).
EXE images based below 4 GB: 8 bits of entropy (1 in 256 chance of guessing correctly).
Нашел показатели энтропии непатченного ядра linux (патчами можно еще увеличить)
Anonymous mapping randomisation test: 28 bits (guessed)
Heap randomisation test (ET_EXEC): 14 bits (guessed)
Heap randomisation test (PIE): 28 bits (guessed)
Main executable randomisation (ET_EXEC): 28 bits (guessed)
Main executable randomisation (PIE): 28 bits (guessed)
Shared library randomisation test: 28 bits (guessed)
Stack randomisation test (SEGMEXEC): 28 bits (guessed)
Stack randomisation test (PAGEEXEC): 28 bits (guessed)
Arg/env randomisation test (SEGMEXEC): 20 bits (guessed)
Arg/env randomisation test (PAGEEXEC): 20 bits (guessed)
Randomization under memory exhaustion @~0: 28 bits (guessed)
Randomization under memory exhaustion @0: 28 bits (guessed)
А какие данные у других платформ?
Мониторы 22 дюйма. Вин 8. Пользуюсь виндовой настройкой размера всех элементов — 125%.
С переходом на Хром х64 (возможно битность не при чём, но я заметил именно в момент перехода) в хроме всё стало ощутимо больше (режим 100%), очевидно браузер использует системную настройку.
Тот же хабр в ИЕ при зуме 100% примерно равен 90% Хрома, но в хроме макет во всю ширину, в отличие от ИЕ и 2х Опер (на разных движках).
Меня, как пользователя, это устраивает, но, как разработчику, становится не понятно, как тестировать макеты.
х86 версия хрома исчезла после установки х64. Как то это напоминает историю с версиями ИЕ :(
С переходом на Хром х64 (возможно битность не при чём, но я заметил именно в момент перехода) в хроме всё стало ощутимо больше (режим 100%), очевидно браузер использует системную настройку.
Тот же хабр в ИЕ при зуме 100% примерно равен 90% Хрома, но в хроме макет во всю ширину, в отличие от ИЕ и 2х Опер (на разных движках).
Меня, как пользователя, это устраивает, но, как разработчику, становится не понятно, как тестировать макеты.
х86 версия хрома исчезла после установки х64. Как то это напоминает историю с версиями ИЕ :(
Sign up to leave a comment.
Google выпустил 64-битную версию Chrome для Windows