ВНЕЗАПНО

...а хотите ещё еды пищи для ума?

Пример с Эльбрусом вошёл в лекции, которые читают в Принстоне по микроархитектуре. Причем, пример положительный — как надо делать, а не как не надо. Причем даже онтопик по отношению к тому, что в этой ветке сейчас обсуждают.

Пруфпик тут.

Эти хитрованы придумали, как (хотя бы частично) обойти ситуацию с промахом по кэшу — ту самую, что практически нереально предсказать статически. Идея очень крутая: в случае, если Load не попадает в кэш, исполняется ветвление. Этим ветвлением можно эмулировать поведение агрессивного out-of-order, который в таком случае начинает исполнять инструкции после load'a — те, которые в принципе можно исполнить. Здесь можно сделать то же самое с одной стороны, а с другой — устроить халявную профилировку кэшей или даже какое-то разумное динамическое поведение в зависимости от.

В общем и целом — WIN!

Весь бинарный код и в особенности все что около «x86» можно разместить в музее с вывеской «Как не надо делать».

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

Эти хитрованы придумали, как (хотя бы частично) обойти ситуацию с промахом по кэшу — ту самую, что практически нереально предсказать статически. Идея очень крутая: в случае, если Load не попадает в кэш, исполняется ветвление.

не обязательно исполнять ветвление — можно, например, ограничиться conditional move on cache miss — это выглядит более безопасно и может исполняться более параллельно, чем branch

Эти хитрованы

идея очевидная; если не веришь — вот один из моих вопросов :

3. имеются ли команды, которые компилятор может генерировать, чтобы выяснить, сколько времени займет вычисление следующей команды? скажем «загрузи в регистр R5 число 3, если все операнды следующей команды лежат в L1, число 9, если они в L1 или L2, и число 100, кто-то из них в оперативке» ( Тестирование системы на «Эльбрус-2С+» (комментарий) )

кстати, книжка, которую с их сайта можно скачать, мне непонятна — и я сочувствую тем, кто по ней будет учиться; она похоже нарезана из paper-ов, и надо читать сами эти paper-ы

В общем и целом — WIN!

ну... можно сказать и так, во всяком случае (опять процитирую себя)

можно набраться наглости и сказать, что если за $5М невозможно сделать ответы на все мои вопросы «да» /* включая «3.» */, то результаты опять неинтересны

Пруфпик тут.

уж лучше бы дал ссылку на внятное описание того, как в эльбрусе реализован branch on cache miss

«уж лучше» потому, что мы тут не идиоты, и можем оценивать что-то исходя из содержания, а не исходя из «дядя в принстоне заинтересовался»

Я вот читаю тебя и не понимаю, то ли ты специалист, толи фантазер. Ты так лихо описываешь архитектурные решения, что аж непонятно, куда разработчики чипов смотрят.

я высококвалифицированный специалист по всему это такой процесс самообучения в стиле лор-а — в расчете на то, что мне укажут на дефекты этих решений

А OPT1 что значит?

OPT1 это та же оптимизация, написанная типобезопасно на с++, и жестоко сливающая (не только у меня) по времени неоптимизированной версии; там, возможно, есть принципиальные причины, почему она не может быть быстрой — и если так, то это дефект с++

Размер cache известен и фиксирован...

... в hpc

в хомячковом софте я предлагаю решать эту проблему так: цикл компилируется слегка по-разному для допустим, для определенности, 5 разных соотношений «объем_массива/объем_кэша», и далее в рантайме делается branch на правильную версию кода

Размер массива не так важен - важно только чтобы он был достаточно большой, чтобы покрыть накладные расходы на организацию самого цикла и иметь возможность unroll

это да

но это действительно ОСИЗ. Если ты её реализуешь _аппаратно_, причём БЫСТРО

я не подряжался решать ее аппаратно — речь шла об аппаратуре, которая позволяет решать ее компилятору

вот ты пока не высказал свое мнение насчет jit — это интересно

