forum.opennet.ru - "Началось формирование 32-разрядых Linux-сборок браузера Vivaldi" (45)

форумы

помощь

поиск

регистрация

майллист

вход/выход

слежка

"Началось формирование 32-разрядых Linux-сборок браузера Vivaldi"

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Началось формирование 32-разрядых Linux-сборок браузера Vivaldi"	+/–
Сообщение от opennews (??) on 17-Фев-15, 19:30
Представленный (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
Ответить \| Правка \| Cообщить модератору

Оглавление

Началось формирование 32-разрядых Linux-сборок браузера Viva..., Аноним, 19:30 , 17-Фев-15, (1) +9

Началось формирование 32-разрядых Linux-сборок браузера Viva..., th3m3, 19:35 , 17-Фев-15, (2) +5

Началось формирование 32-разрядых Linux-сборок браузера Viva..., Аноним, 20:13 , 17-Фев-15, (3) +1

Началось формирование 32-разрядых Linux-сборок браузера Viva..., Аноним, 00:26 , 18-Фев-15, (20) +13
Началось формирование 32-разрядых Linux-сборок браузера Viva..., Tav, 00:26 , 18-Фев-15, (21) +6

Началось формирование 32-разрядых Linux-сборок браузера Viva..., Абвгдеёж, 20:21 , 17-Фев-15, (5) +1
Началось формирование 32-разрядых Linux-сборок браузера Viva..., Аноним, 12:16 , 22-Фев-15, (48)

Началось формирование 32-разрядых Linux-сборок браузера Viva..., soarin, 20:19 , 17-Фев-15, (4) +3

Началось формирование 32-разрядых Linux-сборок браузера Viva..., Анононо, 10:29 , 18-Фев-15, (32)

Началось формирование 32-разрядых Linux-сборок браузера Viva..., Аноним, 23:44 , 18-Фев-15, (46) +1

Началось формирование 32-разрядых Linux-сборок браузера Viva..., Аноним, 20:33 , 17-Фев-15, (6)

Началось формирование 32-разрядых Linux-сборок браузера Viva..., Омоним, 20:45 , 17-Фев-15, (7) +5

Началось формирование 32-разрядых Linux-сборок браузера Viva..., vlikhachev, 21:09 , 17-Фев-15, (8) +1
Началось формирование 32-разрядых Linux-сборок браузера Viva..., Аноним, 21:26 , 17-Фев-15, (9)

Началось формирование 32-разрядых Linux-сборок браузера Viva..., Mihail Zenkov, 22:05 , 17-Фев-15, (11) +1

Началось формирование 32-разрядых Linux-сборок браузера Viva..., да я же, 23:29 , 17-Фев-15, (13)

Началось формирование 32-разрядых Linux-сборок браузера Viva..., Mihail Zenkov, 23:43 , 17-Фев-15, (15)

Началось формирование 32-разрядых Linux-сборок браузера Viva..., да я же, 00:10 , 18-Фев-15, (18) –1

Началось формирование 32-разрядых Linux-сборок браузера Viva..., Mihail Zenkov, 00:36 , 18-Фев-15, (22)

Началось формирование 32-разрядых Linux-сборок браузера Viva..., да я же, 01:25 , 18-Фев-15, (24) –1

Началось формирование 32-разрядых Linux-сборок браузера Viva..., Mihail Zenkov, 01:59 , 18-Фев-15, (25)

Началось формирование 32-разрядых Linux-сборок браузера Viva..., да я же, 10:30 , 18-Фев-15, (33) –1

Началось формирование 32-разрядых Linux-сборок браузера Viva..., Аноним, 16:52 , 18-Фев-15, (43)

Началось формирование 32-разрядых Linux-сборок браузера Viva..., tensor, 04:45 , 18-Фев-15, (28)

Началось формирование 32-разрядых Linux-сборок браузера Viva..., Аноним, 13:33 , 18-Фев-15, (39)
Началось формирование 32-разрядых Linux-сборок браузера Viva..., Mihail Zenkov, 13:48 , 18-Фев-15, (40) –1

Началось формирование 32-разрядых Linux-сборок браузера Viva..., count0krsk, 17:24 , 22-Фев-15, (49)

Началось формирование 32-разрядых Linux-сборок браузера Viva..., Прохожий, 04:02 , 18-Фев-15, (27) –1

Началось формирование 32-разрядых Linux-сборок браузера Viva..., BratSinot, 22:02 , 17-Фев-15, (10)

Началось формирование 32-разрядых Linux-сборок браузера Viva..., Mihail Zenkov, 22:13 , 17-Фев-15, (12) –2

Началось формирование 32-разрядых Linux-сборок браузера Viva..., asdasd, 11:17 , 18-Фев-15, (35)

Началось формирование 32-разрядых Linux-сборок браузера Viva..., asdasd, 11:24 , 18-Фев-15, (37) –1
Началось формирование 32-разрядых Linux-сборок браузера Viva..., Mihail Zenkov, 13:31 , 18-Фев-15, (38) –1

Началось формирование 32-разрядых Linux-сборок браузера Viva..., Прохожий, 00:01 , 18-Фев-15, (16) –3

Началось формирование 32-разрядых Linux-сборок браузера Viva..., asdasd, 11:20 , 18-Фев-15, (36) +2

Началось формирование 32-разрядых Linux-сборок браузера Viva..., Аноним, 01:16 , 19-Фев-15, (47) –1

Началось формирование 32-разрядых Linux-сборок браузера Viva..., Прохожий, 00:04 , 18-Фев-15, (17) +2

Началось формирование 32-разрядых Linux-сборок браузера Viva..., нано анон, 06:14 , 18-Фев-15, (31)

Началось формирование 32-разрядых Linux-сборок браузера Viva..., count0krsk, 18:22 , 22-Фев-15, (50)

Началось формирование 32-разрядых Linux-сборок браузера Viva..., Аноним, 00:22 , 18-Фев-15, (19)
Началось формирование 32-разрядых Linux-сборок браузера Viva..., Аноним, 00:36 , 18-Фев-15, (23)

Началось формирование 32-разрядых Linux-сборок браузера Viva..., milinsky, 03:19 , 18-Фев-15, (26) –1

Началось формирование 32-разрядых Linux-сборок браузера Viva..., Typhoon, 16:35 , 18-Фев-15, (42) –1
Началось формирование 32-разрядых Linux-сборок браузера Viva..., ANONYM, 22:00 , 18-Фев-15, (44)
Началось формирование 32-разрядых Linux-сборок браузера Viva..., ANONYM, 22:16 , 18-Фев-15, (45)

Сообщения по теме [Сортировка по времени | RSS]

1. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +9 +/–

Сообщение от Аноним (??) on 17-Фев-15, 19:30

Уже хорошо. Но проприетарщина все равно не нужна.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +5 +/–

Сообщение от th3m3 (ok) on 17-Фев-15, 19:35

Кстати, да. Причём тут Опеннет и эта новость - непонятно.

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +1 +/–

Сообщение от Аноним (??) on 17-Фев-15, 20:13

Половина (если не больше) браузера открыта, модифицируй сколько хочется.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

20. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +13 +/–

Сообщение от Аноним (??) on 18-Фев-15, 00:26

Нельзя быть слегка беременной, такие дела :)

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

21. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +6 +/–

Сообщение от Tav (ok) on 18-Фев-15, 00:26

Движок и без них был открытым, а вот вся остальная проприетарная надстройка (и следовательно вся программа в целом) доверия совершенно не заслуживает и противоречит этике и открытого, и свободного ПО.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

5. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +1 +/–

Сообщение от Абвгдеёж on 17-Фев-15, 20:21

Чтобы помнили.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

48. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +/–

Сообщение от Аноним (??) on 22-Фев-15, 12:16

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

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

4. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +3 +/–

Сообщение от soarin on 17-Фев-15, 20:19

Пока этот браузер доведут до stable, из двух пользователей кому это надо было б, останется один, а второй уже перейдёт на 64 битную ОС.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

32. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +/–

Сообщение от Анононо on 18-Фев-15, 10:29

Я буду ждать, так что всё-таки два, а не один

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

46. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +1 +/–

Сообщение от Аноним (??) on 18-Фев-15, 23:44

А я не буду. Так что все-таки один.

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

6. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +/–

Сообщение от Аноним (??) on 17-Фев-15, 20:33

32 бита в 2015 году. Но зачем?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

7. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +5 +/–

Сообщение от Омоним on 17-Фев-15, 20:45

Чтоб не тратить на указателях в два раза больше ОЗУ.
Лучше поясните, зачем браузеру более 2ГБ ОЗУ. Одному процессу.

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

8. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +1 +/–

Сообщение от vlikhachev (ok) on 17-Фев-15, 21:09

> Чтоб не тратить на указателях в два раза больше ОЗУ.
> Лучше поясните, зачем браузеру более 2ГБ ОЗУ. Одному процессу.
Талантливые Веб-дизайнеры с модными CMS наперевес и больше памяти помогут схавать... Зато сайты да интернет-магазины быстро-быстро клепают - заказчик оглянуться не успеет, а оно уже готово.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

9. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +/–

Сообщение от Аноним (??) on 17-Фев-15, 21:26

