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

CC>Надеюсь никогда не станет. Ибо до сих пор где правильный кошерный бинарь: мало ест и работает быстро. Где байт-код — тормоза и пожирание памяти.

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

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

НС>>На практике тоже.
CC>Меня убедит только ассемблерный output что оно нагенерило.
CC>Потому как то, что я видел до сих пор не дотягивало до результата слабеньких С компиляторов.

Не, оно реально работает. Проблема только в том, что это весьма маленькая часть реального использования SIMD. Т.е. основное применение SIMD — это векторизация произвольных циклов. И такое они не умеют. По сути имеется только прямая подстановка определённых SIMD инструкций при работе с одним определённым типом данных. В общем ситуация печальнее даже C/C++ компиляторов 15-и летней давности (те хотя бы позволяли работу с данными любого типа), так что сравнивать с современными C/C++ компиляторами (автоматизирующими этот процесс) вообще смешно. Но что-то (описанное по ссылке выше) всё же реально есть и в кое-каких специальных случаях оно реально вставит SIMD код. )))

Здравствуйте, Ночной Смотрящий, Вы писали:

CC>>В нативном коде это сразу будет скомпилировано в AVX/SSE вариант
НС>Так в AVX или SSE, ась? А если предполагаются процессоры с разными версиями? Будем под каждую версию компилировать или ограничимся самым куцым вариантом?

Вообще то динамическую загрузку нужного кода, в зависимости от типа процессора делали руками уже не первое десятилетие. ))) Ну а современные компиляторы позволяют решать эту задачу уже вообще автоматически. Например в GCC ты можешь указать в атрибутах функции набор нужных процессоров (например с SSE, с AVX и т.п.), под которые нужно её скомпилировать. В ответ на это компилятор сделает по одной бинарной версии функции под каждый процессор и плюс ещё собственно саму функцию (с нужным именем), представляющую собой форвард к нужной реализации. )

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

V>>И? Если ты пользовался готовыми высокоуровневыми либами
CC>Я их писал.

Да не верю, не убедишь. В либах тоже разные "слои" бывают.

Иначе бы не рассуждал отдельно о DX 3D и отдельно о 2D. Тем более, что в DX9 никакого 2D нет и вообще до Win7 не было, т.е. народ много лет пользовался и пользуется общим с 3D подмножеством АПИ. А в OpenGL и подавно — там в любом случае получается практически идентичная операция при формировании как 2D, так и 3D сцены. Даже нет возможности использовать сокращённую матрицу преобразования (только по x*y, как в D2D).


V>>Причем, судя по уровню обсуждения, — проходили не задерживаясь. ))
CC>Ну ты то тут демонстрируешь просто признаки "дома высокой культуры быта", ага.

Поздно ты спохватился. ))
Корректность она штука специфическая — или обоюдная или никакая.


V>>Вместо тысячи слов и неустанного тыканья пальцем в небо взял бы уже да попробовал давно..
CC>Нахрена? Я не испытываю нужды забивать гвозди микроскопами и тулы пользую для того, для чего они подходят наилучшим образом.

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

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

Ops>Это где такое?

Выслать прогу? ))


Ops>Зачем в десктопной программе гигабайтные текстуры?

Многомегабайтные запросто.


Ops>Весь экран для FHD в несжатом виде 8М, а в типичном окружении он без потерь до сотен килобайт пожмется.

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

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

V>Выслать прогу? ))

IDE, редактор, браузер, почтовик, Far, консоль от Hyper-V, keepass, мелкие утилиты вроде launchy и ditto — вот все, что у меня сейчас запущено. В них во всех текстур на килобайты, в основном для иконок. А что у тебя за прога, расскажи? Игрушка поди?

V>Многомегабайтные запросто.

Нахрена?

V>Дык, о чем и речь. Текстуры-то загружаются предварительно, причем в хорошем кач-ве, а реально отображается обычно небольшая их часть (как по кол-ву так и по областям из самих текстур), да еще часто через мипмапы.

