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

НС>>Это важно?
CC>Да

Почему?

CC>>>Дай бинарь.
НС>>Какой бинарь у JIT? Оно только в памяти.
CC>Дай дамп.

Это не так просто сделать.

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

C>Потому я и сказал про "современные приложения" — они рисуют контролы вручную сами, потому по проводу пересылаются в виде битмапов.

Можно вопрос — а вот нахрена они рисуют контролы сами? Это чтобы настройки OS по шрифтам, цветам, масштабированию и прочему — не работали? Зато дизайнер удовлетворён, вместе с менеджером! Я бы предложил им более простой способ удовлетворения — пусть друг с другом того этого, а софт оставят в покое.

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

НС>Чего, вот так полкода под x64, полкода под ARM?

Положим, один бинарник под x64, другой под ARM.

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

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

V>>В RDP аналогично.
CC>В RDP в большинстве шлётся не битмапка а команды, которые её генерят.

С разморозкой!
Твои сведения устарели лет на 15 или даже больше.

Уже с начала 2000-х почти вся неординарная прорисовка происходит через double-buffer даже по технологиям устаревшего GDI (взять тот же GDI+ и банальный WinForms), а уж в DirectX или OpenGL — так другой там другой прорисовки и нет, кроме цепочки (минимум двух) сменяющих друг друга фреймов.

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

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

Не очень. WPF (вернее, его нейтивная DX-часть) использует Blt-mode от устаревшего DX9. ))
Хотя драйвер RDP прекрасно захватывает изменения по более новой технологии Flip-mode.
Просто на этот WPF забили болт и я лет 5 назад подробно объяснял — почему (невозможность вызывать DX-команды напрямую).

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

CC>В нативном коде это сразу будет скомпилировано в AVX/SSE вариант и на этом все успокоятся.

Угу... И это при том, что в 2017-м году я вынужден компилять нейтивные проги под первый стандарт SSE, которому уже скоро 20 лет.

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

CC>Поднимите руки кто всерьёз писал на ассемблере.

Поднял, и?
Плотно писал суммарно около 4-х лет под пяток разных архитектур.
Что это доказывает или не доказывает и при чём тут?


CC>Потому что как то с пониманием что как и почему происходит на низком уровне устроено у вас какое то странное.

Понимание как раз отличное. Как и понимание того, что привязка к ЛЮБОЙ конкретной архитектуре, будь она даже самой лучшей на "сегодня" — это всегда тормоз прогресса "завтра".

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

V>> Это тот самый технологический тупик, который всех нас зажал в узкие рамки на ближайшие несколько десятилетий. В общей, вот этот груз "легаси-совместимости" на данном этапе невозможно никак перепрыгнуть. Это полная ж-па как она есть, сорри за обилие эпитетов. ))
CC>Мда, куча эмоций а толком ничего и не сказано.
CC>Задайся лучше вопросом почему никто не заморочился идеей перекомпиляции. По сути что P-code что машинный — один фиг, описание что надо сделать в итоге. Может потому что отличия не только в инструкциях?

Почему же "никто не заморочился"? Apple исполнял на своих PowerPC машинах код от M68k такой перетрансляцией при запуске.
Эльбрус (обсуждаемый в соседней ветке) транслирует коды x86 (от неизбежности, но делает же).
Есть qemu, в которой команды эмулируемого процессора переводятся в цепочки, которые затем JITʼятся в хозяйский процессор.
Но по любому скорость, конечно, падает по сравнению с тем, что было бы при чисто нативной компиляции. Из абстрактного кода было бы прямее.

CC>Чтобы получить максимум производительности на другой архитектуре надо писать логику, которая будет использовать преимущества этой архитектуры.

Так сейчас и компиляторы не используют все преимущества.
GCC, LLVM, например, делают такую арифметику, которая годится для архитектур, где нет вообще флагов условий (это как минимум MIPS, Alpha, RISC-V). Зато она легче транслируется на другие процессоры.

V>> И как раз в первую очередь в плане загружаемых "на лету" по-настоящему переносимых и безопасных приложений (и/или их частей), что должно было стать стандартом де-факто работы гипотетического "современного компьютера".
CC>Надеюсь никогда не станет. Ибо до сих пор где правильный кошерный бинарь: мало ест и работает быстро. Где байт-код — тормоза и пожирание памяти.
CC>Какая самая большая проблема в тех же браузерах? Правильно, Javascript.

С Javascript проблемы, по данным народа типа разработчиков V8, растут от затрат типа "определить тип данного при каждом вызове операции" и "каждое поле приходится пролукапить через два прототипа с хэш-функцией на каждом", и основные оптимизации идут на кэширование именно этих данных.
В языках типа Java, C# этих затрат уже нет, типы определены в байткоде (и JIT получает данные о них без дополнительных затрат), лукапы сразу переводятся в смещение от указателя на объект.

UPD:
CC> Дыра в безопасности зависит от ошибок в коде а не от бинарности.

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

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

V>Уже с начала 2000-х почти вся неординарная прорисовка происходит через double-buffer даже по технологиям устаревшего GDI (взять тот же GDI+ и банальный WinForms), а уж в DirectX или OpenGL — так другой там другой прорисовки и нет, кроме цепочки (минимум двух) сменяющих друг друга фреймов.
И? RDPDD видит всё, что посылается в драйвер через GDI и DX. Что ему мешает отправлять команды создания буфера/текстуры, рисования в буфер/текстуру а потом команду Blt этого буфера? Запись из обычной памяти в битмапу/load texture шлётся битмапой и кэшируется на клиенте. Все операции с этой битмапой же посылаются в виде команд.
Проигрываешь последовательность команд на той стороне — получаешь такой же результат.

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