Ничего, что в 32-х битной версии теряем на отсутствии операций над "широкими" регистрами? А также теряем целую кучу новых инструкций, дающих процентов 15 производительности просто на пустом месте?

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

11. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +1 +/–

Сообщение от Mihail Zenkov (ok) on 17-Фев-15, 22:05

На аудио/видео кодеках и то если повезет.
Несколько спасает ситуацию большие количество регистров, а то на оборот могли бы на ряде задач худшую производительность наблюдать ибо кэш не резиновый.
Если в системе <= 4GB, то наоборот нужно экономить память, а не жалкие проценты производительности процессора. Если начнется свопинг ...

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

13. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +/–

Сообщение от да я же on 17-Фев-15, 23:29

> Несколько спасает ситуацию большие количество регистров
Спрашивал уже сколько раз, никто не отвечал толком: КАК спасёт ситуацию бОльшее количество регистров???
Современный код это по большей части лазанья-код, где "everything happens somewhere else", а значительное количество функций состоит просто из вызовов других функций и минимальной логики. БОльшее количество регистров всё равно придётся сохранять в стеке а потом восстанавливать, как и в случае с небольшим числом регистров.
Где я неправ?

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

15. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +/–

Сообщение от Mihail Zenkov (ok) on 17-Фев-15, 23:43

> Спрашивал уже сколько раз, никто не отвечал толком: КАК спасёт ситуацию бОльшее
> количество регистров???
Грубо говоря, каждой переменной в функции можно выделить свой регистр и не дергать обычную память лишний раз.
>  значительное количество функций состоит просто из вызовов других функций и минимальной логики
Если функции действительно простые, то компилятор будет пытаться делать из них более сложные (inline) дабы экономить на переходах.

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

18. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." –1 +/–

Сообщение от да я же on 18-Фев-15, 00:10

> Грубо говоря, каждой переменной в функции можно выделить свой регистр
Это я понимаю.
Но перед каждым вызовом подфункции придётся этот регистр сохранять в стеке а потом - восстанавливать, иначе вызываемая функция может этот регистр перезатереть. Либо, если соглашение о вызове другое, сохранять в стеке модифицируемые регистры придётся самой вызываемой функции. Но в любом случае это запись в стек.
inline-функции это действительно оптимизируют, но... неужели inline-функции (в том числе те, что компилятор сам заинлайнил) действительно дают настолько большой эффект?

Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

22. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +/–

Сообщение от Mihail Zenkov (ok) on 18-Фев-15, 00:36

> Но перед каждым вызовом подфункции придётся этот регистр сохранять в стеке а
> потом - восстанавливать, иначе вызываемая функция может этот регистр перезатереть. Либо,
> если соглашение о вызове другое, сохранять в стеке модифицируемые регистры придётся
> самой вызываемой функции. Но в любом случае это запись в стек.
Не совсем так - если рассматривать самый простой случай (один поток, без прерываний), компилятор просто передаст регистр(ы) в качестве аргумента вызываемой функции и постарается использовать еще не задействованные регистры. Тут их количество и сыграет решающую роль.
> inline-функции это действительно оптимизируют, но... неужели inline-функции (в том числе
> те, что компилятор сам заинлайнил) действительно дают настолько большой эффект?
На микроконтроллерах inline - просто сказка, без него о нормальной скорости можно забыть.
На pc - эффект может быть разный, смотря что именно удалось встроить/развернуть. Например сборка pango с -march=native -mmmx -msse -msse2 -msse3 -msse4a -O3 -mfpmath=sse дает двукратный приросты в gtkperf на тесте текста. Что там точно происходит я не изучал. А так в среднем прирост 5-10%. Но тут конечно больше автовекторизация дает эффект.

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

24. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." –1 +/–

Сообщение от да я же on 18-Фев-15, 01:25

> компилятор просто передаст регистр(ы) в качестве аргумента вызываемой функции
> и постарается использовать еще не задействованные регистры. Тут их количество и
> сыграет решающую роль.
Возможно, вы меня не так поняли (или я вас). Я говорю не о передаче через регистры параметров. Давайте лучше на примере.
Пусть у нас есть функции 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_return
    pushl %rdi ; сохранить регистр, так как g может его поменять
    call g
    popl %rdi ; восстановить значение
    incl %rdi
    jmp f_loop
f_return
    ret
2 вариант. За сохранение регистров отвечает вызываемая функция (та, которая использует регистр). То есть функция заботится о сохранении чужих локальных переменных, которые она может затереть.
f:
    pushl %rdi; сохранить регистр, так как он может использоваться внешней функцией
    movl $0, %rdi
f_loop:
    cmpl %rdi, $10
    je f_return
    call g
    incl %rdi
    jmp f_loop