А что за текстуры такие? Логотип производителя или компании, иконки для кнопок... Где ты мегабайты находишь?

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

_>Вообще то динамическую загрузку нужного кода, в зависимости от типа процессора делали руками уже не первое десятилетие. ))) Ну а современные компиляторы позволяют решать эту задачу уже вообще автоматически. Например в GCC ты можешь указать в атрибутах функции набор нужных процессоров (например с SSE, с AVX и т.п.), под которые нужно её скомпилировать. В ответ на это компилятор сделает по одной бинарной версии функции под каждый процессор и плюс ещё собственно саму функцию (с нужным именем), представляющую собой форвард к нужной реализации. )
Очень херовый подход, т.к. совместимость только в обратную сторону. То есть перенести бинарь на платформу, которой не существовало в момент компиляции, невозможно.
Вот это и есть главная причина того, что развитие архитектуры процов буксует всеми колёсами.

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

_>>Вообще то динамическую загрузку нужного кода, в зависимости от типа процессора делали руками уже не первое десятилетие. ))) Ну а современные компиляторы позволяют решать эту задачу уже вообще автоматически. Например в GCC ты можешь указать в атрибутах функции набор нужных процессоров (например с SSE, с AVX и т.п.), под которые нужно её скомпилировать. В ответ на это компилятор сделает по одной бинарной версии функции под каждый процессор и плюс ещё собственно саму функцию (с нужным именем), представляющую собой форвард к нужной реализации. )
K>Очень херовый подход, т.к. совместимость только в обратную сторону. То есть перенести бинарь на платформу, которой не существовало в момент компиляции, невозможно.
То есть? По традиции новые платформы сейчас обратно-совместимы с предыдущими. И в любом случае, механизм ifunc проверяет наличие нужных флагов в CPUID процессора, а не название платформы. И если на новой платформе их нет, оно просто уйдёт в базовую реализацию без всяких оптимизаций.

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

CC>>>Почему дублирование? На хосте подготовили список на выполнение, на клиенте его выполнили.
C>>Современный D3D/GL с шейдерами так не получится готовить.
CC>Какие млять шейдеры? Откуда в гуе шейдеры?
Начиная с Aero для общих эффектов и продолжая в Direct2D для собственно самого рендеринга, а что?

См.: https://msdn.microsoft.com/en-us/library/windows/desktop/dn879810(v=vs.85).aspx и https://msdn.microsoft.com/en-us/library/windows/desktop/hh973240(v=vs.85).aspx

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

_>>Вообще то динамическую загрузку нужного кода, в зависимости от типа процессора делали руками уже не первое десятилетие. ))) Ну а современные компиляторы позволяют решать эту задачу уже вообще автоматически. Например в GCC ты можешь указать в атрибутах функции набор нужных процессоров (например с SSE, с AVX и т.п.), под которые нужно её скомпилировать. В ответ на это компилятор сделает по одной бинарной версии функции под каждый процессор и плюс ещё собственно саму функцию (с нужным именем), представляющую собой форвард к нужной реализации. )
K>Очень херовый подход, т.к. совместимость только в обратную сторону. То есть перенести бинарь на платформу, которой не существовало в момент компиляции, невозможно.

Именно что происходит — собранное для i386 спокойно выполняется на KabyLake а версия для SSE — на любом проце с SSE.
Другой вопрос, что подобный подход в принципе определён только в пределах одной базовой ISA.

K>Вот это и есть главная причина того, что развитие архитектуры процов буксует всеми колёсами.

Естественно, обеспечение совместимости с прошлыми решениями в какой-то мере препятствует созданию принципиально новых.
И в случае x86 это имеет, за счёт тандема Intel — Microsoft, особенно злокачественные формы.

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

