Это сисколы реализуются на асме. Правильнее сказать, ядро ОС

Суть была сравнения техники скорости выполнения print() интерпретатора Python, и ассемблерных сисколлов

Ладно, вот Си-компилятор (GCC), с его printf()
Скомпилирован O3
Результат тот же - 30 милисекунд отстаёт интерпретатор Python

Даже странно, почему отстаёт

Странно, что тут странного. Интерпретатор работает с исходным кодом, парсит, обрабатывает на ходу

Написал же с самого начала, что мне нужны были цифры, я их не нашёл. Посмотрел  сам примерную цифру, и поделился с чатом.
Я знаю, что Python не используется для быстрых программ, и ассемблер с ним ставить - глупо

Там с питоном не всё так однозначно.

Что именно?

Это долгий разговор. Я вспоминаю свою беседу с одним питоновым спецом. Он мне рассказывал, что сейчас питон очень оптимизироаан.

Я с такими тоже очень часто разговаривал))

Самое важное тут понять - оптимизирован лучше относительно чего (каких языков программирования, каких компиляторов)?

Идея сводилась к тому, что если на си попробовать написать то, что делает питон, когда он, скажем, обращается к сложным библиотекам, то сишный код будет выполняться быстрее питонового, но не настолько, чтобы уж очень.

Но я не готов продолжать аргументацию, поскольку сам не занимался этим вопросом.

30 м\с для алгоритма выше я не считаю "уж очень"
Вроде всё нормально, так и должно быть.

Для библиотек я вот уже в свободное время сам посмотрю, самому интересно. И с GUI тоже надо будет проверить. Как будет Python там работать

Я ставлю акцент на том, что применение питона и асма настолько разное, что сравнивать решения на двух языках вряд ли разумно.

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

Поэтому, фактически, в случае оконного интерфейса уже без разницы на питоне ты выводишь или на си.

Я знаю, я согласен.
Нужно было начинать с GCC, может быть.
Но я ещё раз уточняю, что мне важно было понять конкретно скорость выполнения print() интерпретатора Python. Но сейчас я уже понял, что я получил разницу в скорости, равную компиляции. Т.е я сравнил Сишный скомпилированный printf()  с, фактически, компилятором, вот и поэтому написал (точнее идею мне подкинул Дмитро), что нужно будет попробовать с библиотеками. Может там уже будут равные условия

Для меня идеал программирования на асме задавали компьютерные игры времён z80, когда после перезагрузки память компа была чиста, и просто начинал работать код игры без каких-либо системных вызовов. Без ОС, все обработчики прерываний писали программисты игры, всё что-то куда-то засовывалось в буферы, порты опрашивались. Короче, хардкор!

А потом что-то пошло не так..

Не что-то, а кто-то
Тот, кто пошёл дальше (создаёт новую технологию), тот и нарушает "старые времена", но рождает новые. Потом будет "Эх! Помню, как на Python писал, вот времена были"
Ну или любая такая альтернатива с x86 или x86_64, и ассемблером))

Вот тут кто то спрашивал про дизасемблеры, нашел очень интересную и бесплатную штуку, поддерживает 32 бит