f_return
    popl %rdi ; восстановить значение, потенциально используемое внешней функцией
    ret
Во-первых, в любом случае есть как минимум одно сохранение-восстановление из стека. Во-вторых, если вместо стека мы попытаемся использовать другой, "неиспользуемый", регистр (например, %rsi), то тогда в стек придётся сохранять его, %rsi, значение.
Можно ли как-то оптимизировать этот случай (кроме inline)?

Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

25. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +/–

Сообщение от Mihail Zenkov (ok) on 18-Фев-15, 01:59

> Допустим компилятор решает хранить переменную 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) еще на стадии компиляции.

Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

33. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." –1 +/–

Сообщение от да я же on 18-Фев-15, 10:30

> он либо возьмет другой регистр для i либо для функции g
Так в общем случае при компиляции g компилятор не может знать, какие регистры будут использоваться вызывающими её функциями, такими как f.

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

43. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +/–

Сообщение от Аноним (??) on 18-Фев-15, 16:52

поэтому использует имена абстрактных регистров, а когда ведет генерацию кода - получает ограничения на использование реальных и генерит код под эти ограничения.

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

28. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +/–

Сообщение от tensor on 18-Фев-15, 04:45

> Если в системе <= 4GB, то наоборот нужно экономить память, а не жалкие проценты производительности процессора. Если начнется свопинг...
Немного оффтоп, но не мог не ответить. Если разница в потреблении и достигает 20-50 МБ ("копейки" для нынешних браузеров), что они вам дадут на десктопе? С одной стороны, если у вас забита память под завязку, а swappiness=0, то вам остаётся только лезть в tty и срочно дропать кэши/прибивать процессы - но зачем до такого доводить? С другой, лаги в 64-битной системе со свопом 3-5% от памяти вы, скорее всего, и не заметите.
А вообще, проще сменить ПО на более легковесное (DE, браузер, плеер), чем возвращаться к 32 битам и экономить на спичках.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

39. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +/–

Сообщение от Аноним (??) on 18-Фев-15, 13:33

> А вообще, проще сменить ПО на более легковесное ( ... браузер ... )
Браузер? Угу, удачи. Оксюморон

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

40. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." –1 +/–

Сообщение от Mihail Zenkov (ok) on 18-Фев-15, 13:48

>> Если в системе <= 4GB, то наоборот нужно экономить память, а не жалкие проценты производительности процессора. Если начнется свопинг...
> Немного оффтоп, но не мог не ответить. Если разница в потреблении и
> достигает 20-50 МБ ("копейки" для нынешних браузеров), что они вам дадут
> на десктопе?
Не такие там и копейки - ссылка ниже.
> А вообще, проще сменить ПО на более легковесное (DE, браузер, плеер),
Это верно - почти всегда его использовал.
> чем возвращаться к 32 битам и экономить на спичках.
Мне не нужно возвращаться, я их до сих пор использую. На машине 4GB, без свопа. Пока для всех моих задач более чем достаточно. Сейчас запущен FF (облегченный), более 50 вкладок, реально использовал за этот сеанс 10 из них - памяти занято 346 MB (вся система + FF).
Будет нужно памяти 8GB или больше, тогда и перейду на 64 бита.

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

49. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +/–

Сообщение от count0krsk (ok) on 22-Фев-15, 17:24

Вот-вот. Аналогично.
Сейчас имею 6 Гб, и 32 бит хватает. С учетом того, что скоро и firefox/icecat будет многопроцессным, хватит ещё долго ))
А любители модных молодёжных 64бит пусть и дальше плачут над багами дров.

Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

27. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." –1 +/–

Сообщение от Прохожий (??) on 18-Фев-15, 04:02

Не совсем так. Так или иначе все упирается не в регистровую память, а различные вычислительные блоки CPU. Кеш:L1, L2, L3... Размеры огромны, а скорость впечатляет. Большинство кода умещается именно там и ограничивается вычислительными возможностями CPU. Большее их количество и разрядность не делает операции с ними в два раза быстрее. Большинство программ просто не получат никакого преемущества от этого, за исключением узкого круга специализированного софта.

Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

10. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +/–

Сообщение от BratSinot (ok) on 17-Фев-15, 22:02

В 1KiB влезает 128 64-битных указателя, а в 1Mib 131072 64-битных указателя, как вы думаете, большая разница в потреблении памяти будет?
Только вот в amd64 ABI в качестве FPU юзают SSE, а он, мягко говоря, быстрее работает, упоротого x87, плюс в два раза больше регистров общего назначения и XMM.
Ах да, еще и SSE/SSE2 100% есть, а не как любят собирать под i386 непонятно нафига.

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

12. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." –2 +/–

