| |
| 2.2, th3m3 (ok), 19:35, 17/02/2015 [^] [^^] [^^^] [ответить]
| +5 +/– |
 Кстати, да. Причём тут Опеннет и эта новость - непонятно.
| | |
| |
| 3.3, Аноним (-), 20:13, 17/02/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
Половина (если не больше) браузера открыта, модифицируй сколько хочется.
| | |
| |
| 4.21, Tav (ok), 00:26, 18/02/2015 [^] [^^] [^^^] [ответить]
| +6 +/– |
 Движок и без них был открытым, а вот вся остальная проприетарная надстройка (и следовательно вся программа в целом) доверия совершенно не заслуживает и противоречит этике и открытого, и свободного ПО.
| | |
|
| 3.48, Аноним (-), 12:16, 22/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
Ну, как-то новости про обычный хром вместо изначального хромиума постят и ничё.
| | |
|
|
| 1.4, soarin (?), 20:19, 17/02/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Пока этот браузер доведут до stable, из двух пользователей кому это надо было б, останется один, а второй уже перейдёт на 64 битную ОС.
| | |
| |
| 2.7, Омоним (?), 20:45, 17/02/2015 [^] [^^] [^^^] [ответить]
| +5 +/– |
Чтоб не тратить на указателях в два раза больше ОЗУ.
Лучше поясните, зачем браузеру более 2ГБ ОЗУ. Одному процессу.
| | |
| |
| 3.8, vlikhachev (ok), 21:09, 17/02/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Чтоб не тратить на указателях в два раза больше ОЗУ.
> Лучше поясните, зачем браузеру более 2ГБ ОЗУ. Одному процессу.
Талантливые Веб-дизайнеры с модными CMS наперевес и больше памяти помогут схавать... Зато сайты да интернет-магазины быстро-быстро клепают - заказчик оглянуться не успеет, а оно уже готово.
| | |
| 3.9, Аноним (-), 21:26, 17/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
Ничего, что в 32-х битной версии теряем на отсутствии операций над "широкими" регистрами? А также теряем целую кучу новых инструкций, дающих процентов 15 производительности просто на пустом месте?
| | |
| |
| 4.11, Mihail Zenkov (ok), 22:05, 17/02/2015 [^] [^^] [^^^] [ответить]
| +1 +/– |
 На аудио/видео кодеках и то если повезет.
Несколько спасает ситуацию большие количество регистров, а то на оборот могли бы на ряде задач худшую производительность наблюдать ибо кэш не резиновый.
Если в системе <= 4GB, то наоборот нужно экономить память, а не жалкие проценты производительности процессора. Если начнется свопинг ...
| | |
| |
| 5.13, да я же (?), 23:29, 17/02/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> Несколько спасает ситуацию большие количество регистров
Спрашивал уже сколько раз, никто не отвечал толком: КАК спасёт ситуацию бОльшее количество регистров???
Современный код это по большей части лазанья-код, где "everything happens somewhere else", а значительное количество функций состоит просто из вызовов других функций и минимальной логики. БОльшее количество регистров всё равно придётся сохранять в стеке а потом восстанавливать, как и в случае с небольшим числом регистров.
Где я неправ?
| | |
| |
| 6.15, Mihail Zenkov (ok), 23:43, 17/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
> Спрашивал уже сколько раз, никто не отвечал толком: КАК спасёт ситуацию бОльшее
> количество регистров???
Грубо говоря, каждой переменной в функции можно выделить свой регистр и не дергать обычную память лишний раз.
> значительное количество функций состоит просто из вызовов других функций и минимальной логики
Если функции действительно простые, то компилятор будет пытаться делать из них более сложные (inline) дабы экономить на переходах.
| | |
| |
| 7.18, да я же (?), 00:10, 18/02/2015 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Грубо говоря, каждой переменной в функции можно выделить свой регистр
Это я понимаю.
Но перед каждым вызовом подфункции придётся этот регистр сохранять в стеке а потом - восстанавливать, иначе вызываемая функция может этот регистр перезатереть. Либо, если соглашение о вызове другое, сохранять в стеке модифицируемые регистры придётся самой вызываемой функции. Но в любом случае это запись в стек.
inline-функции это действительно оптимизируют, но... неужели inline-функции (в том числе те, что компилятор сам заинлайнил) действительно дают настолько большой эффект?
| | |
| |
| |
| 9.24, да я же (?), 01:25, 18/02/2015 [^] [^^] [^^^] [ответить] | –1 +/– | Возможно, вы меня не так поняли или я вас Я говорю не о передаче через регист... большой текст свёрнут, показать | | |
|
|
|
|
| 5.28, tensor (?), 04:45, 18/02/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> Если в системе <= 4GB, то наоборот нужно экономить память, а не жалкие проценты производительности процессора. Если начнется свопинг...
Немного оффтоп, но не мог не ответить. Если разница в потреблении и достигает 20-50 МБ ("копейки" для нынешних браузеров), что они вам дадут на десктопе? С одной стороны, если у вас забита память под завязку, а swappiness=0, то вам остаётся только лезть в tty и срочно дропать кэши/прибивать процессы - но зачем до такого доводить? С другой, лаги в 64-битной системе со свопом 3-5% от памяти вы, скорее всего, и не заметите.
А вообще, проще сменить ПО на более легковесное (DE, браузер, плеер), чем возвращаться к 32 битам и экономить на спичках.
| | |
| |
| 6.39, Аноним (-), 13:33, 18/02/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> А вообще, проще сменить ПО на более легковесное ( ... браузер ... )
Браузер? Угу, удачи. Оксюморон
| | |
| 6.40, Mihail Zenkov (ok), 13:48, 18/02/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> Если в системе <= 4GB, то наоборот нужно экономить память, а не жалкие проценты производительности процессора. Если начнется свопинг...
> Немного оффтоп, но не мог не ответить. Если разница в потреблении и
> достигает 20-50 МБ ("копейки" для нынешних браузеров), что они вам дадут
> на десктопе?
Не такие там и копейки - ссылка ниже.
> А вообще, проще сменить ПО на более легковесное (DE, браузер, плеер),
Это верно - почти всегда его использовал.
> чем возвращаться к 32 битам и экономить на спичках.
Мне не нужно возвращаться, я их до сих пор использую. На машине 4GB, без свопа. Пока для всех моих задач более чем достаточно. Сейчас запущен FF (облегченный), более 50 вкладок, реально использовал за этот сеанс 10 из них - памяти занято 346 MB (вся система + FF).
Будет нужно памяти 8GB или больше, тогда и перейду на 64 бита.
| | |
| |
| 7.49, count0krsk (ok), 17:24, 22/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
 Вот-вот. Аналогично.