ведь покупаю-же они ненужные им 6и ядерные процессоры? Покупают. И хвастаются друг перед другом. Ну и 256и ядерные будут покупать.

пока что только самые крутые видяхи только приблизились к приемлемым значениям 60 гигапикcелов/секунду и 120 гигатекселов/секунду, и жрут при этом почти 300 ватт

как минимум есть возможность прогресса в сторону «запихнуть эти мощности в мобильник»

з.ы. понятно, что это все же dsp, а не процессоры общего назначения, но все же

з.з.ы. 60 гигапикcелов/секунду это жалкие 30 кадров/секунду на FullHD

Пруфпик тут.

Интересно, о каком из многочисленных Эльбрусов речь.

Во втором, можете приобщаться к увлекательным исследованиям о том, как оптимизировать доступ к данным в предметно ориентированных областях. Кстати, очень популярное в pure CS направление.

я не спорю, что *так* можно получить в разы (а то и на порядки) больший выигрыш, чем с помощью компилятора, однако все же это существенно сложнее, чем написать компилятору несколько прагм

т.е. оба подхода должны существовать

Интересно, о каком из многочисленных Эльбрусов речь.

хороший вопрос

просто потому что компилятору доступен полный контекст исполнения и зависимости между данными (системные вызовы и прерывания пока упустим)

мне бы тоже этого хотелось, но это иногда не так из-за aliasing-а

Если это не так, или компилятор не может доказать зависимость, он, очевидно, предполагает независимость и генерирует соответствующий код. Программист может улучшить кодогенерацию с помощью соответствующих pragma statements.

pragma — это ответ на вопрос «что делать, если программист умный, а компилятор тупой»

а я имею в виду вопрос «что делать, если программист умный, компилятор умный, а архитектура — тупая» (например, не предоставляет что-то вроде branch on cache miss или conditional move on cache miss — хотя в цитате речь идет об aliasing-е, который *тоже* может быть неизвестен на этапе компиляции даже *умному* программисту, т.к. зависит от входных данных)

Размер cache известен и фиксирован...

... в hpc

Что-то я потерялся. В каком случае размер cache является неизвестным? Даже в случае, когда один и тут же CPU выпускается с разным размером cache, всегда есть способ определить размер. Да и компилятор обычно имеет опцию указания размера cache (для кросс-компиляции) или определяет размер сам для native кода.

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

Вы, мне видится, придерживаетесь иной точки зрения.

вот ты пока не высказал свое мнение насчет jit — это интересно

Я не могу придумать, где мне в работе могла бы понадобиться jit-компиляция. Поэтому, у меня опыта недостаточно, чтобы сформировать мнение.

не обязательно исполнять ветвление — можно, например, ограничиться conditional
move on cache miss — это выглядит более безопасно и может исполняться более
параллельно, чем branch

Цена промаха по L1 — от 10 тактов, по L2 от 100 и до десятков тысяч, если всё плохо. Cmov исполняется за такт, поэтому в данном случае, совершенно не спасёт. Но он там тоже есть — во всяком случае, его там не может не быть.

идея очевидная; если не веришь — вот один из моих вопросов :

Вопрос сформулирован несколько с другой стороны — со стороны профилировки вообще. А это не профилировка, это прямой перенос фич из ООО в VLIW. (Хотя такое и можно использовать, как профайлер!) Out-of-order процессоры выполняют такие «ветвления» автоматически, без ведома юзера или компилятора, и очень на этом выигрывают.

уж лучше бы дал ссылку на внятное описание того, как в эльбрусе реализован branch on cache miss

Конечно лучше. Только вот не знаю я такой ссылки. Обидно вдвойне, потому что все заинтересованные стороны (см. Принстон или тот же Интел) уже в курсе.