Сообщение от Mihail Zenkov (ok) on 17-Фев-15, 22:13

> В 1KiB влезает 128 64-битных указателя, а в 1Mib 131072 64-битных указателя,
> как вы думаете, большая разница в потреблении памяти будет?
Было много проведено сравнений - для 64-битных программ идет существенно больше памяти.
> Только вот в amd64 ABI в качестве FPU юзают SSE, а он,
> мягко говоря, быстрее работает, упоротого x87,
-mfpmath=sse
> плюс в два раза больше
> регистров общего назначения и XMM.
Это да, существенный плюс.
> Ах да, еще и SSE/SSE2 100% есть, а не как любят собирать
> под i386 непонятно нафига.
Это только говорит об неадекватности собиравшнго. Или avx и прочие новинки будем использовать только после перехода на 128 бит?

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

35. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +/–

Сообщение от asdasd on 18-Фев-15, 11:17

> Было много проведено сравнений - для 64-битных программ идет существенно больше памяти.
УМВРНЧЯДНТ?
> -mfpmath=sse
Не прокатит с системными либами.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

37. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." –1 +/–

Сообщение от asdasd on 18-Фев-15, 11:24

> Не прокатит с системными либами.
Забыл добавить, что возвращаемые значения все равно будут через x87.

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

38. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." –1 +/–

Сообщение от Mihail Zenkov (ok) on 18-Фев-15, 13:31

>> Было много проведено сравнений - для 64-битных программ идет существенно больше памяти.
> УМВРНЧЯДНТ?
http://askubuntu.com/questions/7034/what-are-the-differences...
>> -mfpmath=sse
> Не прокатит с системными либами.
Это что за библиотеки такие? У меня так вся система (lfs) собрана.

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

16. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." –3 +/–

Сообщение от Прохожий (??) on 18-Фев-15, 00:01

Зачем спорить. На хабре была статья на примере php в Ubuntu i386\x86_64. В i386 потребляет почти в 2 раза меньше памяти. Можешь там попробовать втирать свой дзен.

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

36. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +2 +/–

Сообщение от asdasd on 18-Фев-15, 11:20

Во первых, ссылку пожалуйста, беглый поиск ничего не выдал.
Во вторых, сравнивать сервер и десктоп глупо.
На моей домашней машине любой дистрибутив не потребляет в два раза больше, пробовал Ubuntu, а пользуюсь Slackware. Собственно тот-же FireFox в i386 и amd64 редакции жрут одинакового дофига.

Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

47. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." –1 +/–

Сообщение от Аноним (??) on 19-Фев-15, 01:16

Наверно, речь об этом: http://habrahabr.ru/post/161629/
Gentoo forever! :D

Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

17. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +2 +/–

Сообщение от Прохожий (??) on 18-Фев-15, 00:04

Для 4GB и меньше - только i386. Сборка актуальна.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

31. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +/–

Сообщение от нано анон on 18-Фев-15, 06:14

А если РАЕ?

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

50. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +/–

Сообщение от count0krsk (ok) on 22-Фев-15, 18:22

> А если РАЕ?
Вроде до 32 Гб можно не заморачиваться, или 64. В-общем лет на 10 хватит, а там уже дистры перестанут собирать под i686.

Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

19. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +/–

Сообщение от Аноним (??) on 18-Фев-15, 00:22

Оно же не умеет fit-to-width?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

23. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +/–

Сообщение от Аноним (??) on 18-Фев-15, 00:36

Эм.. Оно только у меня в openSUSE хочет Qt3 или нет?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

26. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." –1 +/–

Сообщение от milinsky (ok) on 18-Фев-15, 03:19

Наверное только у тебя. У меня поставилось без зависимостей.

Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

42. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." –1 +/–

Сообщение от Typhoon (ok) on 18-Фев-15, 16:35

"Подогнать по ширине" появилась?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

44. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +/–

Сообщение от ANONYM on 18-Фев-15, 22:00

Они даже под винду делать не научились. Их устанощик последний раз работал только от администратора и ставился только в пользовательскую папку администратора и работал только от администратора. Такое ощущение что там и в линуксе все под рутом сидят.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

45. "Началось формирование 32-разрядых Linux-сборок браузера Viva..." +/–

Сообщение от ANONYM on 18-Фев-15, 22:16

