Придумал тему для наброса.
Если в одной фразе то так: "Настоящее программирование подразумевает компиляцию в машинный код".
Программирование это чудо рождения машинного кода из человекочитаемых исходников.
От того, что примерно представляешь механизм компиляции, чудо рождения не перестает быть чудом. Как и в биологии.
Помню, как скомпилировал свой первый экзешник в турбопаскале. Восторг, почувствовал себя творцом.
JVM и dotnet с их промежуточным байткодом — это суррогаты компиляции, хотя в чем-то и удобнее.
Скриптовые языки — это вообще не программирование, а профанация.
Модератор-националист Kerk преследует оппонентов по политическим мотивам.
Здравствуйте, Bill Baklushi, Вы писали:
BB>Помню, как скомпилировал свой первый экзешник в турбопаскале. Восторг, почувствовал себя творцом.
А я почуствовал себя творцом, когда его написал, а не когда скомпилировал. Собственно, акт компиляции моего первого исходника проходил вообще без меня, я туда отдал тексты на бланках, их там набили на перфокарты, пропустили через ЕС ЭВМ, и через несколько дней притащили мне распечатку. Когда по распечатке я увидел, что все сработало, я себя еще больше творцом почуствовал. А всякие там промежуточные этапы, типа компиляции, линковки и т.п., я их всегда считал фактами богатой внутренней жизни ЭВМ
BB>JVM и dotnet с их промежуточным байткодом — это суррогаты компиляции, хотя в чем-то и удобнее. BB>Скриптовые языки — это вообще не программирование, а профанация.
Ну открой для себя, что та система команд, которую ты видешь у современного процессора, это не та система команд, которую он внутри себя на самом деле исполняет. Он перетранслирует на ходу твою программу из внешнего представления (например, "набор команд x86"), в удобное ему внутреннее.
Так что увы, в настоящих кодах тебе вряд ли пописать доведется.
Pzz:
Pzz>Ну открой для себя, что та система команд, которую ты видешь у современного процессора, это не та система команд, которую он внутри себя на самом деле исполняет. Он перетранслирует на ходу твою программу из внешнего представления (например, "набор команд x86"), в удобное ему внутреннее.
Я в курсе. Конечно, тут результат смахивает на те же JVM/.NET. Ну уж какие команды есть...
Что там делается под капотом процессора, это скорее железячничество, а не программизм.
Pzz>Так что увы, в настоящих кодах тебе вряд ли пописать доведется.
Кстати, помимо x86 приходилось программировать и другие процы. В основном они не заморачиваются с промежуточной системой команд, а шпарят как есть.
Модератор-националист Kerk преследует оппонентов по политическим мотивам.
Здравствуйте, Bill Baklushi, Вы писали:
BB>Доброго времени года.
BB>Придумал тему для наброса. BB>Если в одной фразе то так: "Настоящее программирование подразумевает компиляцию в машинный код".
Ты либо одепт? А что что-то напомнило мне "Вступайте и кампелируйте ибо в месте мы сила!".
Здравствуйте, Bill Baklushi, Вы писали:
BB>Придумал тему для наброса.
Хороший наброс. Одобряю
BB>Если в одной фразе то так: "Настоящее программирование подразумевает компиляцию в машинный код". BB>JVM и dotnet с их промежуточным байткодом — это суррогаты компиляции, хотя в чем-то и удобнее.
Это тоже интересные технологии.
BB>Скриптовые языки — это вообще не программирование, а профанация.
+1
Здравствуйте, Pzz, Вы писали:
Pzz>Ну открой для себя, что та система команд, которую ты видешь у современного процессора, это не та система команд, которую он внутри себя на самом деле исполняет.
Именно та самая. То. что там внутри все непросто, оно конечно интересно, но уже на уровне того, как программа и её исполнение в последовательность электрических сигналов превращается. То есть для программиста, даже системного, скорее общая эрудиция в смежной области, а не профессиональные познания.
Здравствуйте, pagid, Вы писали:
P>Именно та самая. То. что там внутри все непросто, оно конечно интересно, но уже на уровне того, как программа и её исполнение в последовательность электрических сигналов превращается. То есть для программиста, даже системного, скорее общая эрудиция в смежной области, а не профессиональные познания.
Некоторые неочевидные вещи про внутреннее мироустройство процессора программисту было бы неплохо понимать, даже и прикладнику. Например тот факт, что скорость памяти при последовательном доступе может быть раз в 10 больше, чем при произвольном.
А меня раздражает засилье компиляторов. По-мне модель пхп идеальна, когда ты пишешь код и он сразу работает. Я не понимаю, почему все так не делают. И JVM тут не выделяется, компиляция Java так же очень долгая. Всё, что нужно для начала выполнения кода это построить AST. Это выполняется за один проход. Всё, дальше можно и нужно начинать выполнение программы. И уже там считать метрики, выполнять более глубокую компиляцию часто выполняющихся методов и так далее, но это всё под капотом.
Это я всё говорю именно про разработку, отладку, юнит-тесты. Перед релизом, конечно, всё нужно компилировать как следует, тут без вопросов.
Здравствуйте, Pzz, Вы писали:
Pzz>Некоторые неочевидные вещи про внутреннее мироустройство процессора программисту было бы неплохо понимать, даже и прикладнику. Например тот факт, что скорость памяти при последовательном доступе может быть раз в 10 больше, чем при произвольном.
Это связано с устройством кэша (кэшей), а не тем, основана ли схемотехника процессора на микропрограммах или нет.
Здравствуйте, pagid, Вы писали:
Pzz>>Некоторые неочевидные вещи про внутреннее мироустройство процессора программисту было бы неплохо понимать, даже и прикладнику. Например тот факт, что скорость памяти при последовательном доступе может быть раз в 10 больше, чем при произвольном. P>Это связано с устройством кэша (кэшей), а не тем, основана ли схемотехника процессора на микропрограммах или нет.
Скорее, это связано с устройством динамической памяти.
Здравствуйте, Pzz, Вы писали:
Pzz>Некоторые неочевидные вещи про внутреннее мироустройство процессора программисту было бы неплохо понимать, даже и прикладнику. Например тот факт, что скорость памяти при последовательном доступе может быть раз в 10 больше, чем при произвольном.
10? Там полсотни, если не тысяча:
— Из L1: ~0.5 нс.
— Чтение с предыдущей позиции в DRAM модуле: задержка около 1 нс.
— Чтение с нового столбца не меняя строку: минимум 12.5 нс на переключение (самая быстрая DDR4).
— Чтение со сменой строки: минимум 37.5 нс на переключение (самая быстрая DDR4).
(Ну-тко, сколько это тактов вашего процессора?)
Перебор кэшей может добавить ещё 5-10 нс (особенно неуспешный и L3).
Здравствуйте, netch80, Вы писали:
N>Перебор кэшей может добавить ещё 5-10 нс (особенно неуспешный и L3).
А потом еще эффекты треша кешей, треша TLB, а там еще пейджфолты, своппинг...
И вообще https://people.freebsd.org/~lstewart/articles/cpumemory.pdf
Здравствуйте, Bill Baklushi, Вы писали:
BB>Если в одной фразе то так: "Настоящее программирование подразумевает компиляцию в машинный код". BB>JVM и dotnet с их промежуточным байткодом — это суррогаты компиляции, хотя в чем-то и удобнее. BB>Скриптовые языки — это вообще не программирование, а профанация.
Что тебе мешает компилировать скриптовые языки и байткод виртуальных машин в машинный код, кроме собственного невежества?
Здравствуйте, rollcoin, Вы писали:
BB>>Если в одной фразе то так: "Настоящее программирование подразумевает компиляцию в машинный код". BB>>JVM и dotnet с их промежуточным байткодом — это суррогаты компиляции, хотя в чем-то и удобнее. BB>>Скриптовые языки — это вообще не программирование, а профанация.
R>Что тебе мешает компилировать скриптовые языки и байткод виртуальных машин в машинный код, кроме собственного невежества?
А вы, значит, обладаете "вежеством", как это делать всегда? Несмотря на потрясающие возможности скриптовых языков заменить всё на ходу и сбить любую ожидаемую оптимизацию? Расскажите, пожалуйста.
Здравствуйте, 3V, Вы писали:
N>>Перебор кэшей может добавить ещё 5-10 нс (особенно неуспешный и L3). 3V>А потом еще эффекты треша кешей, треша TLB, а там еще пейджфолты, своппинг...
Здравствуйте, Bill Baklushi, Вы писали:
BB>Доброго времени года.
BB>Придумал тему для наброса. BB>Если в одной фразе то так: "Настоящее программирование подразумевает компиляцию в машинный код".
Я почувствовал себя творцом, когда слепил из пластилина лошадку. Остальное — так.
А кайф от компиляции... Ну, разве что когда какой-нибудь долбаный фреймворк вдруг собирается какой-нибудь долбаной системой сборки с первого раза, ты некоторое время чувствуешь себя немного счастливым.
Ikemefula:
BB>>Если в одной фразе то так: "Настоящее программирование подразумевает компиляцию в машинный код".
I>Настоящее программирование это сразу в машинных кодах.
В машинных кодах мало программировал, а вот на языке ассемблера приходилось
Недостатки такие:
1. Больше обьем года, сложнее, менее нагляден, менее структурен.
2. На другие архитектуры так просто не перенесешь — переписывай заново.
3. Оптимизация быстро устаревает.
...
Много чего еще.
Язык C задумывался как машинно-независимый структурный ассемблер.
C++, D, Rust в значительной мере это наследуют. Fortran, Pascal/Delphi такими языками не являются, т.к. обладают низкой выразительной силой.
Хороший оптимизатор обычно генерирует хороший машинный код. В сочетании с выразительным языком программирования получается идеальный инструмент. В редких случаях можно посмотреть ассемблерный выхлоп чтобы покрутить настройками оптимизации. В исключительном случае, можно некоторые конструкции переписать на ассемблере.
Модератор-националист Kerk преследует оппонентов по политическим мотивам.
