Здравствуйте, Mamut, Вы писали:

M>>>Да еще желательно не на одном комптютере в сети И начнутся ручные закаты солнца.
F>>надуманная задача, надуманные проблемы..
M>Вот ненадуманная: http://grey-kristy.livejournal.com/87271.html

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

у меня просто тут была похожая ситуация:
к одной нашей игрушке были написаны боты для нагрузочного теста на перле в стиле "один бот — один процесс".. через некоторое время протоколы поменялись, автор укатил надолго в командировку, а боты неожиданно понадобились.. ну я и переписал их на питоне в многопоточном стиле.. в итоге производительность увеличилась на порядок, а то и на два.. говорит ли это о производительности питона в многопоточных приложениях?. да нифига, это говорит о кривой реализации на перле..

Здравствуйте, vdimas, Вы писали:

V>>>Это опять нубство, вот такой уровень общения. Что, где и почему нельзя? Давай по полочкам, а не вот этот бесполезный пинг-понг. Просто ты не прав категорически
A>>опровергай. аргументов не видно.
V>Я пока не вижу что опровергать, т.к. ты вообще еще ничего по делу не сказал.
V>Мое мнение:
V>Есть дополнительные инструкции процессора? — Есть.
V>Работают? — Очень даже хорошо работают.
ёпрст. я не про есть/работают, а про сохранение mm/xmm/ymm и сопутствующих регистров при переключении контекста.

V>Преценденты их использования в режиме ядра есть? — Сколько угодно в тех же виндах.
я уже Шеридану и в линуксовом ядре показал что и где есть, и *как* оно там используется

V>Все, что ты там увидел и чего неожиданно испугался — это всего навсего опции для сборки переносимого ядра. Компилят себе ядро нынче лишь экспериментаторы (коих гораздо меньше 1%), а все остальные пользуют уже сбилженные бинарные инсталляхи. Вот о них-то и беспокоятся. А если ты сам себе экспериментатор и сам собираешь ядро — то компили как хочешь, с любыми опциями, на здоровье.
ага. с любыми. щаз.

V>Я когда то давно собирал себе минимальное ядро Линуха для кое-какой железки, так вот меня наше обсуждение неприкосновенности опций компилятора просто умиляет, в сравнении с тем, что мы вытворяли с самими исходниками и как кромсали реализации сетевых протоколов, убирая нафик все лишнее.
ты кромсание-то лишнего не сравнивай с генерацией кода

Здравствуйте, Antikrot, Вы писали:

A>ёпрст. я не про есть/работают, а про сохранение mm/xmm/ymm и сопутствующих регистров при переключении контекста.

А как же их сохранение при переключении обычных задач, которые могут их использовать?

Здравствуйте, vdimas, Вы писали:

A>>ёпрст. я не про есть/работают, а про сохранение mm/xmm/ymm и сопутствующих регистров при переключении контекста.
V>А как же их сохранение при переключении обычных задач, которые могут их использовать?
вот такая вот оптимизация, всякие xsave вызываются не всегда, всё же не сохранять состояние sse даёт выгоду по времени.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, sndanil, Вы писали:

T>>>Попробуем с другой стороны Для каких задач обычного юзера не хватало процессоров 10-летней давности?

S>>Full HD Video? Crysis (и еще целая куча игрушек)?

PD>Для игрушек никогда не хватит, на то они и игрушки. Для видео — тоже понятно. Давай что-нибудь из более деловой сферы.

да пожалОЙста — Excel попробуй использовать для открытия таблицы хотя бы в пару тыс.строк, да ещё с диаграмками и формулами в хотя бы 10 колонок
поясню — это требуется например для оформления прайс-листов

Здравствуйте, mister-AK, Вы писали:

MA>да пожалОЙста — Excel попробуй использовать для открытия таблицы хотя бы в пару тыс.строк, да ещё с диаграмками и формулами в хотя бы 10 колонок
MA>поясню — это требуется например для оформления прайс-листов

Hint: отключение автоматического пересчета обычно помогает работать с такими документами. Правда в этом #%@#$!% экселе данная опция является не опцией документа, а опцией приложения.

Здравствуйте, mister-AK, Вы писали:

PD>>Для игрушек никогда не хватит, на то они и игрушки. Для видео — тоже понятно. Давай что-нибудь из более деловой сферы.

