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

НС>>Т.е. все таки не будет. ЧТД.
I>Будет или нет зависит от профита. Или ты думал "а докажи" это классная такая игра на все времена и возрасты ?

Бремя доказательства лежит на том, кто выдвинул утверждение. Все остальное — твоя нелепая попытка замаскировать, что утверждение высосано из пальца.

НС>>Слива.
I>Скукота. Никакого разнообразия.

И не говори.

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

_>Хотя недостаток не очень серьёзный, т.к. нет никаких проблем в перекомпиляции ПО при выходе нового поколения процессоров.

Вот и Интель так думала, когда свой Итаник запускала. Ан нет, не вышел каменный цветок.

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

CC>Да что байт код, даже сурсы не позволяют обеспечить полную переносимость программы между архитектурами для сколь либо существенной функциональности. Всегда что нибудь да приходится перепиливать.

И как та же IDEA работает — непонятно. Видать функциональность на достаточно существенную не тянет.

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

N>Что-то я не могу найти (а через рекламный шум Microsoft продраться крайне сложно). Если для UWP можно писать на C++, то о каком байткоде идёт речь?

МСный компилятор С++ давным давно умеет генерировать IL. Но уровень спора, конечно, внушает.

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

CC>Тебе шашечки или ехать?
CC>Работает быстрее.

Если бы. Работает оно быстрее на обещаные проценты только на специальной синтетике, заточенной под использование очередного расширения AVX. А на типовых задачах в лучшем случае процента 3 покажет, а иногда так вообще медленнее выходит.

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

K>А если есть пять разных функций, которые по-разному "ускоряются" на разных архитектурах?

Зато не надо ничего менять. Оно так и начинается. А заканчивается тем, что человек начинает всем доказывать, что смартфоны не нужны. К счастью, облик индустрии формируют совсем другие люди.

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

I>То есть, большей частью функций IDE пользоваться всё равно не выйдет.
Почему не выйдет? Refactor rename работал замечательно, но я никогда не переименовывал что то реально глобальное, как ты просишь.

I>То есть, совсем недавно. Просекаешь?
Угу, году так в 2003м, если не раньше.

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

НС>>>Т.е. все таки не будет. ЧТД.
I>>Будет или нет зависит от профита. Или ты думал "а докажи" это классная такая игра на все времена и возрасты ?

НС>Бремя доказательства лежит на том, кто выдвинул утверждение. Все остальное — твоя нелепая попытка замаскировать, что утверждение высосано из пальца.

Непойму, мы что, в суде или это у тебя такие фантазии ?

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

I>>То есть, большей частью функций IDE пользоваться всё равно не выйдет.
CC>Почему не выйдет? Refactor rename работал замечательно, но я никогда не переименовывал что то реально глобальное, как ты просишь.

Рефакторинг в твоём случае ограничен перформансом IDE. И рефакторинг вобщем глобальный инструмент. Локально можно побороть проблему десятком разных способов, хоть взять влоб да переписать.

I>>То есть, совсем недавно. Просекаешь?
CC>Угу, году так в 2003м, если не раньше.

Хорош врать, вижла в 2003м была 32х битная, а это значит 2гб на процесс и кердык. В 2003м даже винда у редких гиков была 64бита.
SSD массово начали ставить совсем недавно. в 2003м SSD даже у гиков не было.

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

НС>>Бремя доказательства лежит на том, кто выдвинул утверждение. Все остальное — твоя нелепая попытка замаскировать, что утверждение высосано из пальца.
I>Непойму, мы что, в суде или это у тебя такие фантазии ?

"нелепая попытка замаскировать, что утверждение высосано из пальца"

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

I>Хорош врать, вижла в 2003м была 32х битная

Вижла, внезапно, и в 2017 32-битная.

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

CC>>>Где на них посмотреть in the wild? Именно те реализации которые производят именно байт-код.
_>>В смысле?
CC>В смысле проекты, которые собраны именно в байт-код а не в честный машинный бинарь.

Так я же тебе говорю, что ты можешь любой (ну почти — надо чтобы он не использовал скажем встроенный ассемблер и т.п.) свой C++ проект собрать в этот байт код, всего лишь добавлением пары опций в командную строку Clang'а. И проверить сам, как это всё работает и как влияет на быстродействие.

Насчёт использования этого в каких-то реальных проектах... Ну например webassembly практически так и работает. Так же слышал, о реализации плагинов в своё ПО на базе этого подхода. А вот о компиляции проектов целиком под байт-код, с компиляцией под машину при установке я что-то не слышал (но это не значит, что такого нет), хотя технических с этим никаких проблем нет (если не считать необходимости тащить многомегабайтную LLVM в своём дистрибутиве).

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

_>>Развитие архитектуры вроде как совсем не буксует.
НС>И чего в последние лет 5 в топовых процессорах архитектурного внедрили?

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

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

I>>Хорош врать, вижла в 2003м была 32х битная

НС>Вижла, внезапно, и в 2017 32-битная.

Тогда понятно, почему рефакторинг у CreatorCray не палит.

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

_>>Собственно данная оптимизация имеет смысл только во вполне определённом случае: если у нас есть критическая для приложения функция, которая ускоряется в разы на процессорах отличных от определённых как минимальные требования для данного ПО.
НС>Опять телега впереди лошади. Да потому и ситуаций таких мало, что развитие идет в основном экстенсивно, добавлением примочек.

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

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