Сейчас имею 6 Гб, и 32 бит хватает. С учетом того, что скоро и firefox/icecat будет многопроцессным, хватит ещё долго ))
А любители модных молодёжных 64бит пусть и дальше плачут над багами дров.
| | |
|
|
|
| 4.27, Прохожий (??), 04:02, 18/02/2015 [^] [^^] [^^^] [ответить]
| –1 +/– |
Не совсем так. Так или иначе все упирается не в регистровую память, а различные вычислительные блоки CPU. Кеш:L1, L2, L3... Размеры огромны, а скорость впечатляет. Большинство кода умещается именно там и ограничивается вычислительными возможностями CPU. Большее их количество и разрядность не делает операции с ними в два раза быстрее. Большинство программ просто не получат никакого преемущества от этого, за исключением узкого круга специализированного софта.
| | |
|
| 3.10, BratSinot (ok), 22:02, 17/02/2015 [^] [^^] [^^^] [ответить]
| +/– |
 В 1KiB влезает 128 64-битных указателя, а в 1Mib 131072 64-битных указателя, как вы думаете, большая разница в потреблении памяти будет?
Только вот в amd64 ABI в качестве FPU юзают SSE, а он, мягко говоря, быстрее работает, упоротого x87, плюс в два раза больше регистров общего назначения и XMM.
Ах да, еще и SSE/SSE2 100% есть, а не как любят собирать под i386 непонятно нафига.
| | |
| |
| 4.12, Mihail Zenkov (ok), 22:13, 17/02/2015 [^] [^^] [^^^] [ответить]
| –2 +/– |
> В 1KiB влезает 128 64-битных указателя, а в 1Mib 131072 64-битных указателя,
> как вы думаете, большая разница в потреблении памяти будет?
Было много проведено сравнений - для 64-битных программ идет существенно больше памяти.
> Только вот в amd64 ABI в качестве FPU юзают SSE, а он,
> мягко говоря, быстрее работает, упоротого x87,
-mfpmath=sse
> плюс в два раза больше
> регистров общего назначения и XMM.
Это да, существенный плюс.
> Ах да, еще и SSE/SSE2 100% есть, а не как любят собирать
> под i386 непонятно нафига.
Это только говорит об неадекватности собиравшнго. Или avx и прочие новинки будем использовать только после перехода на 128 бит?
| | |
| |
| 5.35, asdasd (?), 11:17, 18/02/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> Было много проведено сравнений - для 64-битных программ идет существенно больше памяти.
УМВРНЧЯДНТ?
> -mfpmath=sse
Не прокатит с системными либами.
| | |
| |
| 6.37, asdasd (?), 11:24, 18/02/2015 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Не прокатит с системными либами.
Забыл добавить, что возвращаемые значения все равно будут через x87.
| | |
|
|
| 4.16, Прохожий (??), 00:01, 18/02/2015 [^] [^^] [^^^] [ответить]
| –3 +/– |
Зачем спорить. На хабре была статья на примере php в Ubuntu i386\x86_64. В i386 потребляет почти в 2 раза меньше памяти. Можешь там попробовать втирать свой дзен.
| | |
| |
| 5.36, asdasd (?), 11:20, 18/02/2015 [^] [^^] [^^^] [ответить]
| +2 +/– | |
Во первых, ссылку пожалуйста, беглый поиск ничего не выдал.
Во вторых, сравнивать сервер и десктоп глупо.
На моей домашней машине любой дистрибутив не потребляет в два раза больше, пробовал Ubuntu, а пользуюсь Slackware. Собственно тот-же FireFox в i386 и amd64 редакции жрут одинакового дофига.
| | |
|
|
|
|
| |
| |
| 3.50, count0krsk (ok), 18:22, 22/02/2015 [^] [^^] [^^^] [ответить]
| +/– | |
> А если РАЕ?
Вроде до 32 Гб можно не заморачиваться, или 64. В-общем лет на 10 хватит, а там уже дистры перестанут собирать под i686.
| | |
|
|
| 1.44, ANONYM (?), 22:00, 18/02/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Они даже под винду делать не научились. Их устанощик последний раз работал только от администратора и ставился только в пользовательскую папку администратора и работал только от администратора. Такое ощущение что там и в линуксе все под рутом сидят.
| | |
| 1.45, ANONYM (?), 22:16, 18/02/2015 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Авторы такие наивные. Они всерьёз думают, что разрабы хромого будут тащить их код?
| | |
|