MA>да пожалОЙста — Excel попробуй использовать для открытия таблицы хотя бы в пару тыс.строк, да ещё с диаграмками и формулами в хотя бы 10 колонок

Это лишь говорит о том, как хорошо он написан. Вычислить по 2000 * 10 == 20000 формулам — для этого никак без 3GHz и $ Gb обойтись нельзя, разумеется . Особенно когда формулы содержат , например, расчет зарплаты (невероятно сложный NP-полный алгоритм

Для сведения. В DOS времена не было Excel, а был Supercalc, например. Он как-то умел работать в 640 Кб памяти. Можешь посмотреть, что он умел.

http://www.alex.krsk.ru/199_/1993/1993_08.htm

Дата этого документа внизу — 1993. Windows 95 еще только разрабатывается.

Приветствую, Pavel Dvorkin, вы писали:

PD> Для сведения. В DOS времена не было Excel, а был Supercalc, например. Он как-то умел работать в 640 Кб памяти. Можешь посмотреть, что он умел.

А вот так выглядел. Имхо — очень даже ничего.

Здравствуйте, Roman Odaisky, Вы писали:

PD>>Будет ли попытка создать какой-то новый процессор общего назначения для персоналок ? Не знаю. Не верю.

RO>Причем здесь Итаниум? А для персоналок ARM наше всё.

ARM наше все для тока для мобильных девайсов. Нетбуков там, с линухами и ChromeOS.

И, как ни странно, для низкопотребляющий фермовых серверов. Продуктов пока нет, но двухядерный Cortex A9, доступный на одной крупной тайваньской фабрике по техпроцессу 45 нм, вчетверо быстрее топового Атома. Суперскалярный (до 4-х инструкций за такт), работает на 2-х гигагерцах, и может быть синтезирован с кэшами L4 до 16 мегабайт. Что наводит на мысли.

Другое дело, что ядро ядром, и хищнические намерения ARM можно понять, но есть проблема. Кто-то должен отважится сделать микросхему для серверных продуктов на этой платформе . Пока героев я не заметил.

Кстати, если кто узнает про реальную микруху с этим ядром (1-2ГГц, Cortex A9, приличного размера кэши, интегрированные Ethernet-ы и switching fabric, плюс контроллер DDR на 64 бита) — скажите, она мне ппц как нужна, а я не нашел.

Здравствуйте, Gaperton, Вы писали:

G> инструкций за такт), работает на 2-х гигагерцах, и может быть синтезирован с кэшами L4 до 16 мегабайт. Что наводит на мысли.

С кэшами L2, естественно.

Здравствуйте, Gaperton, Вы писали:

G>Кстати, если кто узнает про реальную микруху с этим ядром (1-2ГГц, Cortex A9, приличного размера кэши, интегрированные Ethernet-ы и switching fabric, плюс контроллер DDR на 64 бита) — скажите, она мне ппц как нужна, а я не нашел.

Да, и контроллер PCIe штоб был. Это, в принципе, по предназначению микруха для раутеров-свитчей должна быть. Что по интерфейсам вполне понятно.

Здравствуйте, Roman Odaisky, Вы писали:

RO>Здравствуйте, squid, Вы писали:

S>>x86 столь ужасна?

RO>В ней есть проблема — в ней есть MMX, SSE, 3DNow, которые имеют тот недостаток, что их может не быть. Соответственно, в 21 веке компилируют программы в машинный код i386.

Почему?
Это кто смотря кто как пишет эти программы.
XviD, насколько я помню, собирается с возможностью использования кодеком алгоритмов использующих или MMX, или SSE или соответственно с дефолтовою реализацией под 386.
Другое дело, что писать в таком стиле не совсем удобно, опять же ассемблер надо знать.

Приветствую, A13x, вы писали:

A> Почему?
A> Это кто смотря кто как пишет эти программы.
A> XviD, насколько я помню, собирается с возможностью использования кодеком алгоритмов использующих или MMX, или SSE или соответственно с дефолтовою реализацией под 386.
A> Другое дело, что писать в таком стиле не совсем удобно, опять же ассемблер надо знать.

Ты хотел сказать — "в рантайме определяет аоддерживаемые расширения"?

Здравствуйте, Sheridan, Вы писали:

