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

_>Вообще то динамическую загрузку нужного кода, в зависимости от типа процессора делали руками уже не первое десятилетие.

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

_>Например в GCC ты можешь указать в атрибутах функции набор нужных процессоров (например с SSE, с AVX и т.п.), под которые нужно её скомпилировать.

А под которую нужно?

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

C>То есть? По традиции новые платформы сейчас обратно-совместимы с предыдущими.

Не по традиции, а вынужденно.

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

N>Именно что происходит — собранное для i386 спокойно выполняется на KabyLake

И чего в этом хорошего? А если бы тебя заставили написать программу, выполняющуюся и в Windows 10 и в Windows 1.0?

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

N>Для инлайна нужно самому скомпилировать несколько объектных файлов на разных опциях.

И чем это лучше байткода с докомпиляцией на конкретной машине?

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

_>основное применение SIMD — это векторизация произвольных циклов.

Это утверждение нуждается в доказательстве.

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

N>>Для инлайна нужно самому скомпилировать несколько объектных файлов на разных опциях.

НС>И чем это лучше байткода с докомпиляцией на конкретной машине?

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

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

I>Visual Studio Code, Atom — ты как нибудь поинтересуйся

Интересовались уже, неоднократно. По сравнению с настоящей VS — гавнно гавном. Пользоваться можно только на безрыбье. Ну или если ты хипстер.

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

C>Нет, ну тут надо выбирать одно из двух: или старый код работает на новых CPU, или переписываем всё каждую итерацию микроархитектуры.

Или используем промежуточный язык и докомпиляцию на конкретной машине.

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

N>Ограничения же могут быть лицензионные — ставить компилятор уровня icc на каждую машину это... мнэээ... дорого.

Он же бесплатный есть — https://software.intel.com/en-us/articles/free-ipsxe-tools-and-libraries

N> А где-то банально может диска не хватить.

Это ты сейчас серьезно?

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

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

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

С точки зрения внутреннего устройства процессоров — между ними ничего общего, кроме кремния.

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

Ну да, согласен с кэпской частью этой фразы. Но в общем случае, как уже сказали, байт-код — не гарантия эффективности результата такого переноса.

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

В плане стимуляции некоторых решений Intel — очень даже при чём.

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

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

N>>Именно что происходит — собранное для i386 спокойно выполняется на KabyLake

НС>И чего в этом хорошего? А если бы тебя заставили написать программу, выполняющуюся и в Windows 10 и в Windows 1.0?

Давай ограничимся 32-разрядным режимом. То есть это будет 3.11+Win32s vs. Win10. В таком случае, думаю, уже реально увидеть программу, которая работает в обоих. И она вполне может даже выполнять что-то очень важное полезное.

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

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

C>Нет, ну тут надо выбирать одно из двух: или старый код работает на новых CPU, или переписываем всё каждую итерацию микроархитектуры.
Байт-код позволяет переложить это на плечи разработчика рантайма.
P.S. У меня как-то была идея реализовать проц с аппаратным GC на FPGAшке — правда, продвинулся не особо далеко

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

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

Почти. Курсовик одного из отпрысков. Стек гитарных эффектов. ))

	Скрин-шот

Текстуры имеют разрешение с прицелом на экраны с высоким DPI в т.ч.
В развернутом виде это многие десятки мег текстур в памяти.
И это черновик программы, считай, а не сама программа.


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

	А вот тут нахрена?

Законы жанра.


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

Это еще копейки. Ты возьми какой-нить CAD-пакет для того же строительства. Вот уж там текстур в память грузится — мама не горюй. Не каждая видюха потянет более-менее приличный проект.

По ссылке картинко в большом разрешении:
http://i2.piimg.com/568686/03c2dda731d73e78.jpg

В гугле подобного навалом.

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

N>С точки зрения внутреннего устройства процессоров — между ними ничего общего, кроме кремния.
Система команд та же.

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

N>В плане стимуляции некоторых решений Intel — очень даже при чём.
Примеры приведёшь? Только чтоб они были лет эдак 20 назад, когда защищённый режим только начал появляться (ибо многие считают этот момент поворотным в эволюции x86).

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

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

Верно. Только уже последние лет 10 и более новые проги не рисуют через GDI.
Собсно, об этом и было моё первоначальное замечание.

Есть просто окно верхнего уровня, а растеризация подробностей происходит "где-то еще" — в offline-битмапе или непосредственно в памяти карточки.

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

V>Текстуры имеют разрешение с прицелом на экраны с высоким DPI в т.ч.
V>В развернутом виде это многие десятки мег текстур в памяти.
V>И это черновик программы, считай, а не сама программа.

Это не для работы. Оно может даже будет продаваться, но не как профессиональный инструмент. Я, конечно, не против раскраски кода в IDE, но вот немотивированное превращение ее в светофор мне нафиг не сдалось, и плагин, натягивающий на нее текстуры, я ставить не буду.

V>Законы жанра.

Что за жанр такой? Нормальный софт, вот так, например, выглядит:

	Скрытый текст

Конечно, не без крутилок, но они мелкие, и в целом сравнимы с расходами на иконки для кнопок

V>Это еще копейки. Ты возьми какой-нить CAD-пакет для того же строительства. Вот уж там текстур в память грузится — мама не горюй. Не каждая видюха потянет более-менее приличный проект.

От оно. Такой софт и не гоняют удаленно.

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

N>Давай ограничимся 32-разрядным режимом.

О, уже ограничения понадобились.

N> То есть это будет 3.11+Win32s vs. Win10. В таком случае, думаю, уже реально увидеть программу, которая работает в обоих. И она вполне может даже выполнять что-то очень важное полезное.

Но выглядеть она все равно будет как гавно.

N>В случае же x86 — сборка под i386, конечно, даст немного неоптимальный код, но позволяет покрыть огромнейший диапазон функциональности.

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

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

V>Почти. Курсовик одного из отпрысков. Стек гитарных эффектов. ))
V>Законы жанра.

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

Но скажи, зачем на этих тум-балалайках изображать морды каких-то усилков и прочей ерунды? Что, обычных слайдеров не хватает? Или графа звукового потока, где в каждом узле стоит свой обработчик с ползунками?

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

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

V>Да не верю, не убедишь.
А оно мене надо, тебя убеждать?

V>Иначе бы не рассуждал отдельно о DX 3D и отдельно о 2D. Тем более, что в DX9 никакого 2D нет и вообще до Win7 не было

Первый HW accelerated 2D появился внутри винды где то в ХР, насколько я помню. Потом в висте его сломали, в W7 вернули назад и прикрутили Direct2D для более public доступа.

V>Поздно ты спохватился. ))
Спохватился? О чём ты?

V>Столько слов вместо простого признания в том, что ранее ляпнул не подумав.
Не юли.
Съехал с темы ты, а пургу гонишь на меня.

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

_>Ты не прав, сама идея универсального байт-кода вполне хороша.
Теория может и хороша. Но вот практика вносит свои коррективы.

_>Если же ты посмотришь на нормальные реализации этой идеи, типа того же LLVM, то увидишь, что там с быстродействием в принципе всё очень не плохо.
Где на них посмотреть in the wild? Именно те реализации которые производят именно байт-код.