Pull to refresh

Comments 64

Мораль тут одна, индекс TIOBE измеряет урожай бананов на луне. Будучи знакомым и с другими их продуктами скажу что они специалисты именно в этой области.

Так индекс IEEE в общем и целом никак Tiobe не противоречит. Те же языки находятся на более менее одинаковых позициях.

+«assembly language programming» = 690000 результатов
С тех пор, ассемблер почти всегда находится в топ-10 рейтинга

У меня хорошие новости для Object Pascal:
«delphi programming» = About 710,000 results

P.S. Прошу прощения, он так и фигурирует в рейтинге, просто на последней картинке его вообще нет (на самом деле 14 место), а мне казалось, что он популярней асма. Ну да можно ещё Pascal/Free Pascal/TMT Pascal накинуть тысяч на 400

Вообще-то, Delphi был намного популярнее раньше и напоследок он опять растёт. Мне кажется, что ему мешает только то, что он проприетарный.


Но это вообще мой любимый язык. Хотя, ассемблер всё-таки любимее. ;)

Почему в статье об "ассемблере" говорится так, как будто это действительно один конкретный язык, в то время как это общее название огромного количества языков, сильно отличающихся между собой, в зависимости от того, для какой ISA и для какого компилятора он предназначен (т.е. есть x86 Assembly для FASM,NASM,WASM и т.д., 6502 asm для ACME, cc65 и т.д. и т.д....)?

Принципы одни и те же. Да и синтаксис не такой уж и разный.

Ну, то же самое можно сказать про C/C++ или PHP и Java

А, сколько разных ассемблеров проходит мимо этих рейтингов — типа HLA.
не говоря уже и о том, к примеру, что бывают ассемблеры сделанные на базисе Форт языка.

P.S. Кстати, популярная «забава», среди программистов, писать Forth (Форт) системы на разных языках программирования и часто именно на ассемблере. 😋
На уровне приближения «Принципы одни и те же. Да и синтаксис не такой уж и разный.» — весь топ TIOBE, кроме ассемблера, SQL, и Lisp/Scheme — мог бы идти одним пунктом.
А, как же, ещё к примеру, Forth, Prolog (Пролог)? 😋

P.S. В индексе, возможно, ещё имеет смысл разделять языки по используемым парадигмам программирования.

На «цвет и вкус» Бейсик языки тоже все разные.
Я думал про Forth и Prolog, но в топ они не попали :(
Все не попавшие в Топ Tiobe языки программирования после 100-го перечислены отдельно в алфавитном порядке.
Тоже не понятно, но даже Github его плохо «считает»,
хотя неофициальный Topics по Forth создан.

P.S. Но, что радует, поиск по слову Forth на Github выдаёт много результатов поиска за некоторым исключением присутствия его в устойчивых словосочетаниях.

Спасибо. Интересная статья. Но позвольте спросить:
1) о каком языке ассемблера (ЯА) речь? (Вопрос не только автору, но и Tiobe).
Вики


справедливо отмечает:
Язы́к ассе́мблера (англ. assembly language) — машинно-ориентированный язык программирования низкого уровня. Представляет собой систему обозначений, используемую для представления в удобно читаемой форме программ, записанных в машинном коде. Его команды прямо соответствуют отдельным командам машины или их последовательностям. Является существенно платформо-зависимым: языки ассемблера для различных аппаратных платформ несовместимы, хотя могут быть в целом подобны.
[...].
Также может предоставлять дополнительные возможности облегчения программирования, такие как макрокоманды, выражения, средства обеспечения модульности программ. В связи с этим может рассматриваться как автокод (см. ниже), расширенный конструкциями языков программирования высокого уровня[3][4].

Конечно, и перенс кода на ЯП высокого уровня (ЯПВУ) бывает не простым. Но в случае ЯПВУ различая обычно в расширениях (как Turbo Pascal и Dr Pascal, а сам язык в основе обычно одинаков). Знаю по своему опыту, что ЯА различных машин отлчаются гораздо сильнее, нпр., PDP-11, IBM 360/370, IBM PC AT, Macintosh 68К.


