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

V>ИМХО, самое ключевое в статье сказано сразу:
V>

V>Vista was planned for and built for hardware that did not exist.

V>В MS неверно оценили имеющуюся на 2003-й год динамику роста быстродействия ядер процессоров, т.е. они разрабатывали мощнейшую "архитектуру ПО будущего", чтобы первыми суметь "дать еды" будущим мега-мощным вычислениям. А в 2004-м году рост быстродействия в пересчёте на ядро фактически встал колом. Да еще мобильный сегмент пошёл развиваться.

V>Всё остальное — лишь следствие и попытки выкрутиться из сложившейся ситуации.

Наоборот, они решили пересмотреть концепцию OS. А вот исполнение этого подход вышло кривым до безобразия — они опаскудили всё, что было связано с менеджед подходом. Опаскудили именно потому, что выпустили OS под несуществующее железо.
То есть, и задумка, и реализация были убогими. Скажем, та же задумка совсем необязательно требует экспоненциального роста производительности железа. Опаньки!

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

_>Если бы MS угробили чертову силу на managed — сразу были бы сделаны .NET Native или JIT-всемогутор, вылизан WPF до уровня движков современных 3D-игр, C#-scripting в IE, и т.п. Но ничего этого нет, более того даже назревшие изменения в CLR заворачивались с "нет ресурсов". Так что статье верится мало.

Товарищ повторяет давно известные вещи. "сразу были бы сделаны" — дотнет толкали политическими методами, потому он получил те самые родовые травмы.

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

CC>>Они всё больше во всяких приставках светятся в последнее время.
Ops>Ты почитай, они в этом году как раз отыгрывать начали.
Что читать, я их чуткаи прикупил в расчёте на это
Жалко что не взял пока они вообще по $4 были.

Ops>Да ладно? Кому продают?
Ну я например фильмы покупаю. Не люблю стриминг.

Ops> Кому вообще сейчас нужны диски, любые?
Как writable media — никому. BDROM же — полно.

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

I>Ужос, редактор, который изначально задумывался как не-IDE, является не-IDE
И накой он такой красивый вообще нужен?
Он как редактор даже не тянет — пустой функционально.

I>>> Atom
CC>>Вообще хз что это.
I>Это более популярный аналог VS Code.
Что то как то не похоже что он более популярный.

I> Огромное количество девелоперов юзает один из двух редакторов, что я привел.
Ну, удачи им, чо.
Колво не показатель, но вот интересно что я знаю больше людей которые пишут в vim чем в этих двух.

I> Кроме того, есть и другие редакторы на этом же движке, и другие тулы.
Главное в редакторе не движок а функционал.

I> Посмотри, какие софтины пишут на Electron и nwjs.
Вот честно, нет никакого интересу тратить время и выяснять.
Если ты знаешь примеры — просто накидай ссылок.

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

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

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

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

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

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

Впрочем... boring conversation anyway.

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

CC>>Кому должен? Кто такую задачу ставил?
V>Билл Гейтс лично, разумеется. ))
Fwd or GTFO!

V>Среди данной цепочки обсуждения, которую ты уже успел потерять — для пользования мощным CAD.
V>в соседней комнате пыхтит мощный комп.
V>Работает прекрасно.
Если работает — замечательно. Локально можно хоть полноэкранное видео гонять, дури нынче много. Вон, всякие *cast понапридумывали.

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

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

N>У Intel было две потрясающие возможности убрать весь старый хлам — переходы 16->32 и особенно 32->64.
N> Обе возможности она бездарно протеряла.

У них была ровно одна попытка "убрать хлам" — Itanium.
Напомнить чем закончилось?
Железо без софта никому не нужно.
Поэтому backward compatibility очень важен.

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

CC>Мне больше непонятны те, кто усиленно жрёт кактус работает с рассыпухой файлов.

Хипстеры. У них так модно нонче. И это говно они и в VS пытаются тянуть. Последние вести с полей — nuget теперь для фронтенда некошерен, следует использовать bower или, если совсем не повезет, npm.

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

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

Есть даже такое слово -- wintel.

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

I>>Ужос, редактор, который изначально задумывался как не-IDE, является не-IDE
CC>И накой он такой красивый вообще нужен?

Редактировать всякое. Такие тулы вообще говоря адски популярны.

I>>Это более популярный аналог VS Code.
CC>Что то как то не похоже что он более популярный.

И как ты это выяснил ?

I>> Огромное количество девелоперов юзает один из двух редакторов, что я привел.
CC>Ну, удачи им, чо.
CC>Колво не показатель, но вот интересно что я знаю больше людей которые пишут в vim чем в этих двух.

Это отменяет факт использования таких тулов ? Браво.

I>> Кроме того, есть и другие редакторы на этом же движке, и другие тулы.
CC>Главное в редакторе не движок а функционал.

Главное в редакторе это решение тех проблем, на которые он нацелен.
Ты, похоже, всех по себе меряешь. Раз тебе не нужен, то и другим не надо. Поздравляю!

I>> Посмотри, какие софтины пишут на Electron и nwjs.
CC>Вот честно, нет никакого интересу тратить время и выяснять.
CC>Если ты знаешь примеры — просто накидай ссылок.

https://electron.atom.io/apps/
https://github.com/nwjs/nw.js/wiki/List-of-apps-and-companies-using-nw.js

Кстати говоря, Микрософт активно балуется этими вещами. У них Azure Explorer именно на этой хрени написан.

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

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

N>>У Intel было две потрясающие возможности убрать весь старый хлам — переходы 16->32 и особенно 32->64.
N>> Обе возможности она бездарно протеряла.

CC>У них была ровно одна попытка "убрать хлам" — Itanium.

Нет, у них были две возможности при переходе разрядностей.

CC>Напомнить чем закончилось?

Itanium был попыткой не "убрать хлам", а ввернуть принципиально новую непроработанную и неподдерживаемую концепцию. Потому и провалился. Сам по себе он местами больший бред, чем x86.

CC>Железо без софта никому не нужно.
CC>Поэтому backward compatibility очень важен.

Так он был бы естественным образом сохранён. Разумеется, если не допускать туда итановодов.

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

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

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

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

Нет связи.

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

V>И как ты тогда отличишь один инструмент от другого? По названию мелким шрифтом в углу? ))

Можно по цвету заливки, например.

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



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

Это, интересно, с чего вдруг?

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

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

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

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

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

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

K>>Очень херовый подход, т.к. совместимость только в обратную сторону. То есть перенести бинарь на платформу, которой не существовало в момент компиляции, невозможно.
C>То есть? По традиции новые платформы сейчас обратно-совместимы с предыдущими. И в любом случае, механизм ifunc проверяет наличие нужных флагов в CPUID процессора, а не название платформы. И если на новой платформе их нет, оно просто уйдёт в базовую реализацию без всяких оптимизаций.

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

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

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

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

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

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

Можешь назвать ещё какое-то применение? )))

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

CC>>Мне больше непонятны те, кто усиленно жрёт кактус работает с рассыпухой файлов.

НС>Хипстеры. У них так модно нонче. И это говно они и в VS пытаются тянуть. Последние вести с полей — nuget теперь для фронтенда некошерен, следует использовать bower или, если совсем не повезет, npm.

bower давно отстой. npm хватает на всё