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

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

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

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

I>>Ужос, редакторы который предназначался "быть не IDE" удруг не IDE.
CC>Пусть они хотя бы "будут редактором кода", с подсветкой, навигацией, рефакторингом и прочими обязательными фичами.
CC>А то этот Code последний раз как я на него смотрел даже простой С не поддерживал.

И ты разумеется уверен, что и по сей день ничего не изменилось ?

I>>Скажем, VS как не умела, так и не умеет внятно работать с фолдерами, как с проектами.
CC>Это как раз мелочёвка. Затянуть их в проекты — одноразово, и много времени не надо, даже автоматизируемо при желании.
CC>Мне больше непонятны те, кто усиленно жрёт кактус работает с рассыпухой файлов.

А что ты в ИДЕ делаешь ? Ну вот внятно перечислить можешь и объяснить, что именно тебе там надо ?

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

C>>>Нет, ну тут надо выбирать одно из двух: или старый код работает на новых CPU, или переписываем всё каждую итерацию микроархитектуры.
N>>У Intel было две потрясающие возможности убрать весь старый хлам — переходы 16->32 и особенно 32->64. Обе возможности она бездарно протеряла. (Ну, во втором AMD помогла, но тут они близнецы.)
C>Переход 16->32 состоялся, когда никто (в том числе и Intel) не думал, что x86 задержится надолго. Это был 85-й год, т.е. разработку начали где-то в 82-м году.

Так у них все такие изменения в линии x86 — с заглядыванием вперёд не более, чем на полшага, и обязательно минимально совместимо с предыдущим. Это не один случай, это система.

C>Переход 32->64 они попробовали сделать революционным, но получился Итаник.

И это действие такой же конструкции, как и предыдущие.

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

N>>Естественно, какие-то ограничения нужны. Иначе ты код для Мир-2 потребуешь исполнять

НС>Я взял тот же временной интервал — дату выхода i386. Windows 1.0 — его ровесник.

А надо брать от момента, когда i386 стал доступен массовой аудитории Windows. Это уже 1988-1990.

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

V>Наверно потому что то, чего сейчас служит D2D, раньше называлось DirectDraw?

Шеф, тормози! Чего-то тебя не туда заносит...

DirectDraw это был фактически механизм вывода напрямую в видео память минуя инфраструктуру окон. Т.е. low level blitting фактически.
Современный Direct2D и рядом не лежал к этому.

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

I>>>Ужос, редактор, который изначально задумывался как не-IDE, является не-IDE
CC>>И накой он такой красивый вообще нужен?
I>Редактировать всякое. Такие тулы вообще говоря адски популярны.
Понятно что редактировать? Чем он лучше прочих, чтоб поставить именно этот, несмотря на куцый функционал?

I>>>Это более популярный аналог VS Code.
CC>>Что то как то не похоже что он более популярный.
I>И как ты это выяснил ?
Да как то в моей окрестности про него не слышал никто.
Про VS Code — слышали, причём маководы, не виндузятники.

CC>>Главное в редакторе не движок а функционал.
I>Главное в редакторе это решение тех проблем, на которые он нацелен.
Ок, давай начнём издали и по шагам: какие проблемы надо решать при редактировании кода?

I>https://electron.atom.io/apps/
I>https://github.com/nwjs/nw.js/wiki/List-of-apps-and-companies-using-nw.js
Глану, пасиб!

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

CC>>А то этот Code последний раз как я на него смотрел даже простой С не поддерживал.
I>И ты разумеется уверен, что и по сей день ничего не изменилось ?
Гугление показало что воз и ныне там. Я б им пользовался если бы там всё как в полноценной вижуалке работало.

I>А что ты в ИДЕ делаешь ? Ну вот внятно перечислить можешь и объяснить, что именно тебе там надо ?
Из того, что надо каждый день:

Refactor rename, с пониманием scope, чекбоксом для каждого места где переименовать а где не трогать, чтоб понимало что надо включать в список кандидатов код под #ifdef вне зависимости от #define
Find symbol с пониманием scope, с правильной подсветкой где нашло, индикацией Read, Write или Ref op в том месте производится.
Next/prev для symbol по scope. Подсветка выделенного symbol по всему scope.
Extract code
Call hierarchy

ещё?

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

K>>> Вопрос упирается только в наличие эффективного jit/ngen
CC>>Jit сразу идёт в лес просто потому что у него банально нет времени и ресурсов генерировать эффективный код.

S>Это, интересно, с чего вдруг?
Потому что он "in time".
Он просто не может себе позволить уйти спать на минуту и сожрать гиг памяти чтоб произвести качественный код, как offline compiler c WPO.

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

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

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

N>А надо брать от момента, когда i386 стал доступен массовой аудитории Windows.

Опять отговорочки пошли. Не лезет сова, активно трещит.

N> Это уже 1988-1990.

Ну ок, в 90 вышла 3.0. По прежнему смешно.

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

_>Развитие архитектуры вроде как совсем не буксует.