2) Зачем сейчас писать на ЯА? Когда-то это позволяло заметно ускорить программу. Но сейчас современные компиляторы настолько хорошо оптимизируют, что ускорения от ручного кодинга на ЯА не получается. (Конечно, если такое хобби, то понятно. В списке Tiobe и ЯП Brainfuck есть ;)

Одна из причин использования ассемблера, что при создании какого то процессорного ядра — это первый простейший язык иллюстрирующий все различия присущие данной архитектуре на уровне его использования «регистровой» модели.
Когда-то это позволяло заметно ускорить программу. Но сейчас современные компиляторы настолько хорошо оптимизируют, что ускорения от ручного кодинга на ЯА не получается.

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

Вы это пробовали или только читали?

Пробовал неоднократно. Например, еще в эпоху Pentium 4 у меня была задача в области мат. химии: сгенерировать ок. 100 000 000 связных графов с числом вершин не больше 8, где степень вершины не больше 4, записать для каждого по простым правилам СЛАУ — т.е. 8 уравнений и 8 неизвестных и решить эти системы. При этом математически строго доказано, что каждая такая система имеет решение и только одно.


Написал программу на Delphi-7. Она оказалась быстрее библиотек Интела. Попробовал переписать на asm – сколько не пытался было медленнее. Списался с Интелом – мне дали адрес разработчика функций решения СЛАУ. Послал ему исх.коды. Он ответил, что у меня слишком особый случай, а если в ситеме 1000 уравнений, то мой код быстрее не будет.


До того я много работал с ассемблерами на PDP 11 и на ЕС ЭВМ (задачи реального времени), на Маке, на IBM PC.


Дело в том, что это язык, который «официально» как бы и не существует. Почти не издаются книги про ассемблер, а те которые издаются безнадёжно устарели.

Да. В 2004 было издано несколько


интересных книг
  • В.И. Юров, Assembler, 2-е издвние, "Питер"
  • В.И. Юров, Assembler, Практикум, 2-е издвние, "Питер"
  • О.В.Бурдаев и др., Ассемблер в задачах защиты информации, "Кудиц-образ"

Там много советов по ускорению, но на новых машинах они не работают.
Из списка литературы на Вики самая недавняя книга :


Практическое программирование микроконтроллеров Atmel AVR на языке ассемблера… — 2-е. — БХВ-Петербург, 2014. — 368 с. — (Электроника). — ISBN 9785977533119.

В англо-Вики список литературы больше, но, судя по названиям, литература в основном исторического характера. Отсюда следует предположение, что практический интерес падает, а высокий ретинг Tiobe вызван повышением интереса к истории CS.

В современном мире для решения СЛАУ у INTEL есть своя библиотека MKL, которая тоже использует ассемблер. Сравните с ней. Ну а вообще любая оптимизация начинается с профилирования, результаты которого могут оказаться весьма неожиданными, и узким местом может оказаться не сам алгоритм, а, скажем, промахи кэша при работе с памятью (частая ситуация).
То есть программа для перемножения матриц, написанная на Delphi-7 20 лет назад, оказалась быстрее современной, вручную оптимизированной для AVX ассемблерной той же компанией, что и делает эти самые процессоры? В это очень, очень сложно поверить. Ладно, фиг с ним с MKL — в С++ на однотипных операциях можно добиться ускорения в 4 раза без ассемблера, просто интрисиками — но в то время даже слова такого не было. А вот ассемблерными вставками посреди паскалевского кода злоупотребляли многие — хотя бы для того, чтобы стек FPU использовать по полной, чтобы избежать записи/чтения промежуточных значений в память (а этого даже современные компиляторы делать не научились).
Совсем не очевидно, что программа для перемножения целочисленных матриц 8х8, о которых выше речь и шла, — выиграет от AVX и/или ассемблерных вставок.
Конечно выиграет — AVX с целочисленными значениями тоже умеет работать. Там же речь шла об однотипных вычислениях — это значит, что за один проход можно перемножить 4 одних матрицы на 4 других (или даже 8), и размер их тоже значения не имеет.
Написал программу на Delphi-7. Она оказалась быстрее библиотек Интела. Попробовал переписать на asm – сколько не пытался было медленнее.

