Болталка PascalABC.NET


#203

Значит, по-Вашему, ПЗУ уже не существует. А ОЗУ? Или теперь все данные хранятся в другом измерении? :face_with_monocle:


#204

Коба он был… А Сталина, насколько я помню, сам себе придумал, как Говард “рокетмена” в “Теории большого взрыва”. Ну и в последующие времена товарищи не осмелились перечить, Кобу забыли…


#205

Почему не существуют? :roll_eyes: Существуют, конечно – как интегрированные компоненты устр-ва, являющиеся неотъемлемой частью его архитектуры и адресного пространства, т.е. без которых оно (устр-во) нормально работать не сможет.


#206

Подготовил демку, показывающую, на сколько сильно проверка индексов массива замедляет работу с ним. Так как Паскаль что-то мудрит с указателями, код написан на C#. В неуправляемом блоке с указателями обработка занимает более чем в 2.2 раза меньше времени.Compile.bat (116 Байты) Test.cs (486 Байты) Test.exe (4 КБ)


#207

Должен сказать, что разработчики CLR ушли гораздо дальше, чем разработчики .NET Framework. Видел данные, согласно которым, правильно написанное приложение на C# по скорости уступает C++ лишь 2-4%.


#208

Ну, это смотря что считать правильным. Вроде можно ещё делать вставки из асемблера или IL, прямо в коде. Тогда точно уступать C++ оно по производительности не будет)))


#209

Но я то имел ввиду, что оно по-честному написано на C#. То есть никакого ассемблера или IL никуда не вставляется.


#210

Скорее всего всё-таки будет. На 0.5%. Ведь CLR компилирует код в процессе выполнения, а на это тратятся ресурсы.


#211

Да, но оно компилирует его 1 раз, при первой попытке выполнить что то из него. То есть по сути производительность тут нужна не на выполнение а на загрузку.


#212

Да, да – а дедушка Ленин на субботнике бревна таскал и позировал, а свой сахар детям раздавал :slight_smile: Так было написано и нарисовано в советских детских книжках.

По более достоверным источникам у Джугашвили были десятки различных кличек и имен во времена его подпольной политической деятельности, и не важно кто их придумывал (хотя этого мы все равно уже никогда точно не узнаем). А вот именно Сталин закрепилось, думаю, не случайно – уж больно соответствовало его суровому характеру и несгибаемой воле.


#213

Я говорил суммарно. А суммарно это и получается меньше 0.5%.


#214

Парни, да перестаньте вы уже соревноваться в своих фантазиях с С++… :biking_man: Он всегда будет быстрее при прочих равных! :motorcycle: Иногда на 0,5%, иногда на 1000% – просто потому, что этот инструмент в руках квалифицированного и опытного разработчика позволяет делать очень тонкие и высокоэффективные низкоуровневые оптимизации для максимального использования возможностей конкретного железа и ОС. А еще потому, что у него нет издержек от виртуальной среды исполнения (CLR) и управляемой памяти с её малопредсказуемым сборщиком мусора.

Хотя, разумеется, граната в руках обезьяны (c++ в руках г*внокодера) может легко давать и обратный результат… :slight_smile:

Всякие вставки на ассемблере – это чудовищный костыль, который будет являться сущим адом для дальнейшей поддержки и сопровождения любого нетривиального проекта. Да даже в маленьком коде вы сами через месяц забудете, что и зачем вы там намутили…


#215

Ну, не всегда. Я вот SharpDX скачал недавно, .Net .dll для DirectX, там везде где надо провести хитрые махинации с памятью - всё по-нативному сделано. Как выделение или копирование памяти.


#216

которым таки постоянно пользуются С++ программисты :wink:


#217

Так это и есть костыли, по определению! Всякие вставки на asm внутри кода на ЯВУ, вызовы нативных низкоуровневых функций из-под управляемого кода и т.п. Так делают вынужденно, поскольку иначе не добиться нужного результата или производительности. Но такой архитектуры следует по возможности избегать!

А пытаться всегда использовать ЯВУ (тем более managed code) не по назначению, расчитывая компенсировать его врожденные слабости и недостатки при решении определенного круга задач с помощью различных костылей – моветон, а часто – просто банальный недостаток знаний и опыта, который пытаются скрыть, утверждая, что это “нормально”, мол, многие так делают…


#218

Программисты на С++ они тоже очень разные бывают :slight_smile: Как и сами задачи. И там это гораздо чаще бывает оправдано, когда стоит задача любой ценой выжать максимум производительности из какой-то железки, а родной компилятор при этом нативно не справляется.

Кроме того, С/С++ – изначально языки для системного (низкоуровневого) программирования, поэтому переход на ассемблер в таком коде – не такой резкий провал в уровне абстракции, как в случае, скажем, вставок на asm в Delphi. Но даже для С/С++ все равно это костыль, который усложняет как процесс разработки, так и поддержки!


#219

я уверяю вас, “родной” компилятор справляется прекрасно. Вставки на ASM не для того делаются, чтобы компилятор “переумничать” :wink:

Программисты С++ достаточно часто читают/используют ассемблер, поэтому называть такое “костылем”, по меньшей мере, странно


#220

Епт. Когда пишут очередную чушь про “низкоуровневость” С++ - хочется то ли смеяться, то ли плакать. Товарищи, которые ставят С и С++ в одну строку, прошу вас почитать о том, что из себя представляет STL в 2018 году. Пожааааалуйста…

То, что инструмент позволяет писать нечитаемый говнокод, не означает, что иначе писать нельзя. Почему-то как только речь заходит о том, что кто-то пишет в синтаксисе старого Паскаля, его тут дружно закидывают какахами, а когда С++ обсуждается с учитыванием стандарта С++98 - всем это кажется нормальным.


#221

Ну, не всегда же по условиям задачи (требования к стабильности или совместимость с другими сторонними компонентами, напр.) разработчики могут использовать последнюю версию компилятора, эффективно использующую все новые возможности целевого процессора.

Костыль-костылю рознь! :slight_smile: Можно и на родном С++ или Паскале накостылить так, что мама не горюй. “Костыль” не в том смысле, что это обязательно будет плохой код или плохое решение, а в том смысле, что по какой-то причине (неважно, реальной или надуманной) приходится использовать сторонний инструмент с другим уровнем абстракции. Это в любом случае сказывается на читабельности кода и, как правило, усложняет его поддержку.

Но при разработке нативного низкоуровнего кода на С++, конечно, это не так заметно. Это как заменить универсальный острый нож и очки на скальпель и микроскоп, по сравнению с тем, как если заменить топор сразу на скальпель (в случае с применением asm в языках прикладного уровня). :slight_smile:


#222

Всякая чушь с “надо вручную контролировать память”, “о боже, указатели!” и прочими недомыслами умерла примерно так лет 10 назад. Пишут так, чтобы в коде это мешало его читать/писать только динозавры, застрявшие в 90-х. Предлагаю поглядеть, какие стайлгайды приняты в большинстве современных компаний, ага.