И чего в последние лет 5 в топовых процессорах архитектурного внедрили?

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

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

Опять телега впереди лошади. Да потому и ситуаций таких мало, что развитие идет в основном экстенсивно, добавлением примочек.

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

N>>А надо брать от момента, когда i386 стал доступен массовой аудитории Windows.

НС>Опять отговорочки пошли. Не лезет сова, активно трещит.

В бредовых рамках твоих условий — ничего не налезет.

N>> Это уже 1988-1990.

НС>Ну ок, в 90 вышла 3.0. По прежнему смешно.

И давно уже шла разработка NT, проги уже были.

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

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

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

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

CC>>>И накой он такой красивый вообще нужен?
I>>Редактировать всякое. Такие тулы вообще говоря адски популярны.
CC>Понятно что редактировать? Чем он лучше прочих, чтоб поставить именно этот, несмотря на куцый функционал?

Куцый функционал, это ты про свои сведения "он даже С не умел" ?
Я напомню, мы вообще про редакторы на таких движках, алё, _семейство_ аналогичных тулов.

I>>И как ты это выяснил ?
CC>Да как то в моей окрестности про него не слышал никто.
CC>Про VS Code — слышали, причём маководы, не виндузятники.

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

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

CC>>>А то этот Code последний раз как я на него смотрел даже простой С не поддерживал.
I>>И ты разумеется уверен, что и по сей день ничего не изменилось ?
CC>Гугление показало что воз и ныне там. Я б им пользовался если бы там всё как в полноценной вижуалке работало.

Это мягко говоря враньё. Я напомню, что такие тулы не являются IDE, т.е. они используются там, где IDE нет.

I>>А что ты в ИДЕ делаешь ? Ну вот внятно перечислить можешь и объяснить, что именно тебе там надо ?
CC>Из того, что надо каждый день:

CC>Refactor rename, с пониманием scope, чекбоксом для каждого места где переименовать а где не трогать, чтоб понимало что надо включать в список кандидатов код под #ifdef вне зависимости от #define

Итак, все динамические языки этот пункт не требуют.

CC>Find symbol с пониманием scope, с правильной подсветкой где нашло, индикацией Read, Write или Ref op в том месте производится.

И здесь.

CC>Next/prev для symbol по scope. Подсветка выделенного symbol по всему scope.

И здесь.

CC>Extract code

И здесь.

CC>Call hierarchy

И здесь.

CC>ещё?

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

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

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

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

Байткод и есть компромисс.

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

V>>Наверно потому что то, чего сейчас служит D2D, раньше называлось DirectDraw?
CS>Шеф, тормози! Чего-то тебя не туда заносит...
CS>DirectDraw это был фактически механизм вывода напрямую в видео память минуя инфраструктуру окон.

Не понял этого заявления. Я писал когда-то на DirectDraw, там суть всё та же — создаётся поверхность, на ней рисуешь, потом эта поверхность отображается либо полноэкранно, либо в некоем конкретном окне (через блиттинг или оверлей, если железо позволяет). В OpenGL аналогом является frame buffer, созданный поверх текстуры или экранного буфера (deep buffer). Т.е. во всех случаях речь идёт о массиве байт в видеопамяти.

В D2D полностью аналогично, разве что идентификаторы участников чуть другие.


CS>Современный Direct2D и рядом не лежал к этому.

Лежал-лежал... ))
Там всей "принципиальной" разницы, что помимо непосредственного оперирования байтами, иногда надо что-то еще рисовать на поверхности, например, поверх видеокадра надо написать какой-нить текст (как раз у меня была такая задачка). В DirectDraw для функции рисования используется только лишь абстракция DC, т.е. так и вызываешь HDC dc = dxSurface->GetDC() и рисуешь себе. А в D2D поддерживается два АПИ для рисования — свой xxxRenderTarget, либо через ID2D1GdiInteropRenderTarget, который надо использовать точно так же, как в случае DirectDraw, т.е. dc = dxSurface->GetDC() и ву-а-ля. ))

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

V>>Лежишь себе на диванчике с ноутом или планшетом
CC>Странный use case, воистину.
CC>Последний раз когда я пользовался CAD-like софтом мне на 34" монике было внезапно тесновато.

Значит, ты ОЧЕНЬ давно пользовался этим софтом. В лучшем случае в начале/середине 2000-х. ))


CC>А про планшетик или ноут — это какой то мазохизм. Ты ещё с мобилки предложи.

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

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

V>>Наверно потому что то, чего сейчас служит D2D, раньше называлось DirectDraw?
CC>Да всё равно как называлось. Гуй на нём в те времена никому в голову не приходило делать.

Т.е. делали без прихождения в голову!
Мощно задвинул! )))


CC>>>Всё было на GDI.
V>>Да все, кому надо было видео, анимация, даже просто CAD-программу с кучей линий на GDI не сделаешь — жутко тормозило-с.
CC>Мы всё ещё про гуй?

Конечно.