Что же до того, о каком Эльбрусе речь — так вот об этом, как я понял. VLIW, начался в очень позднем СССР, потом проекту поплохело, потом получшало, потом команду разработчиков купил Интел (и это было упомянуто лектором). Ну а сейчас вот его(по-видимому) таки пытаются наконец выпустить.

Что-то я потерялся. В каком случае размер cache является неизвестным? Даже в случае, когда один и тут же CPU выпускается с разным размером cache, всегда есть способ определить размер. Да и компилятор обычно имеет опцию указания размера cache (для кросс-компиляции) или определяет размер сам для native кода.

я полагал, что там слово «известно» означает «статически известно», поскольку речь шла о компиляторе

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

хотя и остается возможность иметь несколько разных dll/so или даже просто разных функций, вызываемых для разных размеров кэша и разных размеров массива, это не самый лучший вариант, т.к. нам придется иметь m*n вариантов для m разных размеров кэша и n разных размеров массива

далее мысль была в том, что вместо m*n вариантов можно было бы ограничиться небольшим числом вариантов, скажем 5-ю, для нескольких разных отношений «размер_массива разделить на размер_кэша», что уже намного лучше (хотя в данном случае m*n тоже реалистично, но в случае необходимости учитывать при оптимизации еще какие-либо варианты может произойти комбинаторный взрыв, что плохо — btw afaik именно комбинаторным взрывом и оправдывают применение jit)

наконец, компилятор мог бы под воздействием определенной прагмы сам генерить 5 вариантов цикла, каждый из которых оптимизирован под соответствующее отношение «размер_массива разделить на размер_кэша», и в этом я не вижу ничего суперсложного

Иначе говоря, улучшить архитектуру процессора программным способом нельзя. Вы, мне видится, придерживаетесь иной точки зрения.

очень странно было бы, если бы я отрицал очевидные вещи

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

Вопрос сформулирован несколько с другой стороны — со стороны профилировки вообще

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

та инструкция предполагалось не как средство профилировки, а как средство поменять порядок исполнения команд на основе инфы из рантайма — и что-то подобное этому (но не обязательно точно это) vliw иметь обязан, иначе он с треском проиграет оое

это предполагалось как средство поменять порядок исполнения команд на основе инфы из рантайма

Если имеется в виду статическая смена порядка во время компиляции — то это есть. Некоторые компиляторы для VLIW таки интерпретируют программу чтобы прикинуть вероятность ветвлений и расположить инструкции на пути наиболее вероятного развития программы. При этом, если предсказание сделано неверно, исполняется корректировочный код, потому что на VLIW нет commit'ов и rollback'ов состояния — всё софтверно.

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

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

1. Qt 4.5.2 входит в штатную поставку ОС. Препятствий перед портированием более свежих версий нет. 2. Набортный звуковой чип есть, поддерживается SDL (1.2 ЕМНИП)

Учебник с описанием архитектуры Эльбруса выложен на сайте МЦСТ

Скажем так, при запущенных virtualbox, eclipse, chrome на многоядернике всё крутится шустрее чем на одноядернике. Вопрос в том, что если ты не можешь нагрузить имеющуюся у тебя выч. мощность, это твои проблемы.

не пользуйся былокодом. (VB мне нравится, это не быдлокод, это костыль для запуска быдлокода).

я не подряжался решать ее аппаратно — речь шла об аппаратуре, которая позволяет решать ее компилятору

я вообще сомневаюсь, что это в принципе возможно. А если возможно, то так, что-бы было хотя-бы 5% профита.

ведь покупаю-же они ненужные им 6и ядерные процессоры? Покупают. И хвастаются друг перед другом. Ну и 256и ядерные будут покупать.

пока что только самые крутые видяхи только приблизились к приемлемым значениям 60 гигапикcелов/секунду и 120 гигатекселов/секунду, и жрут при этом почти 300 ватт

причём тут видео?

как минимум есть возможность прогресса в сторону «запихнуть эти мощности в мобильник»

это для исполнения JavaScript в мобильниках и ОС на нём?

