Исходное сообщение
"Выпуск CRIU 1.0, системы для заморозки и восстановления..." Отправлено AlexAT, 28-Ноя-13 07:30
> честное слово: у меня нет задач, гиперсложно обсчитывающих массу целочисленых значений. > а плавающим числам и вовсе плевать на целочисленые регистры, у них > своя подсистема. Вообще-то в режиме x86-64 и SSE-регистров поболе. > да пофигу им, пофигу. не заметишь ты разницы Даже на банальном веб-сервере разница есть. Там как раз в основном программы и занимаются тем, что тасуют строки... > и всё это по-прежнему нифига не заметно. Кому как. На десктопах с аськой и браузером, наверное, действительно будет незаметно. А вот если кодированием видео заняться - тут уже разница вылезет. Когда что-то на сервере ворочается - заметно. В свое время переход с x86-32 на x86-64 дал где-то 5-7% производительности по LAMP, за данный момент не скажу - ни одного сервера с x86-32 просто не осталось, и даже x86-32 библиотек ни на одном нет. Тестировать не на чем. Из личного хобби еще был MaNGOS - тому вообще сильно похорошело (где-то на четверть упала нагрузка на CPU). MySQL (и прочие движки БД) прекрасно умеет юзать и любит более 4Гб памяти. Так что если кто-то конкретный не может задействовать фичи x86-64 - это не значит, что x86-64 не нужен. Компиляция больших проектов GCC, кстати, именно что имеет обратную разницу между x86-32 и x86-64, c 99% вероятностью из-за того, что в сумме упирается в диск. Дисковых операций тут получается (в основном из-за выравнивания мелких структур, + объем кода на x86-64 несколько больше) несколько больше, соответственно процесс идет несколько дольше. Тут, правда, ccache может спасти очень даже неплохо хоть на x86-32, хоть на x86-64.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> честное слово: у меня нет задач, гиперсложно обсчитывающих массу целочисленых значений. >> а плавающим числам и вовсе плевать на целочисленые регистры, у них >> своя подсистема. > Вообще-то в режиме x86-64 и SSE-регистров поболе. >> да пофигу им, пофигу. не заметишь ты разницы > Даже на банальном веб-сервере разница есть. Там как раз в основном программы > и занимаются тем, что тасуют строки... >> и всё это по-прежнему нифига не заметно. > Кому как. На десктопах с аськой и браузером, наверное, действительно будет незаметно. > А вот если кодированием видео заняться - тут уже разница вылезет. > Когда что-то на сервере ворочается - заметно. В свое время переход с > x86-32 на x86-64 дал где-то 5-7% производительности по LAMP, за данный > момент не скажу - ни одного сервера с x86-32 просто не > осталось, и даже x86-32 библиотек ни на одном нет. Тестировать не > на чем. > Из личного хобби еще был MaNGOS - тому вообще сильно похорошело (где-то > на четверть упала нагрузка на CPU). > MySQL (и прочие движки БД) прекрасно умеет юзать и любит более 4Гб > памяти. > Так что если кто-то конкретный не может задействовать фичи x86-64 - это > не значит, что x86-64 не нужен. > Компиляция больших проектов GCC, кстати, именно что имеет обратную разницу между x86-32 > и x86-64, c 99% вероятностью из-за того, что в сумме упирается > в диск. Дисковых операций тут получается (в основном из-за выравнивания мелких > структур, + объем кода на x86-64 несколько больше) несколько больше, соответственно > процесс идет несколько дольше. Тут, правда, ccache может спасти очень даже > неплохо хоть на x86-32, хоть на x86-64.
	Введите код, изображенный на картинке: