Значит, по-Вашему, ПЗУ уже не существует. А ОЗУ? Или теперь все данные хранятся в другом измерении? 
Коба он был… А Сталина, насколько я помню, сам себе придумал, как Говард “рокетмена” в “Теории большого взрыва”. Ну и в последующие времена товарищи не осмелились перечить, Кобу забыли…
Почему не существуют? 
Существуют, конечно – как интегрированные компоненты устр-ва, являющиеся неотъемлемой частью его архитектуры и адресного пространства, т.е. без которых оно (устр-во) нормально работать не сможет.
Подготовил демку, показывающую, на сколько сильно проверка индексов массива замедляет работу с ним. Так как Паскаль что-то мудрит с указателями, код написан на C#. В неуправляемом блоке с указателями обработка занимает более чем в 2.2 раза меньше времени.Compile.bat (116 Байты) Test.cs (486 Байты) Test.exe (4 КБ)
Должен сказать, что разработчики CLR ушли гораздо дальше, чем разработчики .NET Framework. Видел данные, согласно которым, правильно написанное приложение на C# по скорости уступает C++ лишь 2-4%.
Ну, это смотря что считать правильным. Вроде можно ещё делать вставки из асемблера или IL, прямо в коде. Тогда точно уступать C++ оно по производительности не будет)))
Но я то имел ввиду, что оно по-честному написано на C#. То есть никакого ассемблера или IL никуда не вставляется.
Скорее всего всё-таки будет. На 0.5%. Ведь CLR компилирует код в процессе выполнения, а на это тратятся ресурсы.
Да, но оно компилирует его 1 раз, при первой попытке выполнить что то из него. То есть по сути производительность тут нужна не на выполнение а на загрузку.
Да, да – а дедушка Ленин на субботнике бревна таскал и позировал, а свой сахар детям раздавал 
Так было написано и нарисовано в советских детских книжках.
По более достоверным источникам у Джугашвили были десятки различных кличек и имен во времена его подпольной политической деятельности, и не важно кто их придумывал (хотя этого мы все равно уже никогда точно не узнаем). А вот именно Сталин закрепилось, думаю, не случайно – уж больно соответствовало его суровому характеру и несгибаемой воле.
Я говорил суммарно. А суммарно это и получается меньше 0.5%.
Парни, да перестаньте вы уже соревноваться в своих фантазиях с С++… 
Он всегда будет быстрее при прочих равных! 
Иногда на 0,5%, иногда на 1000% – просто потому, что этот инструмент в руках квалифицированного и опытного разработчика позволяет делать очень тонкие и высокоэффективные низкоуровневые оптимизации для максимального использования возможностей конкретного железа и ОС. А еще потому, что у него нет издержек от виртуальной среды исполнения (CLR) и управляемой памяти с её малопредсказуемым сборщиком мусора.
Хотя, разумеется, граната в руках обезьяны (c++ в руках г*внокодера) может легко давать и обратный результат…
Всякие вставки на ассемблере – это чудовищный костыль, который будет являться сущим адом для дальнейшей поддержки и сопровождения любого нетривиального проекта. Да даже в маленьком коде вы сами через месяц забудете, что и зачем вы там намутили…
Ну, не всегда. Я вот SharpDX скачал недавно, .Net .dll для DirectX, там везде где надо провести хитрые махинации с памятью - всё по-нативному сделано. Как выделение или копирование памяти.
которым таки постоянно пользуются С++ программисты 
Так это и есть костыли, по определению! Всякие вставки на asm внутри кода на ЯВУ, вызовы нативных низкоуровневых функций из-под управляемого кода и т.п. Так делают вынужденно, поскольку иначе не добиться нужного результата или производительности. Но такой архитектуры следует по возможности избегать!
А пытаться всегда использовать ЯВУ (тем более managed code) не по назначению, расчитывая компенсировать его врожденные слабости и недостатки при решении определенного круга задач с помощью различных костылей – моветон, а часто – просто банальный недостаток знаний и опыта, который пытаются скрыть, утверждая, что это “нормально”, мол, многие так делают…
Программисты на С++ они тоже очень разные бывают Как и сами задачи. И там это гораздо чаще бывает оправдано, когда стоит задача любой ценой выжать максимум производительности из какой-то железки, а родной компилятор при этом нативно не справляется.
Кроме того, С/С++ – изначально языки для системного (низкоуровневого) программирования, поэтому переход на ассемблер в таком коде – не такой резкий провал в уровне абстракции, как в случае, скажем, вставок на asm в Delphi. Но даже для С/С++ все равно это костыль, который усложняет как процесс разработки, так и поддержки!
я уверяю вас, “родной” компилятор справляется прекрасно. Вставки на ASM не для того делаются, чтобы компилятор “переумничать”
Программисты С++ достаточно часто читают/используют ассемблер, поэтому называть такое “костылем”, по меньшей мере, странно
1 лайк
Епт. Когда пишут очередную чушь про “низкоуровневость” С++ - хочется то ли смеяться, то ли плакать. Товарищи, которые ставят С и С++ в одну строку, прошу вас почитать о том, что из себя представляет STL в 2018 году. Пожааааалуйста…
То, что инструмент позволяет писать нечитаемый говнокод, не означает, что иначе писать нельзя. Почему-то как только речь заходит о том, что кто-то пишет в синтаксисе старого Паскаля, его тут дружно закидывают какахами, а когда С++ обсуждается с учитыванием стандарта С++98 - всем это кажется нормальным.
2 лайка
Ну, не всегда же по условиям задачи (требования к стабильности или совместимость с другими сторонними компонентами, напр.) разработчики могут использовать последнюю версию компилятора, эффективно использующую все новые возможности целевого процессора.
Костыль-костылю рознь! Можно и на родном С++ или Паскале накостылить так, что мама не горюй. “Костыль” не в том смысле, что это обязательно будет плохой код или плохое решение, а в том смысле, что по какой-то причине (неважно, реальной или надуманной) приходится использовать сторонний инструмент с другим уровнем абстракции. Это в любом случае сказывается на читабельности кода и, как правило, усложняет его поддержку.
Но при разработке нативного низкоуровнего кода на С++, конечно, это не так заметно. Это как заменить универсальный острый нож и очки на скальпель и микроскоп, по сравнению с тем, как если заменить топор сразу на скальпель (в случае с применением asm в языках прикладного уровня).
Всякая чушь с “надо вручную контролировать память”, “о боже, указатели!” и прочими недомыслами умерла примерно так лет 10 назад. Пишут так, чтобы в коде это мешало его читать/писать только динозавры, застрявшие в 90-х. Предлагаю поглядеть, какие стайлгайды приняты в большинстве современных компаний, ага.
Институт математики, механики и компьютерных наук ЮФУ, 2005–2021