з.ы. понятно, что это все же dsp, а не процессоры общего назначения, но все же

нет, не «всё-же».

з.з.ы. 60 гигапикcелов/секунду это жалкие 30 кадров/секунду на FullHD

я всё ещё не понимаю смысла FullHD в мобильнике с экраном 3'? Ты этот экран в микроскоп разглядываешь что-ли?

Предлагаешь голый фреймбуфер, emacs и links?

я всё ещё не понимаю смысла FullHD в мобильнике с экраном 3'

dpi больше, текст читать приятнее.

пока что только самые крутые видяхи только приблизились к приемлемым значениям 60 гигапикcелов/секунду и 120 гигатекселов/секунду, и жрут при этом почти 300 ватт

причём тут видео?

это у тебя надо спросить

исходя из слов «гигатекселов» и «300 ватт» очевидно, что речь идет не о воспроизведении видео, а о рендеринге 3д сцен

з.ы. понятно, что это все же dsp, а не процессоры общего назначения, но все же

нет, не «всё-же».

нет, «все-же» — ты сам завел речь о 256-ядерных процессорах, а при таком количестве ядер начинает быть существенной dsp-специфика — во всяком случае если у нас 256 ядер, то рендерить 3д сцены будут наверно уж ядра, а не видеокарта?

я всё ещё не понимаю смысла FullHD в мобильнике с экраном 3'?

4"...5" — и да, точки на менее чем FullHD мобильниках все еще заметны (лестничный эффект либо размытость краев видно на 1280х720)

Предлагаешь голый фреймбуфер, emacs и links?

KDE, kDev, FireFox нормально работают на iP4 с одним ядром. а про elinks это ты до абсурда доводишь.

dpi больше, текст читать приятнее.

ИМХО тоже самое, что разница между 5ю мегапиксилями и 55ю если фотка 9х12 из кодак-экспресса.

нет, «все-же» — ты сам завел речь о 256-ядерных процессорах, а при таком количестве ядер начинает быть существенной dsp-специфика — во всяком случае если у нас 256 ядер, то рендерить 3д сцены будут наверно уж ядра, а не видеокарта?

я говорил про _обычные_ CPU, с 256ю ядрами. Но возможно ты прав - в те времена видяха будет тупо не нужна. 256 ядер хоть чем-то полезным займутся…

4"...5" — и да, точки на менее чем FullHD мобильниках все еще заметны (лестничный эффект либо размытость краев видно на 1280х720)

ну должны же более дорогие модели хоть как-то отличаться с виду?!

Потестил моноблок. Неплохая штука вышла. Очень секьюрная и не такая уж и тормознутая для пятиста мегагерц. Но, софта катастрофически не хватает. Буду ждать следующую ревизию с гигагерцовым камешком.

Потестил моноблок.

где????

Неа. Разницу между 5 и 12 Mpix на печати отлично видно. Тут то же самое, чем больше dpi тем более чёткие шрифты можно отрисовать.

Разницу между 5 и 12 Mpix на печати отлично видно.

это потому, что там не совсем честные мегапиксели. На самом деле, каждый пиксель там ОДНОГО цвета (каждый второй зелёный, и остальные два красный и синий), потому эти 5 можно смело поделить на 4, а потом ещё раз на 2, из-за слабости мощности CPU в дешёвом мыле, из-за чего приходится использовать примитивные алгоритмы интерполяции (выяснения, насколько синие были красные пиксели). Ну и ещё раз вдвое..впятеро за копеечную пластиковую линзу в 5и мегапиксельном фотике. В итоге ты и получаешь где-то так 640х480 (0.3Mpix), где всякие ступеньки конечно различимы на печати(особенно если это всё ещё в фотике в JPEG пожать). В 12и мегапиксельной мыльнице и пикселей больше, и линза лучше, и процессор мощнее, потому и разница видна.

С твоим «FullHD» в твоей мобиле та же самая история.