Извините, но здесь что-то не так.


Компилятор Delphi-7 генерирует не так уж и хороший код в плане производительности. Так что, сделать на ассемблере медленнее Delphi-7 это надо постараться. По крайней мере всегда можно посмотреть что накомпилировал компилятор и продолжит дальше. Нет?

Я так и делал.VTune использовал...

Тогда должно было получится по крайней мере не медленней Delphi. Как вы умудрились сделать тот же самый код медленнее?


Но если говорим вообще, то такой подход неправильный. Нельзя следовать компилятора. Надо писать «по другому», не как на ЯВУ. Потому что, если по сути вручную компилируете код высокого уровня, получите не более чем 10..20% быстрее компилятора.


Оптимальный ассемблерный код часто вообще никак не возможно перевести на ЯВУ. И я сейчас не о производительности.

Согласен, что не всякий ассемблерный код переводим на ЯВУ. В этом смысле ЯА мощнее любого ЯВУ. Но не всякий код оптимален, а в хороших компиляторах ЯВУ применяют обычно наиболее эффективные решения.

Вы уверены в этом?, а как же тогда смысл в рекомендациях к использованию разных профилировщиков кода.

P.S. Даже запуск одной программы в разных поколениях процессоров не даёт такой простой эвристики к пониманию возмржностей по его ускорению. (где то и выравнивание инструкций очень эффективно, а где то не очень)

P.S. Интересно, что в топике Уроки от NeHe на masm64 кто то переписал и уроки NeHe — программирования OpenGL — на ассемблере 64.
Даже запуск одной программы в разных поколениях процессоров не даёт такой простой эвристики к пониманию возмржностей по его ускорению

Я говорил об одном поколении. Стоит отметить возможность промежуточного решения для Delphi-7 — вставка asm кода в код Delphi. Для критических участков это м.б. полезно, а остальные 99 или 90% кода будут на Delphi.

Да. В 2004 было издано несколько интересных книг,… Отсюда следует предположение, что практический интерес падает.
Ещё можно предположить, что вы не учли контекст. В 2004 ещё не было интернета в каждом доме с безлимитным траффиком, а упомянутые вами книги носят справочный характер и не без опечаток (лично находил несколько). В наше время такую литературу проще и надёжнее скачивать с оф. сайта Intel. Были ещё книги в стиле «Желтые страницы Internet», которые сейчас тоже перестали издаваться — но вряд ли из этого следует, что практический интерес к интернету падает.
упомянутые вами книги носят справочный характер и не без опечаток

Первые две книги (Юров) это учебники с надписью на титульном листе "допущено Министерством образования РФ в качестве учебного пособия для вузов..." и еще интересная надпись "издательская программа 300 лучших учебников для высшей школы в честь 300-летия СПб" ;)


Хорошо известно, что в инете много мусора. И даже на Хабре хватает и Вики верить не всегда стоит. Сайт Интела, конечно, хорошо, но там очень легко заблудиться. Одно время (примерно в 2005-10) я туда (в ру-Интел) статьи выкладывал и другие публиковались. Было очень много спорных публикаций. Т.о. учиться только по инету проблематично.


Были ещё книги в стиле «Желтые страницы Internet», которые сейчас тоже перестали издаваться — но вряд ли из этого следует, что практический интерес к интернету падает.

Сейчас издают много других книг по инету.

Зачем сейчас писать на ЯА? Когда-то это позволяло заметно ускорить программу. Но сейчас современные компиляторы настолько хорошо оптимизируют, что ускорения от ручного кодинга на ЯА не получается.
Для сейчас это ничуть не менее актуально. Мой личный рекорд — ускорение в 40 раз, и это по сравнению с с++, а не каким-нибудь там питоном. Просто (внезапно) на ассемблере тоже надо уметь программировать. Современные компиляторы хорошо оптимизируют только те алгоритмы, которые могут распознать — типа сложения массивов и умножения комплексных чисел, а с полноценной автоматической векторизацией там по прежнему всё далеко не идеально. Типичный пример — FFT по степеням двойки ни один компилятор вам не векторизирует.
Дополню на примере быстрого текстового редактора:
EmEditor uses various CPU optimizations such as multithreading and SIMD technology such as AVX-512 and AVX-2 to improve the speed of opening very large files, Find/Replace/Filter, parsing CSV, various Sort, Delete Duplicate Lines, and various other operations.
А как это связано с ассемблером? SIMD отлично можно использовать из C и C++ с помощью интринсиков. Про многопоточность и не говорю. Плагины к EmEditor тоже предлагается писать на C или на C++. Есть ли какая-то информация, что там именно ассемблер используется (я сам не нашёл)?
Там про ассемблер ничего не сказано. Если речь про
Improved the speed by dividing the core program into 3 executable files — ee512.exe for AVX-512, ee256.exe for AVX-2, and ee128.exe for SSE2 instruction sets (64-bit only). EmEditor automatically selects the most optimized executable file by default, or a user can select any executable file as long as the current CPU supports the corresponding instruction set.
то абсолютно ничто не мешает это сделать в C++.
А в C++ при этом интринсики SIMD использовались?
Конечно нет, иначе какой смысл в таком сравнении? Но в моём коде их тоже не было.
Зачем сейчас писать на ЯА? Когда-то это позволяло заметно ускорить программу. Но сейчас современные компиляторы настолько хорошо оптимизируют, что ускорения от ручного кодинга на ЯА не получается. (Конечно, если такое хобби, то понятно. В списке Tiobe и ЯП Brainfuck есть ;)

Помимо оптимизаций есть ещё и куча «специальных» применений. У меня, к примеру, по сути embedded разработка, со своей спецификой. Попробуйте объяснить компилятору хотя бы C, что часть регистров общего назначения должна быть зарезервирована под volatile память с глобальными переменными, в которой я буду смотреть наличие одиночных сбоев. Ещё мне обычно проще написать на ассемблере, чем выяснить, что не так в программе на C (или компиляторе), что она не работает или работает медленно: выяснение всё равно потребует понимания ассемблерного кода.

Ok. "куча «специальных» применений" — особые случаи. И эта "куча" сравнельно небольшая, по сравнению с общей кучей применений ЯП. В статье отмечен факт:


Дело в том, что это язык, который «официально» как бы и не существует. Почти не издаются книги про ассемблер, а те которые издаются безнадёжно устарели. Не пишутся статьи, а когда пишутся, они попадают в раздел «ненормальное программирование» или в лучшем случае в «написание вирусов».

Автор объяснил эту ситуацию


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

Что-то вроде апокрифического языка, который используют часто, но тайно, чтобы не быть обвинёнными в ереси за использование антипаттернов, дурных практик и других языческих методов программирования.

Выше я предложил другое объяснение:
Из списка литературы на Вики самая недавняя книга :


Практическое программирование микроконтроллеров Atmel AVR на языке ассемблера… — 2-е. — БХВ-Петербург, 2014. — 368 с. — (Электроника). — ISBN 9785977533119.

В англо-Вики список литературы больше, но, судя по названиям, литература в основном исторического характера. Отсюда следует предположение, что практический интерес падает, а высокий ретинг Tiobe вызван повышением интереса к истории CS.

Ну-у-у, восьмое место, мне кажется, трудно объяснить только интересом к истории.


И причём здесь Counter-strike???

И причём здесь Counter-strike???

Если это вопрос по сокращению CS, то я про Computer Science.


восьмое место, мне кажется, трудно объяснить только интересом к истории