A>> Почему?
A>> Это кто смотря кто как пишет эти программы.
A>> XviD, насколько я помню, собирается с возможностью использования кодеком алгоритмов использующих или MMX, или SSE или соответственно с дефолтовою реализацией под 386.
A>> Другое дело, что писать в таком стиле не совсем удобно, опять же ассемблер надо знать.
S>Ты хотел сказать — "в рантайме определяет аоддерживаемые расширения"?
объясни разницу применительно к "в 21 веке компилируют в код i386"?
все более-менее серьёзные программы, начиная с ядра линукса, которому нас...ть на useфлаги, определяют расширения, и расширениями cpu тут не ограничиваются. кстати, при желании и знать-то всего надо одну инструкцию.

Приветствую, Antikrot, вы писали:

A> Здравствуйте, Sheridan, Вы писали:

A> A>> Почему?
A> A>> Это кто смотря кто как пишет эти программы.
A> A>> XviD, насколько я помню, собирается с возможностью использования кодеком алгоритмов использующих или MMX, или SSE или соответственно с дефолтовою реализацией под 386.
A> A>> Другое дело, что писать в таком стиле не совсем удобно, опять же ассемблер надо знать.

A> S>Ты хотел сказать — "в рантайме определяет аоддерживаемые расширения"?
A> объясни разницу применительно к "в 21 веке компилируют в код i386"?
Не понял вопроса... Ты хочешь знать разницу между билд-тайм и рантайм?

A> все более-менее серьёзные программы, начиная с ядра линукса, которому нас...ть на useфлаги, определяют расширения, и расширениями cpu тут не ограничиваются. кстати, при желании и знать-то всего надо одну инструкцию.
Постой ка, назови остальные "болееменее серьезные".

Здравствуйте, DOOM, Вы писали:

DOO>Павел. Ей-богу, смешно.
DOO>Весь мир HPC построен на итаниумах — вся линейка HP Integrity, например. Вплоть до Superdome. Если бы HP сказали, что они отказываются от итаниумов в этой линейке — это было бы да.

Интересно, как Вы считаете "весь мир HPC", если, например, в Top500 списке единственный пункт с Itanium это 86-е место? При том, что все прочие распределены с преобладанием x86 и некоторого количества Cell'ов.
Или Вы под HPC имеете в виду что-то другое?

Да, я знаю, что счётная задача и задача перемалывания базы данных имеют много различий в характере нагрузки, но если бы Itanium был интересен как средство держать нагрузку "вообще" — там было бы уж никак не одно место из ста, а как минимум десяток.

Думаю, надо признать следующее:
1. VLIW как идея провалилась.
2. Причины этого провала толком неясны и, видимо, для них понимания нужен или кто-то очень грамотный в теме, или данные изнутри Intel и HP. Потому что, например, когда P4 разгонялись до 4GHz, а итаниумы в это время еле-еле тянули 2GHz — что мешало разогнать вторые? Только маркетинг? Слабо верится.

DOO>А то, что отказывается MS говорит лишь одно — ни асилили. У них была очень ограниченная поддержка. Винды для NUMA систем не было — там был только вариант с HP-UX или OpenVMS и нарезка на партиции, на которых уже винду ставить.

Их "ниасиливают" почти все. Но те, кому смена архитектуры — замена нескольких десятков файлов и небольшое дотачивание компилятора — "асиливают" за счёт разработки на других платформах; к этому классу относятся все юниксы. С Windows так просто не получалось.

Здравствуйте, Sheridan, Вы писали:

S>Приветствую, Antikrot, вы писали:

A>> расскажи что в make menuconfig сделать чтобы ядро собралось с -msse2/3/... .

S>Выбрать тип процессора. Компилятору подставляется -mcpu=..., а это в свою очередь включает нужные флаги.

-march, вообще-то. Но это не поможет без дополнительного разрешения. gcc автоматически не генерирует SSE2 и SSE3 вообще. Он может только первый SSE для плавучки, если разрешено.
(Я уж молчу, что в ядре Linux и аналогах использование FPU и SSE* резко ограничено административно. Ибо таки нефиг.)

Здравствуйте, Eugeny__, Вы писали:

S>>thebat, kmail — про них уже както забыли наверное?

E__>Если честно, с появлением гмыла я с радостью отказался от специальных клиентов для почты. Они — тупо лишнее звено. Были актуальны 10 лет назад только потому, что интернет был хреновый и дорогой, и вообще не всегда был, потому копии писем лучше было хранить локально. Сейчас интернет доступен даже в лесу(с телефона), а уж настольных компов без подключения к сети я уже несколько лет в глаза не видел. Поэтому почтовые клиенты для меня напрочь потеряли смысл.