Мне есть с чем сравнивать - был у меня HTC Wildfire S c каким-то там дохлым разрешением, теперь у меня китаец ThL W3+ с 1280*720 - разница налицо. Читать с экрана стало гораздо удобнее, мелкий шрифт лучше виден.

И меня не еб^Wволнует насколько там пиксели честные.

И меня не еб^Wволнует насколько там пиксели честные.

это твоё право. Я же говорил о том, что «ядра» в процессорах такие-же нечестные, как разрешение и мегапиксели. По большому счёту, это всё маркетинг, и число ядер совсем не влияет на производительность(влияют другие параметры). Зато ядрами удобно мериться, если пиписька маленькая. Также как и мегапикселями, мегагерцами, и FullHD.

Правда иной раз хомячки испытывают когнитивный диссонанс, видя монитор 640х480 за 100500 денег… Или сабж…

Просто сабж тоже нельзя мерить топорными маректинговыми характеристиками от винтел.

Человекам надо чем-то меряться. Раньше мерились длиной члена. Теперь член в обществе не покажешь, надо мериться чем-то ещё. То, что маркетинг, такой маркетинг - это да, и без него уже никак.

Ты видимо не хочешь понять одну простую мысль - все эти гигабайты и гигагерцы помимо маркетинговой шелухи, несут в себе ещё и сравнительные характеристики, которые играют роль при выборе чего-то. Понятно, что кто-то просто недостаточно образован, чтобы понимать, что MHz - это техническая характеристика, которая позволяет приблизительно сравнивать производительность в рамках одной архитектуры и то, последние лет 5 сильно неточно.

Когда я вижу монитор 640*480 за 100500 денег я ощущаю удивление, да, поскольку не знаю за что там просят таких денег. Но видимо если его за эти деньги покупают, значит там что-то такое есть, за что их можно просить.

Человекам надо чем-то меряться. Раньше мерились длиной члена. Теперь член в обществе не покажешь, надо мериться чем-то ещё.

man история

Член _в обществе_ никогда нельзя было показывать, и тем не менее, именно им всегда и мерились. И сейчас тоже.

Ты видимо не хочешь понять одну простую мысль - все эти гигабайты и гигагерцы помимо маркетинговой шелухи, несут в себе ещё и сравнительные характеристики, которые играют роль при выборе чего-то

я это прекрасно понимаю. Это _вы_ не можете понять простой вещи: что-бы приобрести нужный _вам_ девайс, нужно со специалистом советоваться, а не по «попугаям» сравнивать. Попугаи придуманы теми людьми, которые купили за 10, а хотят продать вам за 20.

Понятно, что кто-то просто недостаточно образован, чтобы понимать, что MHz - это техническая характеристика, которая позволяет приблизительно сравнивать производительность в рамках одной архитектуры и то, последние лет 5 сильно неточно.

это сильно неверно. могу поспорить, что мой компьютер с 806MHz работает минимум вдвое быстрее твоего с 3000+ MHz. В смысле сцылки в браузере вдвое быстрее щёлкаются и т.д. Хотя у меня не Links, а последний FF. А по попугаям - да, твой рвёт конечно.

Когда я вижу монитор 640*480 за 100500 денег я ощущаю удивление, да, поскольку не знаю за что там просят таких денег.

видишь? тебя уже приучили думать в попугаях. Фишка в том, что ты даже никогда _не видел_ этих 640х480, то, что ты видел в мобилах с 0.3Мп это СОВСЕМ ДРУГОЕ. Никаких артефактов из твоей мобилы, с которой ты сравниваешь, там нет. А те, что есть - то не баг, а фича(которая будет заметна на _очень_ хорошем телевизоре клиента, и значит оператор должен сменить ракурс так, что-бы этого не было).

Член _в обществе_ никогда нельзя было показывать, и тем не менее, именно им всегда и мерились. И сейчас тоже.

Член тут ни при чём, это был пример пузомерки, одной из.