Тут м.б. чисто денежный интерес. Приведу пример из своей практики. Когда для одной небольшой фирмы в США портировал IDE Dr. Pascal с MS DOS на MacOS, то шеф сказал, что работает отлично под новыми версиями MacOS, но надо чтобы работало и под устаревшими версиями. Я удивился: кто их сейчас использует? Оказалось, что одна фирма подарила одному универу устаревшие машины, которые иначе надо было выбрасывать. И этот универ заказал фирме, для которой я работал, совмнстимость. В универе решили, что вводный курс по кодингу студенты могут делать на старых машинах. Т.о. бывают разные обстоятельства. Не удивлюсь, если какой музей закажет программу на asm PDP 11.

Все это так, но мы говорим о мировых тенденциях. И поэтому всякие частные случаи вряд ли могут так сильно повлиять.


Но зачем ходить далеко, вот 5 постов выше Mike-M написал про EmEditor. Вполне современный софт, в котором используют ассемблер.

ИМХО были бы тенденции — издавлись бы книги.

Вот интересно, а насколько Пролог (Prolog) в тенденциях, но по нему издаются книги и где то и изучается в учебных программах вузов.

Да, это удивительно. Помню, в прошлом веке, побывал на лекции представителя Борланда. Ему задали вопрос: почему ваша фирма отказалась от Пролога? Он обратился к залу (примерно 500 человек): пожалуйста, встаньте те, кто использует Пролог. Встали три человека.
— Ну, вот видите, — сказал лектор.

Это да, но только если язык не табуирован. А если табуирован, то тогда книги издаваться не будут, а информацию будут искать тайно в Интернете. А так как язык по сути очень простой, то можно и так.

А откуда видно, что этот язык табуирован? В предыдущих комментах привели пример ЯП Prolog. Много лет назад Борланд от него отказался по причине низкого спроса — и этот ЯП стал табуирован, но книги и сейчас издают. И не сказал бы, что asm очень простой: то что ЯПВУ делает одним оператором в одну строку на asm записывается в десять и более строк-инструкций.

Может из-за того, что и сами какие то разработчики, например на Си, не считают значимым навык опыта работы с ассемблером и его понимания?
Отсюда и издательства не выпускают книг по нему
и не интересуются потребностями пользователей как то использующих ассемблер и разного сделанного в рамках его развития.

P.S. В этом плане, по незнанию и, вероятно, привитому стереотипному мышлению делаются и выводы об эквивалентности и даже высокоуровневых языков.

Вот, к примеру, есть и С-- язык, но почти никем не используется и не факт, что не обосновано.

Вероятно и Forth (Форт) табуирован. 😋

Табуирован это не то же самое как непопулярен. Пролог и Форт являются непопулярными, но вполне мейнстримовские языки. Так что и книги издаются и т.д. И ничего плохого в этом нет.


А табу, это то, о чем нельзя говорить, потому что неприлично. Оно может быть и вполне популярным, но все равно о нем разговаривать на публике не будут.

Forth (Форт), по критериям поиска Tiobe приведёнными в статье через поисковик google выдаёт мало результатов
и ещё сам поисковик смешивает результат выдачи Fortran и Forth вместе при поиске по Fortran языку (т.е. как то не особо отличает эти языки).

Ну, да. У меня 20000 результатов получаются. Что немного. Мне кажется, что Forth просто изжил своё время. Было время, он и был очень перспективным – примерно в 1980-ых. Я писал компилятор для Forth примерно в 1986-ом, на Apple II. И баловался graforth-ом в котором была настоящая 3D графика. ;)


Но дело в том, что преимущества Forth на современных процессорах далеко не очевидны. Вот если бы создали Forth ориентированные процессоры, тогда было бы по другому. А так, Forth ничем не лучше других языков.

А так, Forth ничем не лучше других языков.

А, как сравнивать?
Форт имеет некоторое количество «магии» позволяющей находить ему своё применение и в текущих реалиях «IT».