А приватный ключ для подписывания своих сообщений ты тоже хранишь на gmail? ;)
Или ты считаешь, что честному человеку все эти меры не нужны? ;)

Здравствуйте, vdimas, Вы писали:

V>И не надо вводить лишних признаков водораздела, термин "микропрограмма" — это аналог термина firmware, то бишь более точный аналог этого термина — "прошивка". Как пример микропрограммы обычно приводят ПО в сотовых телефонах или BIOS, идущий на материнках. Т.е., если думаешь, что "микропрограммы" исключительно относятся ко временам микропрограммных процессоров, то это не так.

V>И ты же не будешь утверждать, что службы BIOS, или вот эта его конфигурационная программа, которую можно вызвать на старте, или менюхи в твоем сотовом — это все "железячное" исполнение? :)

Когда процессор серии x86, исполняя код BIOS, переводит его во внутренний микрокод и только затем его исполняет — у тебя есть чёткое различие между firmware и микропрограммой.
Даже если тебе это несущественно, то остальных будешь систематически сбивать с толку.

V>Короче, никаких аппаратных декодеров видео в природе не существует, и, надеюсь, никогда не появится. Более того, никто не будет ради кодека разрабатывать процессор с 0-ля какими-то мифическими микроядрами, ведь с этим связана еще и разработка tool chain, что может оказаться дороже разработки процессора. Поэтому обычно берут готовое ядро какого-нить обкатанного недорогого DSP вчерашнего/позавчерашнего дня, тоже самое для ЦПУ — обычно берут готовое ядро позавчерашнего дня. Во-первых — дешевле, во-вторых — надежней, в третьих — на современном процессе эту же схему ядра можно заставить работать на более высокой частоте. А другого пути выпускать электронику по разумным ценам и нет. :xz: Если под каждый медиаплеер разрабатывать свое ядро DSP, он будет стоить гораздо дороже любого десктопа.

Полностью аппаратных декодеров — да, не бывает.
Но поддержка под конкретные кодеки может быть настолько существенной, что без неё работы не будет. Сравни скорость обработки AES на сверхновых x86 с соответствующими командами и без них. И это всего лишь несколько команд. Железной структурой можно достичь большего.
И это как раз то, что не может быть взято из разработок позавчерашнего дня, ибо они совсем другие.

А склеивать совершенно разные по происхождению и работе блоки в одном SoC промышленность научилась давно, тут особого ума не надо.

Здравствуйте, vdimas, Вы писали:

A>>И это говорит человек, который требует от других знать как ОС работает внутри :))) Кстати, выбор в конфигураторе таки влияет, но sse тут не причём. Кроме того — а ты точно уверен, что оно не будет *медленнее*? ;)

V>Для GCC последних версий — не будет. Кстати, этот зоопарк несовместимых по командам x86-х — реальный аргумент в пользу Шеридана в его агитации собирать все из исходников.

На практике не сходится. Мы имеем или платформу x86-64, у которого пока что различия между платформами минимальны (и базовый объём того же SSE есть достаточный для большинства нынешних задач), или i386, в котором даже если ограничиваться уровнем i486 можно получить практически всё необходимое.

У меня перед глазами примеры разных линуксовых дистрибутивов. Практически нет попыток выставить -march (набор команд) выше i686, ибо незачем — улучшения не будет, а вот переносимость установленного результата убьётся. Есть варианты сборки i586 (Mandrake, Alt), i486 (ASP несколько лет назад; не знаю как сейчас). Есть деление на i386 и i686 (RedHat до относительно недавнего; сейчас они оставили только i686). Но никто не предлагает специальный дистрибутив под Pentium4 или CoreDuo только потому, что якобы будет быстрее. Если для какого-то приложения версия процессора крайне важна, оно само себе соберёт версии под конкретный процессор и набор команд (как это делает mplayer). А вот оптимизация генерации кода (-mtune=) идёт под современные процессоры.

Аналогичное слышу про Windows, хотя руками столь подробно не щупал.

Пересборка из исходников, по моему опыту, чаще оказывается полезней для уточнения других опций (режимы работы, если задаются при сборке; отключение нафиг не нужных зависимостей), чем для собственно оптимизации по процессору.