Авторы такие наивные. Они всерьёз думают, что разрабы хромого будут тащить их код?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	+9 +/–
Сообщение от Аноним (??) on 17-Фев-15, 19:30
Уже хорошо. Но проприетарщина все равно не нужна.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	2. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	+5 +/–
	Сообщение от th3m3 (ok) on 17-Фев-15, 19:35
	Кстати, да. Причём тут Опеннет и эта новость - непонятно.
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	3. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	+1 +/–
	Сообщение от Аноним (??) on 17-Фев-15, 20:13
	Половина (если не больше) браузера открыта, модифицируй сколько хочется.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	20. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	+13 +/–
	Сообщение от Аноним (??) on 18-Фев-15, 00:26
	Нельзя быть слегка беременной, такие дела :)
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	21. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	+6 +/–
	Сообщение от Tav (ok) on 18-Фев-15, 00:26
	Движок и без них был открытым, а вот вся остальная проприетарная надстройка (и следовательно вся программа в целом) доверия совершенно не заслуживает и противоречит этике и открытого, и свободного ПО.
	Ответить \| Правка \| ^ к родителю #3 \| Наверх \| Cообщить модератору


	5. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	+1 +/–
	Сообщение от Абвгдеёж on 17-Фев-15, 20:21
	Чтобы помнили.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	48. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	+/–
	Сообщение от Аноним (??) on 22-Фев-15, 12:16
	Ну, как-то новости про обычный хром вместо изначального хромиума постят и ничё.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору

4. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	+3 +/–
Сообщение от soarin on 17-Фев-15, 20:19
Пока этот браузер доведут до stable, из двух пользователей кому это надо было б, останется один, а второй уже перейдёт на 64 битную ОС.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	32. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	+/–
	Сообщение от Анононо on 18-Фев-15, 10:29
	Я буду ждать, так что всё-таки два, а не один
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	46. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	+1 +/–
	Сообщение от Аноним (??) on 18-Фев-15, 23:44
	А я не буду. Так что все-таки один.
	Ответить \| Правка \| ^ к родителю #32 \| Наверх \| Cообщить модератору

6. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	+/–
Сообщение от Аноним (??) on 17-Фев-15, 20:33
32 бита в 2015 году. Но зачем?
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	7. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	+5 +/–
	Сообщение от Омоним on 17-Фев-15, 20:45
	Чтоб не тратить на указателях в два раза больше ОЗУ. Лучше поясните, зачем браузеру более 2ГБ ОЗУ. Одному процессу.
	Ответить \| Правка \| ^ к родителю #6 \| Наверх \| Cообщить модератору


	8. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	+1 +/–
	Сообщение от vlikhachev (ok) on 17-Фев-15, 21:09
	> Чтоб не тратить на указателях в два раза больше ОЗУ. > Лучше поясните, зачем браузеру более 2ГБ ОЗУ. Одному процессу. Талантливые Веб-дизайнеры с модными CMS наперевес и больше памяти помогут схавать... Зато сайты да интернет-магазины быстро-быстро клепают - заказчик оглянуться не успеет, а оно уже готово.
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	9. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	+/–
	Сообщение от Аноним (??) on 17-Фев-15, 21:26
	Ничего, что в 32-х битной версии теряем на отсутствии операций над "широкими" регистрами? А также теряем целую кучу новых инструкций, дающих процентов 15 производительности просто на пустом месте?
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	11. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	+1 +/–
	Сообщение от Mihail Zenkov (ok) on 17-Фев-15, 22:05
	На аудио/видео кодеках и то если повезет. Несколько спасает ситуацию большие количество регистров, а то на оборот могли бы на ряде задач худшую производительность наблюдать ибо кэш не резиновый. Если в системе <= 4GB, то наоборот нужно экономить память, а не жалкие проценты производительности процессора. Если начнется свопинг ...
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	13. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	+/–
	Сообщение от да я же on 17-Фев-15, 23:29
	> Несколько спасает ситуацию большие количество регистров Спрашивал уже сколько раз, никто не отвечал толком: КАК спасёт ситуацию бОльшее количество регистров??? Современный код это по большей части лазанья-код, где "everything happens somewhere else", а значительное количество функций состоит просто из вызовов других функций и минимальной логики. БОльшее количество регистров всё равно придётся сохранять в стеке а потом восстанавливать, как и в случае с небольшим числом регистров. Где я неправ?
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	15. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	+/–
	Сообщение от Mihail Zenkov (ok) on 17-Фев-15, 23:43
	> Спрашивал уже сколько раз, никто не отвечал толком: КАК спасёт ситуацию бОльшее > количество регистров??? Грубо говоря, каждой переменной в функции можно выделить свой регистр и не дергать обычную память лишний раз. > значительное количество функций состоит просто из вызовов других функций и минимальной логики Если функции действительно простые, то компилятор будет пытаться делать из них более сложные (inline) дабы экономить на переходах.
	Ответить \| Правка \| ^ к родителю #13 \| Наверх \| Cообщить модератору


	18. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	–1 +/–
	Сообщение от да я же on 18-Фев-15, 00:10
	> Грубо говоря, каждой переменной в функции можно выделить свой регистр Это я понимаю. Но перед каждым вызовом подфункции придётся этот регистр сохранять в стеке а потом - восстанавливать, иначе вызываемая функция может этот регистр перезатереть. Либо, если соглашение о вызове другое, сохранять в стеке модифицируемые регистры придётся самой вызываемой функции. Но в любом случае это запись в стек. inline-функции это действительно оптимизируют, но... неужели inline-функции (в том числе те, что компилятор сам заинлайнил) действительно дают настолько большой эффект?
	Ответить \| Правка \| ^ к родителю #15 \| Наверх \| Cообщить модератору


	22. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	+/–
	Сообщение от Mihail Zenkov (ok) on 18-Фев-15, 00:36
	> Но перед каждым вызовом подфункции придётся этот регистр сохранять в стеке а > потом - восстанавливать, иначе вызываемая функция может этот регистр перезатереть. Либо, > если соглашение о вызове другое, сохранять в стеке модифицируемые регистры придётся > самой вызываемой функции. Но в любом случае это запись в стек. Не совсем так - если рассматривать самый простой случай (один поток, без прерываний), компилятор просто передаст регистр(ы) в качестве аргумента вызываемой функции и постарается использовать еще не задействованные регистры. Тут их количество и сыграет решающую роль. > inline-функции это действительно оптимизируют, но... неужели inline-функции (в том числе > те, что компилятор сам заинлайнил) действительно дают настолько большой эффект? На микроконтроллерах inline - просто сказка, без него о нормальной скорости можно забыть. На pc - эффект может быть разный, смотря что именно удалось встроить/развернуть. Например сборка pango с -march=native -mmmx -msse -msse2 -msse3 -msse4a -O3 -mfpmath=sse дает двукратный приросты в gtkperf на тесте текста. Что там точно происходит я не изучал. А так в среднем прирост 5-10%. Но тут конечно больше автовекторизация дает эффект.
	Ответить \| Правка \| ^ к родителю #18 \| Наверх \| Cообщить модератору


	24. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	–1 +/–
	Сообщение от да я же on 18-Фев-15, 01:25
	> компилятор просто передаст регистр(ы) в качестве аргумента вызываемой функции > и постарается использовать еще не задействованные регистры. Тут их количество и > сыграет решающую роль. Возможно, вы меня не так поняли (или я вас). Я говорю не о передаче через регистры параметров. Давайте лучше на примере. Пусть у нас есть функции 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_return pushl %rdi ; сохранить регистр, так как g может его поменять call g popl %rdi ; восстановить значение incl %rdi jmp f_loop f_return ret 2 вариант. За сохранение регистров отвечает вызываемая функция (та, которая использует регистр). То есть функция заботится о сохранении чужих локальных переменных, которые она может затереть. f: pushl %rdi; сохранить регистр, так как он может использоваться внешней функцией movl $0, %rdi f_loop: cmpl %rdi, $10 je f_return call g incl %rdi jmp f_loop f_return popl %rdi ; восстановить значение, потенциально используемое внешней функцией ret Во-первых, в любом случае есть как минимум одно сохранение-восстановление из стека. Во-вторых, если вместо стека мы попытаемся использовать другой, "неиспользуемый", регистр (например, %rsi), то тогда в стек придётся сохранять его, %rsi, значение. Можно ли как-то оптимизировать этот случай (кроме inline)?
	Ответить \| Правка \| ^ к родителю #22 \| Наверх \| Cообщить модератору


	25. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	+/–
	Сообщение от Mihail Zenkov (ok) on 18-Фев-15, 01:59
	> Допустим компилятор решает хранить переменную 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) еще на стадии компиляции.
	Ответить \| Правка \| ^ к родителю #24 \| Наверх \| Cообщить модератору


	33. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	–1 +/–
	Сообщение от да я же on 18-Фев-15, 10:30
	> он либо возьмет другой регистр для i либо для функции g Так в общем случае при компиляции g компилятор не может знать, какие регистры будут использоваться вызывающими её функциями, такими как f.
	Ответить \| Правка \| ^ к родителю #25 \| Наверх \| Cообщить модератору


	43. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	+/–
	Сообщение от Аноним (??) on 18-Фев-15, 16:52
	поэтому использует имена абстрактных регистров, а когда ведет генерацию кода - получает ограничения на использование реальных и генерит код под эти ограничения.
	Ответить \| Правка \| ^ к родителю #33 \| Наверх \| Cообщить модератору


	28. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	+/–
	Сообщение от tensor on 18-Фев-15, 04:45
	> Если в системе <= 4GB, то наоборот нужно экономить память, а не жалкие проценты производительности процессора. Если начнется свопинг... Немного оффтоп, но не мог не ответить. Если разница в потреблении и достигает 20-50 МБ ("копейки" для нынешних браузеров), что они вам дадут на десктопе? С одной стороны, если у вас забита память под завязку, а swappiness=0, то вам остаётся только лезть в tty и срочно дропать кэши/прибивать процессы - но зачем до такого доводить? С другой, лаги в 64-битной системе со свопом 3-5% от памяти вы, скорее всего, и не заметите. А вообще, проще сменить ПО на более легковесное (DE, браузер, плеер), чем возвращаться к 32 битам и экономить на спичках.
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	39. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	+/–
	Сообщение от Аноним (??) on 18-Фев-15, 13:33
	> А вообще, проще сменить ПО на более легковесное ( ... браузер ... ) Браузер? Угу, удачи. Оксюморон
	Ответить \| Правка \| ^ к родителю #28 \| Наверх \| Cообщить модератору


	40. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	–1 +/–
	Сообщение от Mihail Zenkov (ok) on 18-Фев-15, 13:48
	>> Если в системе <= 4GB, то наоборот нужно экономить память, а не жалкие проценты производительности процессора. Если начнется свопинг... > Немного оффтоп, но не мог не ответить. Если разница в потреблении и > достигает 20-50 МБ ("копейки" для нынешних браузеров), что они вам дадут > на десктопе? Не такие там и копейки - ссылка ниже. > А вообще, проще сменить ПО на более легковесное (DE, браузер, плеер), Это верно - почти всегда его использовал. > чем возвращаться к 32 битам и экономить на спичках. Мне не нужно возвращаться, я их до сих пор использую. На машине 4GB, без свопа. Пока для всех моих задач более чем достаточно. Сейчас запущен FF (облегченный), более 50 вкладок, реально использовал за этот сеанс 10 из них - памяти занято 346 MB (вся система + FF). Будет нужно памяти 8GB или больше, тогда и перейду на 64 бита.
	Ответить \| Правка \| ^ к родителю #28 \| Наверх \| Cообщить модератору


	49. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	+/–
	Сообщение от count0krsk (ok) on 22-Фев-15, 17:24
	Вот-вот. Аналогично. Сейчас имею 6 Гб, и 32 бит хватает. С учетом того, что скоро и firefox/icecat будет многопроцессным, хватит ещё долго )) А любители модных молодёжных 64бит пусть и дальше плачут над багами дров.
	Ответить \| Правка \| ^ к родителю #40 \| Наверх \| Cообщить модератору


	27. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	–1 +/–
	Сообщение от Прохожий (??) on 18-Фев-15, 04:02
	Не совсем так. Так или иначе все упирается не в регистровую память, а различные вычислительные блоки CPU. Кеш:L1, L2, L3... Размеры огромны, а скорость впечатляет. Большинство кода умещается именно там и ограничивается вычислительными возможностями CPU. Большее их количество и разрядность не делает операции с ними в два раза быстрее. Большинство программ просто не получат никакого преемущества от этого, за исключением узкого круга специализированного софта.
	Ответить \| Правка \| ^ к родителю #9 \| Наверх \| Cообщить модератору


	10. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	+/–
	Сообщение от BratSinot (ok) on 17-Фев-15, 22:02
	В 1KiB влезает 128 64-битных указателя, а в 1Mib 131072 64-битных указателя, как вы думаете, большая разница в потреблении памяти будет? Только вот в amd64 ABI в качестве FPU юзают SSE, а он, мягко говоря, быстрее работает, упоротого x87, плюс в два раза больше регистров общего назначения и XMM. Ах да, еще и SSE/SSE2 100% есть, а не как любят собирать под i386 непонятно нафига.
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	12. "Началось формирование 32-разрядых Linux-сборок браузера Viva..."	–2 +/–
	Сообщение от Mihail Zenkov (ok) on 17-Фев-15, 22:13
	> В 1KiB влезает 128 64-битных указателя, а в 1Mib 131072 64-битных указателя, > как вы думаете, большая разница в потреблении памяти будет? Было много проведено сравнений - для 64-битных программ идет существенно больше памяти. > Только вот в amd64 ABI в качестве FPU юзают SSE, а он, > мягко говоря, быстрее работает, упоротого x87, -mfpmath=sse > плюс в два раза больше > регистров общего назначения и XMM. Это да, существенный плюс. > Ах да, еще и SSE/SSE2 100% есть, а не как любят собирать > под i386 непонятно нафига. Это только говорит об неадекватности собиравшнго. Или avx и прочие новинки будем использовать только после перехода на 128 бит?
	Ответить \| Правка \| ^ к родителю #10 \| Наверх \| Cообщить модератору