V>Угу... И это при том, что в 2017-м году я вынужден компилять нейтивные проги под первый стандарт SSE, которому уже скоро 20 лет.
Где ты процы с ним находишь? У меня минимум что есть — старый нетбук с атомом, но и там SSSE3

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

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

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

N>Почему же "никто не заморочился"? Apple исполнял на своих PowerPC машинах код от M68k такой перетрансляцией при запуске.
N>Эльбрус (обсуждаемый в соседней ветке) транслирует коды x86 (от неизбежности, но делает же).
N>Есть qemu, в которой команды эмулируемого процессора переводятся в цепочки, которые затем JIT?ятся в хозяйский процессор.
Это всё интерпретация или JIT.
Я же про перекомпиляцию, которая offline и занимает сколько потребуется времени.

N>GCC, LLVM, например, делают такую арифметику, которая годится для архитектур, где нет вообще флагов условий (это как минимум MIPS, Alpha, RISC-V). Зато она легче транслируется на другие процессоры.
Это неправильный подход. Компилятор должен выжимать максимум из платформы а не генерить вялый код, потому что ему так проще.

N>С Javascript проблемы, по данным народа типа разработчиков V8, растут от затрат типа "определить тип данного при каждом вызове операции" и "каждое поле приходится пролукапить через два прототипа с хэш-функцией на каждом", и основные оптимизации идут на кэширование именно этих данных.
Память js-тяжёлая страница жрёт тоже поэтому?
Там проблема комплексная — хреновый язык.

N>От бинарности тоже. Невозможность проанализировать код на предмет того, куда он неположенно лезет, приводит к тому, что коду нельзя доверять.
Сложнее != невозможно.

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

V>Понимание как раз отличное. Как и понимание того, что привязка к ЛЮБОЙ конкретной архитектуре, будь она даже самой лучшей на "сегодня" — это всегда тормоз прогресса "завтра".
Вопрос что важнее твоему бизнесу: или ты generic просто до безобразия и можешь быстро менять архитектуры но оно одинаково плохо работает везде либо ты быстро работаешь именно здесь и сейчас.
Что то мне кажется что второй подход более оправдан.

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

V>использует Blt-mode от устаревшего DX9. ))
А не всё ли равно через какую версию API слать команду Blt?

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

C>Всё как обычно — есть кривости, сам мир JS-разработки коряв до невозможности (npm, bower и т.д.), но таки работает и позволяет быстро создавать клиентские приложения. Которые работают при небольших усилиях на всех основных платформах.
Угу, при небольших усилиях. Тут вёрстка поехала, тут скрипты тормозят безбожно, тут заембеддили шрифт а он выглядит как говно не на uber high DPI.
Щастя нет.

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

V>>Уже с начала 2000-х почти вся неординарная прорисовка происходит через double-buffer даже по технологиям устаревшего GDI (взять тот же GDI+ и банальный WinForms), а уж в DirectX или OpenGL — так другой там другой прорисовки и нет, кроме цепочки (минимум двух) сменяющих друг друга фреймов.
CC>И? RDPDD видит всё, что посылается в драйвер через GDI и DX. Что ему мешает отправлять команды создания буфера/текстуры, рисования в буфер/текстуру а потом команду Blt этого буфера?

Да ничего не мешает. Ну разве что для какой-нить 3D-игры это будет означать дублирование просчёта сцены на стороне терминала.


CC>Запись из обычной памяти в битмапу/load texture шлётся битмапой и кэшируется на клиенте. Все операции с этой битмапой же посылаются в виде команд.

Верно. Там фактически две основных операции — установка матрицы преобразования и посылка списка вершин с указанием привязки координат к текстурам.


CC>Проигрываешь последовательность команд на той стороне — получаешь такой же результат.

И я о том же!
Осталось такую же по мощности видюху на удалённый терминал поставить и ноу проблем!

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

V>Ну разве что для какой-нить 3D-игры это будет означать дублирование просчёта сцены на стороне терминала.
Почему дублирование? На хосте подготовили список на выполнение, на клиенте его выполнили.

CC>>Проигрываешь последовательность команд на той стороне — получаешь такой же результат.
V>Осталось такую же по мощности видюху на удалённый терминал поставить и ноу проблем!
Мы всё ещё про remote desktop или про игру на remote машине?

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

CS>Direct2D это вообще по своей природе не bitmaps, а поток команд транслируемых в GPU примитивы вывода, сиречь batch processing в самом сермяжном виде.

Одно но — все текстуры предварительно надо загрузить в видео-память и только потом их можно использовать. Такая предварительная загрузка текстур может занять несколько минут по сетке.


CS>А в GDI для этой же цели metafiles.

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

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

V>>Угу... И это при том, что в 2017-м году я вынужден компилять нейтивные проги под первый стандарт SSE, которому уже скоро 20 лет.
CC>Где ты процы с ним находишь? У меня минимум что есть — старый нетбук с атомом, но и там SSSE3

Он у тебя потому и "старый", что с атомом. ))
А какой-нить топовый десктоп десятилетней давности прекрасно пашет у людей до сих пор.
Там видюху поменяли и память нарастили. Остальное вполне актуально.

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

V>>Понимание как раз отличное. Как и понимание того, что привязка к ЛЮБОЙ конкретной архитектуре, будь она даже самой лучшей на "сегодня" — это всегда тормоз прогресса "завтра".
CC>Вопрос что важнее твоему бизнесу: или ты generic просто до безобразия и можешь быстро менять архитектуры но оно одинаково плохо работает везде либо ты быстро работаешь именно здесь и сейчас.

Я здесь причём?
В эти рамки втиснута вся отрасль.
В первую очередь — разработчики процессоров.