_>>Развитие архитектуры вроде как совсем не буксует. Более того, в последние годы это по сути единственный работающий способ, способный увеличивать производительность процессоров на универсальных задачах (а не только на узком классе задач, поддающихся лёгкому распараллеливанию).
K>Оно не просто буксует — оно встало колом и никуда не движется. Или ты из тех, кто считает 7-gen i7 новой архитектурой по сравнению с 6-gen i7?

Речь немного не о том. Я сказал, что основное развитие топовых процессоров идёт в основном за счёт архитектурных изменений (а не частоты и т.п. количественных параметров, которые уже давно не растут). То, что прирост быстродействия в последние годы не очень велик — это правда (собственно я сам уже давно об этом писал, как об одной из главных причин существенных сдвигов в мире разработки ПО), но всё это небольшое увеличение обеспечено как раз архитектурными улучшениями.

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

_>>Собственно данная оптимизация имеет смысл только во вполне определённом случае: если у нас есть критическая для приложения функция, которая ускоряется в разы на процессорах отличных от определённых как минимальные требования для данного ПО. Соответственно в таком случае мы указываем в списке минимальное требование (как и для всего остального кода в проекте) и плюс те поколения процессоров, на которых происходит принципиальный скачок в производительности для данной функции.
K>А если есть пять разных функций, которые по-разному "ускоряются" на разных архитектурах? Неужели непонятно, что это путь в тупик?

Ну так и в чём проблема? Настройка то указывается на функцию, а не на проект, так что никакого комбинаторного взрыва или каких-то мешающих друг другу взаимодействий не будет.

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

_>>В смысле? Ты не знаешь какую производительность выдаёт Clang? ) Конечно он чуть похуже чем gcc и icc, но не так чтобы очень существенно. Если хочется посмотреть при этом непосредственно на байт код, то разделение компиляции на отдельные этапы (в начале в байт-код, а потом в нативный) делается там просто лишним ключиком командной строки.
Ops>В том смысле, что хочется систему, где программы поставляются в байт-коде, а потом на конкретной архитектуре дособираются. Пока я вижу такое только в дотнете: поставил программу, и система там сама шуршит, нгенит, и при этом позволяет и сразу запустить, пусть чуть медленнее. А в идеале было бы, чтобы и ядро системы пересобиралось под конкретную архитектуру.

Я согласен, что это оптимальный сценарий (разве что лучше чтобы докомпиляция происходила при инсталляции, а не при запуске). И как раз LLVM без проблем его реализует (причём без таких потерь в производительности, как у .Net). Только вот чтобы такой подход распространения ПО стал популярным, надо бы чтобы хоть одна популярная ОС имела в себе предустановленную инфраструктуру LLVM (ну или его аналога)...

Кстати, в какой-то степени это уже реализуется на наших глазах — см WebAssembly. Только там в роли ОС выступают браузеры (причём тут будет даже не один из популярных, а смогли договориться об этом все популярные) и соответственно область применения более узкая.

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

CS>У CPU вообще нет доступа к видео памяти в том же виде что и основной памяти.

Безусловно его нет. Более того, если бы обмен данными между обычной памятью и видео-памятью происходил с помощью инструкций CPU, то это было бы катастрофически медленно. Однако в CPU (и не только — сейчас это уже даже в копеечных МК присутствует) имеется такой механизм работы с периферией как DMA, который позволяет периферийным устройствам обмениваться с памятью процессора в фоне (без его прямых команд). Соответственно при включение этого механизма запись в определённые разделы оперативной памяти по сути полностью аналогична записи в видео-память. И думаю что большинство участников дискуссии имели в виду именно это, просто не расшифровывая очевидные детали.

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

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

CS>>У CPU вообще нет доступа к видео памяти в том же виде что и основной памяти.

_>Безусловно его нет. Более того, если бы обмен данными между обычной памятью и видео-памятью происходил с помощью инструкций CPU, то это было бы катастрофически медленно. Однако в CPU (и не только — сейчас это уже даже в копеечных МК присутствует) имеется такой механизм работы с периферией как DMA, который позволяет периферийным устройствам обмениваться с памятью процессора в фоне (без его прямых команд). Соответственно при включение этого механизма запись в определённые разделы оперативной памяти по сути полностью аналогична записи в видео-память. И думаю что большинство участников дискуссии имели в виду именно это, просто не расшифровывая очевидные детали.

Всё верно, только оппоненты в дискуссии имели в виду именно "DDB это video память" и "GDI hardware accelerated".

Я же говорю (и MSDN) что у GDI hardware accelerated только BitBlt (фактически это и есть DMA).
Также я говорю (и Фень Юань) что DDB это область RAM а не video RAM. То есть DDB это и есть твои "определённые разделы оперативной памяти".

Вышеизложенное означает что GDI в принципе не может иметь per primitives hardware accelerated drawing.

Т.е. DrawLine(hdc, ...) это банальный Брезенхем исполняемый CPU и изменяющий RAM. Т.е. этот механизм есть O(N) где N это количество пикселей на экране. Т.е. sucks on high-dpi monitors.

В Direct2D, DirectX, OpenGL же DrawLine() это (условно) посылка quad (четырех координат) на GPU для отрисовки его процессорами (shaders, etc).
Т.е. этот механизм для CPU есть O(1) complex — на зависит от размера экрана.