С>>А вот могут ли компиляторы сделать так, чтобы в результирующем бинаре было несколько вариантов одного и того же кода — один под AVX, другой под SSE?
CC>Могут. См ICC /Qax

Опаньки. Ты только что предложил самый куцый вариант для всех АМД. Или что-то в политике интела изменилось, и они поддерживают возможности процессоров АМД моложе 10 лет?

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

_>В ответ на это компилятор сделает по одной бинарной версии функции под каждый процессор и плюс ещё собственно саму функцию (с нужным именем), представляющую собой форвард к нужной реализации. )

Это что же, функции будут через стабы вызываться? А я губы раскатал на инлайн...

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

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

С>>>А вот могут ли компиляторы сделать так, чтобы в результирующем бинаре было несколько вариантов одного и того же кода — один под AVX, другой под SSE?
CC>>Могут. См ICC /Qax

Ops>Опаньки. Ты только что предложил самый куцый вариант для всех АМД. Или что-то в политике интела изменилось, и они поддерживают возможности процессоров АМД моложе 10 лет?

Все совпадающие с интеловыми, насколько я знаю, поддерживаются. После того, как им прижали хвост, они даже детектят их правильно. А что из специфических AMDʼшных возможностей настолько критично для обсуждаемых целей?

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

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

_>>В ответ на это компилятор сделает по одной бинарной версии функции под каждый процессор и плюс ещё собственно саму функцию (с нужным именем), представляющую собой форвард к нужной реализации. )

Ops>Это что же, функции будут через стабы вызываться? А я губы раскатал на инлайн...

Для инлайна нужно самому скомпилировать несколько объектных файлов на разных опциях.
Где-то выше всё равно будет стаб, но уже там, где лишний косвенный jmp некритичен.

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

Ops>>Зачем в десктопной программе гигабайтные текстуры?
V>Многомегабайтные запросто.

А что, во всех этих средствах удаленного доступа до сих пор нет какого-то механизма сбора статистики? Как в БД, где иногода нужно решить, как делать джойн двух таблиц — с левой на правую, или наоборот, и производительность этого сильно зависит от размера таблиц. Так и тут — где-то выгодно передавать сырую картинку, где-то — примитивы отрисовки, для каждого окна это индивидуально.

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

N>Все совпадающие с интеловыми, насколько я знаю, поддерживаются. После того, как им прижали хвост, они даже детектят их правильно. А что из специфических AMDʼшных возможностей настолько критично для обсуждаемых целей?

Я именно про общие с интелом. Не знал, что их прижали, раньше для АМД использовали только базовый древний набор команд. А еще, когда-то использовал ISPL (сейчас оно IPP и/или что-то еще), оно вообще только базовую библиотеку цепляло на любой AMD камень.

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

C>То есть? По традиции новые платформы сейчас обратно-совместимы с предыдущими.
Вот в этом-то и есть суть проблемы. Именно из-за этого система команд x86/x64 представляет из себя Адъ и Израиль, в котором без ящика водки не разберёшься. При том, что большая часть команд, режимов и подрежимов уже давным-давно устарела и не используется.

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

N>Именно что происходит — собранное для i386 спокойно выполняется на KabyLake а версия для SSE — на любом проце с SSE.
Это одна и та же архитектура.

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

N>И в случае x86 это имеет, за счёт тандема Intel — Microsoft, особенно злокачественные формы.
Это началось уже очень и очень давно, и MS тут вовсе ни при чём.

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

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

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

C>>То есть? По традиции новые платформы сейчас обратно-совместимы с предыдущими.
K>Вот в этом-то и есть суть проблемы. Именно из-за этого система команд x86/x64 представляет из себя Адъ и Израиль, в котором без ящика водки не разберёшься. При том, что большая часть команд, режимов и подрежимов уже давным-давно устарела и не используется.
Нет, ну тут надо выбирать одно из двух: или старый код работает на новых CPU, или переписываем всё каждую итерацию микроархитектуры.