P.S. «Форт» процессоры есть, но их не делают для масс потребителя (к примеру RTX2010, K1894, 1881ВЕ2T), что не является помехой для его использования в рамках существующего «инородного» железа. 😋
Хотя для FPGA делают «Форт» ядра и есть, к примеру GA144 MISC контроллер с 144 асинхронными ядрами соединёнными в матрицу.
Был и у Atmel в портфеле 4-ёх битный MISC контроллер Marc4.

Если есть интерес, то могу привести ещё какое то количество «отсылок». 😋
Ну, да. У меня 20000 результатов получаются. Что немного.

Вероятно это связано ещё и с тем, что к примеру, Google поисковик может не соотносит разные диалекты Forth (Форт) языка в результирующюю выборку поискового запроса.

Например в сервисе поиска картинок попробовал ввести +«pForth programming»… kForth… Win32Forth… SPForth… то он указал, что показаны результаты поиска по слову Forth присутствующему в запросе, вероятно посчитав его вариации набранного слова ошибкой ввода и дополнительным указанием, что всё же показывать результаты именно по введённому запросу.

а такое наименование разных «диалектов» Forth достаточно обычное явление.

т.е. метрики поиска Tiobe по Forth «не срабатывают» т.к. не учитывают и такие вариации диалектов Forth языка в его именовании.

поэтому по результатам выдачи поисковиков Forth сложно соотнести с майнстрим языками.
выяснить, что не так в программе на C (или компиляторе), что она не работает или работает медленно: выяснение всё равно потребует понимания ассемблерного кода.

Вот это важный момент, который статья обходит: мало кому приходится писать на ассемблере, но многим приходится читать дизассемблированный код при отладке.
Делая статистические исследования надо очень внимательно проверять что именно вы измеряете и какой физический смысл тех чисел, которые вы получаете на выходе своих программ.

Осталось понять, какой физический смысл у суммы популярностей ассемблеров PDP-11, x86, MIPS и Hexagon. По-моему, области применимости этих ассемблеров не пересекаются.
А, не рассматривали ли Вы вариант фан программирования на ассемблере для компьютера Gigatron TTL?

По нему была и одна опубликована статья пару лет назад на Habr
Гигатрон — самодельный микрокомпьютер без процессора

Ассемблер (система команд процессора) в нём настолько минималистична, что даже разработчики посчитали необходимым сделать более высокоуровневый язык ассемблерa GCL на этой архитектуре для «абстрактного» vCPU

P.S. Здесь есть сводная табличка по группам команд процессора (команда — 1 байт + считывание вместе с ней ещё одного байта — из ПЗУ шины D в терминологии поцессора, oper в этой таблице)
У процессора ещё две 8-ми битных шины: IN, OUT
кроме внутренних регистров A — аккумулятор, и X и Y могущих образовывать пару,
но в адресации её автоинкремента изменяется только регистр X.

так как процессор сделан на логических микросхемах, то есть возможность даже напрямую вывести, к примеру, сигналы аккумуляторного регистра на светодиоды
(как впрочем и других компонентов процессора) и использовать как дополнительную возможность по управлению чем то и смотреть по шагам управление по программе нажатием кнопки при её отладке)

как впрочем и других компонентов процессора и шагать по программе по нажатию кнопки.

Здесь в проекте процессора процессора Gigatron на Verilog есть emulator под Linux
Здесь под Windows в этой теме с форума Gigatrona другой эмулятор

Интересно, что в конечной таблице есть R, но нету Go. Вероятно потому, что по "go programming" находится всякая хрень, а называть его "golang" не все догадываются))

А ещё, например "react programming" должно включаться в "js programming" и в сумме уделать всех, но... Считается урожай бананов на Луне, в первом комментарии очень верно сказали))

Есть там Go. Просто я обрезал таблицу, чтобы не занимала слишком много места по вертикали. А так, в декабре, Go был на 14-ом месте, а сейчас в январе на 13-ом.

Phix, Wren, Julia, Raku – А, ну да, ну да.

Sign up to leave a comment.

Articles