Представленный (http://www.opennet.me/opennews/art.shtml?num=41546) в прошлом месяце web-браузер Vivaldi (https://vivaldi.net/), созданный под руководством бывшего руководителя Opera Software, теперь доступен (https://vivaldi.net/blogs/teamblog/item/7-new-snapshot-1-0-1...) и в 32-разрядных сборках для Linux. Изначально для Linux поставлялись только 64-разрядные сборки, но после многочисленных пожеланий разработчики пристипили к формированию 32-разрядных пакетов DEB (https://vivaldi.com/download/download.php?f=vivaldi-snapshot...) и RPM (https://vivaldi.com/download/download.php?f=vivaldi-snapshot...). Браузер построен с использованием web-движка Chromium и продолжает развитие идей классического раузера Opera, предоставляя широкий спектр возможностей и настроек.URL: http://www.webupd8.org/2015/02/vivaldi-browser-devs-add-32bi...
Новость: http://www.opennet.me/opennews/art.shtml?num=41681
Уже хорошо. Но проприетарщина все равно не нужна.
Кстати, да. Причём тут Опеннет и эта новость - непонятно.
Половина (если не больше) браузера открыта, модифицируй сколько хочется.
Нельзя быть слегка беременной, такие дела :)
Движок и без них был открытым, а вот вся остальная проприетарная надстройка (и следовательно вся программа в целом) доверия совершенно не заслуживает и противоречит этике и открытого, и свободного ПО.
Чтобы помнили.
Ну, как-то новости про обычный хром вместо изначального хромиума постят и ничё.
Пока этот браузер доведут до stable, из двух пользователей кому это надо было б, останется один, а второй уже перейдёт на 64 битную ОС.
Я буду ждать, так что всё-таки два, а не один
А я не буду. Так что все-таки один.
32 бита в 2015 году. Но зачем?
Чтоб не тратить на указателях в два раза больше ОЗУ.
Лучше поясните, зачем браузеру более 2ГБ ОЗУ. Одному процессу.
> Чтоб не тратить на указателях в два раза больше ОЗУ.
> Лучше поясните, зачем браузеру более 2ГБ ОЗУ. Одному процессу.Талантливые Веб-дизайнеры с модными CMS наперевес и больше памяти помогут схавать... Зато сайты да интернет-магазины быстро-быстро клепают - заказчик оглянуться не успеет, а оно уже готово.
Ничего, что в 32-х битной версии теряем на отсутствии операций над "широкими" регистрами? А также теряем целую кучу новых инструкций, дающих процентов 15 производительности просто на пустом месте?
На аудио/видео кодеках и то если повезет.Несколько спасает ситуацию большие количество регистров, а то на оборот могли бы на ряде задач худшую производительность наблюдать ибо кэш не резиновый.
Если в системе <= 4GB, то наоборот нужно экономить память, а не жалкие проценты производительности процессора. Если начнется свопинг ...
> Несколько спасает ситуацию большие количество регистровСпрашивал уже сколько раз, никто не отвечал толком: КАК спасёт ситуацию бОльшее количество регистров???
Современный код это по большей части лазанья-код, где "everything happens somewhere else", а значительное количество функций состоит просто из вызовов других функций и минимальной логики. БОльшее количество регистров всё равно придётся сохранять в стеке а потом восстанавливать, как и в случае с небольшим числом регистров.
Где я неправ?
> Спрашивал уже сколько раз, никто не отвечал толком: КАК спасёт ситуацию бОльшее
> количество регистров???Грубо говоря, каждой переменной в функции можно выделить свой регистр и не дергать обычную память лишний раз.
> значительное количество функций состоит просто из вызовов других функций и минимальной логики
Если функции действительно простые, то компилятор будет пытаться делать из них более сложные (inline) дабы экономить на переходах.
> Грубо говоря, каждой переменной в функции можно выделить свой регистрЭто я понимаю.
Но перед каждым вызовом подфункции придётся этот регистр сохранять в стеке а потом - восстанавливать, иначе вызываемая функция может этот регистр перезатереть. Либо, если соглашение о вызове другое, сохранять в стеке модифицируемые регистры придётся самой вызываемой функции. Но в любом случае это запись в стек.
inline-функции это действительно оптимизируют, но... неужели inline-функции (в том числе те, что компилятор сам заинлайнил) действительно дают настолько большой эффект?
> Но перед каждым вызовом подфункции придётся этот регистр сохранять в стеке а
> потом - восстанавливать, иначе вызываемая функция может этот регистр перезатереть. Либо,
> если соглашение о вызове другое, сохранять в стеке модифицируемые регистры придётся
> самой вызываемой функции. Но в любом случае это запись в стек.Не совсем так - если рассматривать самый простой случай (один поток, без прерываний), компилятор просто передаст регистр(ы) в качестве аргумента вызываемой функции и постарается использовать еще не задействованные регистры. Тут их количество и сыграет решающую роль.
> inline-функции это действительно оптимизируют, но... неужели inline-функции (в том числе
> те, что компилятор сам заинлайнил) действительно дают настолько большой эффект?На микроконтроллерах inline - просто сказка, без него о нормальной скорости можно забыть.
На pc - эффект может быть разный, смотря что именно удалось встроить/развернуть. Например сборка pango с -march=native -mmmx -msse -msse2 -msse3 -msse4a -O3 -mfpmath=sse дает двукратный приросты в gtkperf на тесте текста. Что там точно происходит я не изучал. А так в среднем прирост 5-10%. Но тут конечно больше автовекторизация дает эффект.
> компилятор просто передаст регистр(ы) в качестве аргумента вызываемой функции
> и постарается использовать еще не задействованные регистры. Тут их количество и
> сыграет решающую роль.Возможно, вы меня не так поняли (или я вас). Я говорю не о передаче через регистры параметров. Давайте лучше на примере.
Пусть у нас есть функции void f(void) и void g(void):
void f (void) {
for (int i = 0; i != 10; ++i)
g();
}Допустим компилятор решает хранить переменную i в регистре %rdi. Однако функция g тоже может использовать этот регистр, и его состояние надо сохранить на время её вызова. Тут есть два варианта того, какое соглашение принято (не знаю, какой из них применяется на практике, возможно даже в разных ОС применяются разные).
1 вариант. За сохранение регистров отвечает вызывающая функция (та, чьё значение должно быть сохранено). То есть функция заботится о сохранении своих локальных переменных. В таком случае f будет выглядеть как-то так (грубо, просто чтоб смысл объяснить):
f:
movl $0, %rdi
f_loop:
cmpl %rdi, $10
je f_returnpushl %rdi ; сохранить регистр, так как g может его поменять
call g
popl %rdi ; восстановить значение
incl %rdi
jmp f_loop
f_return
ret2 вариант. За сохранение регистров отвечает вызываемая функция (та, которая использует регистр). То есть функция заботится о сохранении чужих локальных переменных, которые она может затереть.
f:
pushl %rdi; сохранить регистр, так как он может использоваться внешней функцией
movl $0, %rdi
f_loop:
cmpl %rdi, $10
je f_returncall g
incl %rdi
jmp f_loop
f_return
popl %rdi ; восстановить значение, потенциально используемое внешней функцией
retВо-первых, в любом случае есть как минимум одно сохранение-восстановление из стека. Во-вторых, если вместо стека мы попытаемся использовать другой, "неиспользуемый", регистр (например, %rsi), то тогда в стек придётся сохранять его, %rsi, значение.
Можно ли как-то оптимизировать этот случай (кроме inline)?
> Допустим компилятор решает хранить переменную i в регистре %rdi. Однако функция g
> тоже может использовать этот регистр, и его состояние надо сохранить на
> время её вызова.ИМХО компилятор постарается хранить все переменные в разных регистрах - соответственно он либо возьмет другой регистр для i либо для функции g - смотря что собрал первым. Зачем что либо сохранять/восстанавливать, пока есть свободные регистры?
Еще гляньте -frename-registers в man gcc.
> Можно ли как-то оптимизировать этот случай (кроме inline)?
Inline больше нужен для выкидывания переходов и случаев типа:
void f() {
mode(0);
...
mode(1);
}void mode(int m) {
...
if (m) {
...
} else {
...
}
}Соответственно можно вставить часть функции mode и выкинуть проверку if (m) еще на стадии компиляции.
> он либо возьмет другой регистр для i либо для функции gТак в общем случае при компиляции g компилятор не может знать, какие регистры будут использоваться вызывающими её функциями, такими как f.
поэтому использует имена абстрактных регистров, а когда ведет генерацию кода - получает ограничения на использование реальных и генерит код под эти ограничения.
> Если в системе <= 4GB, то наоборот нужно экономить память, а не жалкие проценты производительности процессора. Если начнется свопинг...Немного оффтоп, но не мог не ответить. Если разница в потреблении и достигает 20-50 МБ ("копейки" для нынешних браузеров), что они вам дадут на десктопе? С одной стороны, если у вас забита память под завязку, а swappiness=0, то вам остаётся только лезть в tty и срочно дропать кэши/прибивать процессы - но зачем до такого доводить? С другой, лаги в 64-битной системе со свопом 3-5% от памяти вы, скорее всего, и не заметите.
А вообще, проще сменить ПО на более легковесное (DE, браузер, плеер), чем возвращаться к 32 битам и экономить на спичках.
> А вообще, проще сменить ПО на более легковесное ( ... браузер ... )Браузер? Угу, удачи. Оксюморон
>> Если в системе <= 4GB, то наоборот нужно экономить память, а не жалкие проценты производительности процессора. Если начнется свопинг...
> Немного оффтоп, но не мог не ответить. Если разница в потреблении и
> достигает 20-50 МБ ("копейки" для нынешних браузеров), что они вам дадут
> на десктопе?Не такие там и копейки - ссылка ниже.
> А вообще, проще сменить ПО на более легковесное (DE, браузер, плеер),
Это верно - почти всегда его использовал.
> чем возвращаться к 32 битам и экономить на спичках.
Мне не нужно возвращаться, я их до сих пор использую. На машине 4GB, без свопа. Пока для всех моих задач более чем достаточно. Сейчас запущен FF (облегченный), более 50 вкладок, реально использовал за этот сеанс 10 из них - памяти занято 346 MB (вся система + FF).
Будет нужно памяти 8GB или больше, тогда и перейду на 64 бита.
Вот-вот. Аналогично.
Сейчас имею 6 Гб, и 32 бит хватает. С учетом того, что скоро и firefox/icecat будет многопроцессным, хватит ещё долго ))
А любители модных молодёжных 64бит пусть и дальше плачут над багами дров.
Не совсем так. Так или иначе все упирается не в регистровую память, а различные вычислительные блоки CPU. Кеш:L1, L2, L3... Размеры огромны, а скорость впечатляет. Большинство кода умещается именно там и ограничивается вычислительными возможностями CPU. Большее их количество и разрядность не делает операции с ними в два раза быстрее. Большинство программ просто не получат никакого преемущества от этого, за исключением узкого круга специализированного софта.
В 1KiB влезает 128 64-битных указателя, а в 1Mib 131072 64-битных указателя, как вы думаете, большая разница в потреблении памяти будет?Только вот в amd64 ABI в качестве FPU юзают SSE, а он, мягко говоря, быстрее работает, упоротого x87, плюс в два раза больше регистров общего назначения и XMM.
Ах да, еще и SSE/SSE2 100% есть, а не как любят собирать под i386 непонятно нафига.
> В 1KiB влезает 128 64-битных указателя, а в 1Mib 131072 64-битных указателя,
> как вы думаете, большая разница в потреблении памяти будет?Было много проведено сравнений - для 64-битных программ идет существенно больше памяти.
> Только вот в amd64 ABI в качестве FPU юзают SSE, а он,
> мягко говоря, быстрее работает, упоротого x87,-mfpmath=sse
> плюс в два раза больше
> регистров общего назначения и XMM.Это да, существенный плюс.
> Ах да, еще и SSE/SSE2 100% есть, а не как любят собирать
> под i386 непонятно нафига.Это только говорит об неадекватности собиравшнго. Или avx и прочие новинки будем использовать только после перехода на 128 бит?
> Было много проведено сравнений - для 64-битных программ идет существенно больше памяти.УМВРНЧЯДНТ?
> -mfpmath=sse
Не прокатит с системными либами.
> Не прокатит с системными либами.Забыл добавить, что возвращаемые значения все равно будут через x87.
>> Было много проведено сравнений - для 64-битных программ идет существенно больше памяти.
> УМВРНЧЯДНТ?http://askubuntu.com/questions/7034/what-are-the-differences...
>> -mfpmath=sse
> Не прокатит с системными либами.Это что за библиотеки такие? У меня так вся система (lfs) собрана.
Зачем спорить. На хабре была статья на примере php в Ubuntu i386\x86_64. В i386 потребляет почти в 2 раза меньше памяти. Можешь там попробовать втирать свой дзен.
Во первых, ссылку пожалуйста, беглый поиск ничего не выдал.Во вторых, сравнивать сервер и десктоп глупо.
На моей домашней машине любой дистрибутив не потребляет в два раза больше, пробовал Ubuntu, а пользуюсь Slackware. Собственно тот-же FireFox в i386 и amd64 редакции жрут одинакового дофига.
Наверно, речь об этом: http://habrahabr.ru/post/161629/
Gentoo forever! :D
Для 4GB и меньше - только i386. Сборка актуальна.
А если РАЕ?
> А если РАЕ?Вроде до 32 Гб можно не заморачиваться, или 64. В-общем лет на 10 хватит, а там уже дистры перестанут собирать под i686.
Оно же не умеет fit-to-width?
Эм.. Оно только у меня в openSUSE хочет Qt3 или нет?
Наверное только у тебя. У меня поставилось без зависимостей.
"Подогнать по ширине" появилась?
Они даже под винду делать не научились. Их устанощик последний раз работал только от администратора и ставился только в пользовательскую папку администратора и работал только от администратора. Такое ощущение что там и в линуксе все под рутом сидят.
Авторы такие наивные. Они всерьёз думают, что разрабы хромого будут тащить их код?