806MHz работает минимум вдвое быстрее твоего с 3000+ MHz.

пруф или не было.

Это _вы_ не можете понять простой вещи: что-бы приобрести нужный _вам_ девайс, нужно со специалистом советоваться, а не по «попугаям» сравнивать. Попугаи придуманы теми людьми, которые купили за 10, а хотят продать вам за 20.

Специалист смотрит на тех же попугаев, только лучше понимает что за ними кроется. Вот в этом и есть разница.

тебя уже приучили думать в попугаях.

Поделись libastral.so, да. У любой технической хреновины которая продаётся есть набор характеристик, по которым можно сделать сравнение между одной, другой и третьей. Это и есть те самые попугаи о которых ты так пренебрежительно говоришь.

В примере с монитором ты заранее не говоришь всех его «попугаев», ака тех. характеристики, кроме разрешения, которое не блещет в сравнении с другими. Остальные характеристики ты умалчиваешь и когда кто-то удивляется «с какого перепою столько?» ты начинаешь выставлять себя таким всемногомудрым который не думает в «попугаях», а знает много.

пруф или не было.

как ты это себе представляешь?

Специалист смотрит на тех же попугаев, только лучше понимает что за ними кроется. Вот в этом и есть разница.

нет. Специалист на попугаев не смотрит. Он смотрит на то, что за ними скрывается.

Поделись libastral.so, да. У любой технической хреновины которая продаётся есть набор характеристик, по которым можно сделать сравнение между одной, другой и третьей. Это и есть те самые попугаи о которых ты так пренебрежительно говоришь.

да, но тебе достаточно всего ОДНОЙ характеристики, причём даже без методики её измерения, что-бы удивиться.

В примере с монитором ты заранее не говоришь всех его «попугаев», ака тех. характеристики, кроме разрешения, которое не блещет в сравнении с другими.

ты так и не понял самого главного: в примере с монитором, разрешение - это не баг, а фича. Оно такое и ДОЛЖНО быть. Стандарт такой у телевидения. Что PAL, что SECAM. Т.е. оно другим и быть не может.

как ты это себе представляешь?

значит «не было».

нет. Специалист на попугаев не смотрит. Он смотрит на то, что за ними скрывается.

А смотреть на «то, что за ними скрывается» он должен через libastral?

да, но тебе достаточно всего ОДНОЙ характеристики, причём даже без методики её измерения, что-бы удивиться.

чтобы удивиться да. Чтобы выбрать нет.

ты так и не понял самого главного: в примере с монитором, разрешение - это не баг, а фича. Оно такое и ДОЛЖНО быть. Стандарт такой у телевидения. Что PAL, что SECAM. Т.е. оно другим и быть не может.

ты вообще читаешь что я пишу или нет?

А смотреть на «то, что за ними скрывается» он должен через libastral?

есть же спеки. В чём проблема?

чтобы удивиться да.

и что тут удивительного?

ты вообще читаешь что я пишу или нет?

пытаюсь. Хотя не совсем понятно.

Out-of-order процессоры выполняют такие «ветвления» автоматически, без ведома юзера или компилятора, и очень на этом выигрывают.

Да конечно. Было у арма A8 СPI=2 на реальных программах, у А15 стало 0.9. Ну теперь збс, обогнали таки i486. Было у пня2-3 CPI~1.0, стало у коры-i7 0.5. Прогресс, чо. Очень выиграли ценой огромного усложнения.

есть же спеки. В чём проблема?

В спеках написаны те же самые «попугаи».

и что тут удивительного?

100500 за 640*480 монитор вызывают удивление. То, что он специализированный и как-то ещё охуенен и нужен в определённых областях, где на него денег таких выделят, это уже другой разговор.

Да конечно. Было у арма A8 СPI=2 на реальных программах, у А15 стало 0.9

Я чувствую некоторое пренебрежение к таким результатам, но не могу понять: почему? Это что — плохо, что процессор стал работать в несколько раз быстрее?