Джефф Мэррисон (Jeff Marrison), автор реализованной на ассемблере x86_64 свободной (GPLv3) библиотеки HeavyThing, опубликовал видео под названием «Зачем писать на ассемблере?». В видео приводятся результаты тестирования при помощи утилит perf и strace простейшего приложения (вывод 'hello'), написанного на 13 языках программирования...Подробнее: https://www.opennet.me/opennews/art.shtml?num=51992
А теперь пусть напишет на асемблере бизнес логику
А причем здесь "бизнес логика"?
Многие вещи в линукс реализованы на python, например - это в 144 более затратно, чем на C.
А потом возникают удивленные возгласы типа - "как это легковесный дистрибутив требует Х Ггц проц и YГб ОЗУ?"
> реализованы на pythonТак не требуют производительности же. Ну например dnf.
> не требуют производительности же. Ну например dnf.Это так теперь принято оправдывать тормознутость dnf, которому даже использование libsolv не помогло далеко уйти в этом плане от yum?
> Это так теперь принято оправдывать тормознутость dnf, которому даже использование libsolv не помогло далеко уйти в этом плане от yum?А что именно там тормозит не подскажете? Где узкое место?
apt, apt-get, aptitude, dpkg тормозят ещё больше, кстати. Потому, что давайте информацию о пакетах положим файлами на ФС! А потом будем вычитывать эти файлы в память! Больше чтений диска, это же быстро происходит! sqlite не нужен, это сложно!
sqlite это шаг к реестру винды, no way
> sqlite это шаг к реестру винды, no wayТо есть вы настаиваете на том, что идейность важнее здравого смысла?
Кстати, где вы реестр нашли? Хм. Похоже, идейность уже заменила вам здравый смысл.
Где ты нашёл здравый смысл? sqlite тормозит сильнее, чем xapian.
> Где ты нашёл здравый смысл? sqlite тормозит сильнее, чем xapian.А чтобы поиск не тормозил, мы в дополнение к базе пакетов на диске добавим xapian! Это же так здорово, когда для выполнения одной и той же задачи используются сразу 2 вещи одновременно! И работающий всё время сервис -- это же так круто! Ведь пользователь занимается поиском пакетов всё свободное время!
> И работающий всё время сервис -- это же так круто!Xapian — библиотека, а не сервис. Вас, видимо, очень больно покусали фанатики Elasticsearch.
Более того - xapian-index (если это про него) некая весьма опциональная штука. Он реально не нужен ни apt(-get) ни dpkg ни даже synaptic'у. Либа конечно есть но она не кусается.А так - у редхата тоже XMLки кешируются в скулайт, при том после того как они стали выгружать скулайт - XMLки никуда не делись и майнтайнеры все-равно имеют дело с этой монстрятиной. У дебиана в этом плане проще, это простые текстовики, которые можно парсить и без огромных мегабиблиотек. В отличие от XML.
> sqlite это шаг к реестру винды, no wayЯ вам реестров принёс: http://mirror.centos.org/centos-7/7/os/x86_64/repodata/
> sqlite это шаг к реестру винды, no wayКакое просто позорное незнание! Раз уж сами речь о реестре завели.
- Реестр для того и придуман, причём ещё во времена ПК уровня 486 100Mhz/ip1-50Mhz - чтобы компатно хранить, удобно централизованно искать текстовым поиском и усткорять доступ, притом не забывая про WINAPI установщиками и автоматичноть периодического авто-backup позже добавенного на случаи непредвиденных перезагрузок.
Да, он в виндах реализован мог бы быть и ещё быстрей и удобней, но тем не менее.
И систменые требования тех ОС я привёл - вовсе не случайно, соответвенно.
Позор Торвальдсу и BSD-гомосятинам - что до сих пор ниасилил(и) [понять таких элементарных вещей].А, sqlite тот ещё несравнимый тормоз, особенно если извратить формат БД,
но скорей как из-за его скриптовости-для-кухарок, так и потому что там значительный переизбыток функциональности и универсальности ненужной в ОС реестре.
Админы локалхоста не понимают что файловая система - это же база данных, только иерархическая?
> Админы локалхоста не понимают что файловая система - это же база данных, только иерархическая?Админы нелокалхоста не слышали об ACID? o_O
Или же для них реализовать трансакцию/atomic commit на любой ФС - "как два пальца"?
О том что ACID не нужен вам лучше других расскажет очередной адепт NoSQL
> "как два пальца"?Два, не два... с базами данных подстава в том что это реально работает у энтерпрайзныx DBA. А когда у меня oom killer выносит к чертям редхатовский пакетный менеджер - так он потом ошметки от своей чудной базы собрать уже не может. И система потом вообще ничего поставить и снести не может. Упс.
> Админы локалхоста не понимают что файловая система - это же база данных, только иерархическая?Произвольный доступ к диску уже приблизился по скорости к последовательному? Индексы на ФС уже завезли?
> Произвольный доступ к диску уже приблизился по скорости к последовательному?Да, уже лет много как придумали SSD.
> Индексы на ФС уже завезли?
Apt использует xapian для индексов.
>> Произвольный доступ к диску уже приблизился по скорости к последовательному?
> Да, уже лет много как придумали SSD.Как говорил Чапаев, есть один нюанс. С диска считывается всё равно не менее сектора. Сколько секторов необходимо вычитать для поиска данных по ФС (а вычитывать необходимо также метаданные), сколько раз происходит переключение контекста ядро-юзерспейс при чтении метаданных. Наконец, сколько будет создаваться резервная копия такого дерева и сколько будет копироваться 1 файл на десяток мегабайт?
>> Индексы на ФС уже завезли?
> Apt использует xapian для индексов.Так индексы то на ФС завезли? И наличие 2 разных сущностей, выполняющих одну и ту же задачу -- разве не грубое нарушение DRY?
> С диска считывается всё равно не менее сектора. Сколько секторов необходимо вычитать для поиска данных по ФС (а вычитывать необходимо также метаданные), сколько раз происходит переключение контекста ядро-юзерспейс при чтении метаданных. Наконец, сколько будет создаваться резервная копия такого дерева и сколько будет копироваться 1 файл на десяток мегабайт?Так пишешь, будто sqlite не на той же файловой системе валяется.
> Так индексы то на ФС завезли? И наличие 2 разных сущностей, выполняющих одну и ту же задачу -- разве не грубое нарушение DRY?
Хранение данных и их индексирование — это две разные задачи. С DRY всё в порядке.
> Так пишешь, будто sqlite не на той же файловой системе валяется.Происходит ли поиск файла при каждом обращении к уже открытому файлу?
Подсказка -- что такое дескриптор? К какому числу файлов необходимо обратиться в случае работы ы sqlite и в случае работы с деревом на ФС?> Хранение данных и их индексирование — это две разные задачи. С DRY всё в порядке.
То есть вы на полном серьёзе предлагаете отдельно держать дерево файлов с информацией о пакетах (имеющее структуру! Реляционную! Пакеты явно ссылаются друг на друга! Набор полей константный!) и отдельно держать также индекс? Больше файлов богу файлов? Ведь обращения к множеству файлов у нас быстро происходят, да?
Поиск имени в каталоге давным давно идёт по индексу
> apt, apt-get, aptitude, dpkg тормозят ещё большеЛПиП
Показывай time на аналогичных командах.
Нет смысла сравнивать dnf и apt. У них возможности разные, кстати, некоторые из которых, замедляет его, но и предоставляют дополнительные плюшки, которые отсутствуют во всей плеяде apt-*
Ага, в apt отсутствует возможность убить свою базу в хлам по oom на тощей виртуалке. И если что не так идет - чинится с полоборота. В отличие от редхатского шалтайболтая где без пары саппортов RH вообще нечего ловить.
>> Это так теперь принято оправдывать тормознутость dnf, которому даже использование libsolv не помогло далеко уйти в этом плане от yum?
> А что именно там тормозит не подскажете? Где узкое место?Про эти не скажу, а вот в ROSA Fresh тормозил rpm5 из-за беспорядочно вызываемого fdatasync(). Процессорные ядра почти свободны, а система стоит колом, пользоваться невозможно, пришлось исправлять. Забавно, что сами разработчики не замечали (на виртуалке не проявляется).
> (на виртуалке не проявляется).Это на виртуалке по другому проявляется: после внезапного слета питания или ребута такая виртуалка часто отправляется в утиль - она не синхронизировала записи на диск и при внеплановом шатдауне теряется много данных. Порой достаточно чтобы серьезно развалить ФС. Собственно поэтому пакетные менеджеры так и не делают.
...но есть чудные хаки с LD_PRELOAD для самых храбрых, подгрузив либу игнорящую fsync/fdatasync и ко - скорость взлетит до небес. Правда, при внеплановом ребуте в этот момент систему может постичь та же участь что и виртуалку. Убитую виртуалку чинить проще - думаете, чего все разработчики на них это делают? По той же причине они и синхронизацию отключили. Умрет - новую из шаблона сделают.
Вы переносите на rpm5 ту логику, которая реализована в других пакетных менеджерах, в частности в rpm4. В ROSA Fresh вызовы fdatasync() происходили без меры, обновление размером 1Гб устанавливалось 3 (ТРИ часа) на SSD RAID0.Сравните результаты независимого тестирования:
Ребилд базы данных RPM: rpm --rebuilddb - Mageia=5 сек - ROSA=4 мин. 45 сек
Поиск "правых" зависимостей пакета: urpmq --whatrequires libgcc1 - Mageia=7 сек - ROSA=1 мин. 48 сек.
Поиск "правых" зависимостей пакета: urpmq --whatrequires glibc - Mageia=7 сек - ROSA=5 мин.32 сек.https://forum.rosalinux.ru/viewtopic.php?f=56&t=8427&hilit=r...
Как оно сделано в rpm5 теперь никто не знает. Автор проект забросил, а исключительные инженеры тупо скопировали макрос-костыль, приводящий к регрессии в urpmi, на чём и успокоились.
Примечательно, что без отключения fdatasync() БД всё одно падает, что объясняется "магическими причинами:Иногда, в силу каких-то магических причин база RPM падает. Ничего не установить, не обновиться, не удалить. Обычно признаки падения базы RPM примерно такие:
http://wiki.rosalab.ru/ru/index.php/%D0%95%D1...
> меры, обновление размером 1Гб устанавливалось 3 (ТРИ часа) на SSD RAID0.Само по себе такое возможно и в нормальном виде - если там тысячи файлов. А кто сказал что SSD быстро полностью скидывают буфера на запись? Циферки в бенчах эти господа указывают без сброса буферов после каждой команды. Более того - SSD явно желают чтобы их информировали о намерении снять питание и все такое - и логгят если вы это не сделали. И с таким логом хрен чего предъявите производителю за потерю данных, покажут 5-й шрифт в доках и пробурчат "сами виноваты".
Еще кстати стоимость разных позиксных вызовов у разных ФС довольно разная. Возможно у разработчика конфигурация была другой.
> Ребилд базы данных RPM: rpm --rebuilddb - Mageia=5 сек - ROSA=4 мин. 45 сек
...
> тупо скопировали макрос-костыль, приводящий к регрессии в urpmi, на чём и успокоились.А, ну вот и объяснение факапища. Единственное чего я не понял - чего можно с fdatasync делать при поиске?!
>> меры, обновление размером 1Гб устанавливалось 3 (ТРИ часа) на SSD RAID0.
> Само по себе такое возможно и в нормальном виде - если там
> тысячи файлов. А кто сказал что SSD быстро полностью скидывают буфера
> на запись? Циферки в бенчах эти господа указывают без сброса буферов
> после каждой команды. Более того - SSD явно желают чтобы их
> информировали о намерении снять питание и все такое - и логгят
> если вы это не сделали. И с таким логом хрен чего
> предъявите производителю за потерю данных, покажут 5-й шрифт в доках и
> пробурчат "сами виноваты".Это понятно. Другой дело, что на том же железе, на той же ФС, за то же время устанавливались те же пакеты в Gentoo, собираясь из исходников.
> Еще кстати стоимость разных позиксных вызовов у разных ФС довольно разная.
Так точно. Устанавливал эту ROSA Fresh на ZFS, где синхронизация отключается в свойствах тома https://github.com/zfsonlinux/zfs/blob/zfs-0.8-release/man/m...
потому проблему не видел до смены ФС.> Возможно
> у разработчика конфигурация была другой.У директора в то время вообще была MacOS. Разработчики (коих тогда было трое, включая "QA") признали проблему, как видно по ссылке на форум и из анонса R11 https://www.opennet.me/opennews/art.shtml?num=50325 (здесь, кстати, исправили оригинальное fsync() на корректное fdatasync() -- то есть составитель "инженер" РОСА откровенно плавает в вопросе).
>> Ребилд базы данных RPM: rpm --rebuilddb - Mageia=5 сек - ROSA=4 мин. 45 сек
> ...
>> тупо скопировали макрос-костыль, приводящий к регрессии в urpmi, на чём и успокоились.
> А, ну вот и объяснение факапища. Единственное чего я не понял -
> чего можно с fdatasync делать при поиске?!Перестраивать индексы БД для ускорения повторного поиска. При чём делать это каждый раз (с чем и следовало разбираться, а безусловное отключение fdatasync и не является решением, лишь заметает грязь под ковёр).
Установка обновлений винды тут вообще вне конкуренции прилетела маленькая заплатка а такое ощущение что полсистемы переустанвливается.
И в чем хоть проявляется тормознутость apt? Установка той же 1С на винде занимет гораздо больше времени чем установка пакетов в Ubuntu. Можно ещё быстрее? Ну возможно.
Специалисты опеннета считают миллисекунды. Их жизнь полна и насыщена. Они не могут позволить, чтобы какой-то пакетный менеджер потратил на 0.2 секунды больше!
Какие миллисекунды? dnf — самый медленный пакетный менеджер из менеджеров в популярных дистрибутивах. Каждый раз его запускаешь и ждешь, пока он пропердится, пока всё прогрузит.
Fedora с 30 до 31 обновляется на SSD примерно полтора часа чистого времени (без учета скачивания пакетов).
> Они не могут позволить, чтобы какой-то пакетный менеджер потратил на 0.2 секунды больше!Когда у меня сдохла база пакетов по OOM в редхате - приключений было никак не на 2 секунды. Это в дебиане пакетный менеджер не дохнет фатально, даже при OOM, а если что не так - подскажет как починить. А в редхате вместо пакетного менеджера - индусский энтерпрайзный код.
Можно использовать microdnf, который python-free:
https://github.com/rpm-software-management/microdnfЭто позволит Вам сэкономить несколько миллисекунд для Вашей личной жизни.
> Можно использовать microdnf, который python-free:
> https://github.com/rpm-software-management/microdnf
> Это позволит Вам сэкономить несколько миллисекунд для Вашей личной жизни.Спасибо, на меня просмотр работы обновления dnf очень положительно влияет. Прихожу домой с работы, sudo dnf upgrade и сижу зачем-то смотрю, как он работает
Не факт, что в этом виноват именно dnf, а не скорость Вашего интернет-соединения или ширина канала зеркала откуда обновляетесь.
Ещё не факт, что у Вас не установлено кучу пакетов, о назначении которых Вы даже не догадываетесь.Есть возможность выкачивать только дельты пакетов:
https://stackoverflow.com/questions/30553951/how-to-enable-d...
Я так понимаю, тот единственный (на данный момент) человек, который плюсанул этот коммент - это тот единственный человек, который считает нормой необходимость устанавливать отдельный пакет и править конфиги, чтобы получить функционалность, которая должна быть из коробки и включена по дефолту (а она отсутствует, потому что "they have problems with certain things").
Ждём пруфы, которые докажут, что проблема именно в dnf и libsolv, а не во всем выше перечисленном или в прослойке между компьютером и креслом.И конфигурацию железа, пожалуйста, добавьте.
> Ждём пруфы, которые докажут, что проблема именно в dnf и libsolvПроблема точно не в libsolv, ибо zypper летает.
> Можно использовать microdnf, который python-free:Выковыривать за редхатом непотребное - зачем? Можно просто дебиан взять. Там пакетный менеджер изначально нормально сделан. Они почему-то смогли.
Его усиленно на Си переписывают
Уже i++'й год переписывают, а все-равно куча пихона жрущая RAM оптом. И просто адское месиво вместо пакетного менеджера, говоря начистоту. Хороший пример как не надо делать пакетные менеджеры. По сравнению с этим позором даже менеджер какой-нибудь FreeBSD - шедевр.
> Так не требуют производительности же. Ну например dnf.А в результате дебиан ворочается на vm с 128 мегами памяти, тогда как DNF дохнет и на 512. С вонью и брызгами - база после выноса OOM убита в хлам. Как ее восстанавливать - ктулху его знает. В общем отвратительный пакетный менеджер. По сравнению с тем что в debian, например.
>например - это в 144 более затратно, чем на C.Питон - язык-связка. Все критичные к производительности части можно либо вынести в нативный код, либо вообще запускать поверх виртуальной машины с jit-компиляцией.
Язык-связка - это bash:c его помощью можно связать несвязанные между собой по функционалу утилиты доступные в *nix.А в python большинство этого функционала доступно из коробки в виде стандартной библиотеки, например.
Ну так запускай, кто тебе мешает-то? Что надо тебе так критично - перепиши. Человек написал на питоне - значит ему было так удобно и с руки. Пользоваться никто не заставляет, это опенсорс. Открыл редактор и гого.
Не туда ответил, ну ладно.
Только он write only с максимальным ганфутингом. Уж лучше пыхтон, чем такая связка.
Write-only - это скорее Perl, в котором, по словам его создателя, можно одну и ту же задачу выполнить несколькими способами.Это значит, что читать такой код будет нелегко.
Perl write only только у тех, кто специально или от непрофессионализма пишет write only код.
> по словам его создателя, можно одну и ту же задачу выполнить несколькими способамиТак в любом языке
Уж лучше сразу на плюсах писать чем на динамически типизированном мусоре
Ну зачем сразу из крайности в крайность?
> Ну зачем сразу из крайности в крайность?Не, ну можно и как парни из dropbox - переписать с ноля, три раза. Или как Брэйн Кохем, вынужденный в конце концов купить комндочку плюсовиков, чтобы не потерять контроль над разработкой протокола. А просто потому что когда 300 кил прожка на винапи адово втыкает адовому питоноскрипту и по фичам и по скорости - ну вы поняли кому этот кусок питона будет нужен.
> Или как Брэйн Кохем, вынужденный в конце концов купить
> комндочку плюсовиков, чтобы не потерять контроль над разработкой протокола. А просто
> потому что когда 300 кил прожка на винапи адово втыкает адовому
> питоноскрипту и по фичам и по скорости - ну вы поняли кому этот кусок питона будет нужен.Правда, опять наш скромный анонимный аналитик стыдливо умалчивает незначительный фактик появления первой плюсовой реализация только годика через 4 после выхода питонячьей.
Но! Как знают все-все-все стоящие аналитики опеннета: дело там было совсем уже почти все еще наверняка не в окончательном доказательстве практической эффективности протокола (там придумывать-то было - раз два и готово! Ну, наверняка так, раз уж даже питонисты с этим справились! Вон, Napster и eDonkey сразу писались на правильных сишках или плюсах и отличались завидной эффек … ой)!
Как и не в обкатке, доводке и шлифовке протокола на питоньем прототипе - чего там доводить-то, оно ж само все ясно, стоит только чуть напрячь мозги!
А все дело в том, что у спецов просто руки не доходили - ну там напстер и осла на правильныя ЯП писать надо было. А не то бы они бы питонистам бы как показали! Ух!
> Питон - язык-связка.И пишут на нем сказочные... ну в общем синоним слова "раздолбай".
> вынести в нативный код, либо вообще запускать поверх виртуальной машины с jit-компиляцией.
А еще упаси меня пользоваться критичным системным софтом от таких разработчиков, яву им в пакетный менеджер.
Мне кажется необъективным тест для python2 - забыли выполнить команду
$ python2 -m compileall ./hello.py
О, модераторы снизошли и вернули ветку на место. Я удивлён тем, сколько плюсов собрал этот коммент, ведь он абсолютно не имеет значения. Это какой-то злой пук без аргументов. И что это значит? Что бОльшая часть опеннета - это люди без личной жизни, которым лишь бы противопоставить что-нибудь кому-нибудь и не важно что это будет значить? В любом случае, у меня сложилось супер отрицательное мнение о аудитории этого сайта, комменты не буду больше ни читать не писать, и вообще добавлю их в фильтр адблока. Аноны, вы казались мне рациональными
> Многие вещи в линукс реализованы на python, например - это в 144
> более затратно, чем на C.Все эти вещи к Linux (который вообще ядро) не имеют особого отношения. Можно юзать Linux вообще без всяких питонов. Питон затратен не только по системным вызовам - он еще и интерпретируемый к тому же. Это сразу его выносит в совсем другую лигу по скорости.
Для бизнес-логики 60 лет назад придумали КОБОЛ. А то, что _ты_ называешь бизнес-логикой, это паразитирование на обществе.
весь трюк в том что хитрый ассемблер протащил свой рантайм в фирмварь железки и этот рантайм уже запущен на момент старта теста в то время как всем остальным его придётся сначала запустить..
> то время как всем остальным его придётся сначала запустить..Cortex-M можно и чистой сишечкой раскочегарить. Но есть нюансы - потом сишечка будет не совсем чистым и вы таки позовете intrinsics/asm()/... - а си внезапно не умеет сам по себе прерывания например запрещать/разрешать, как и вообще доступаться к регистрам которые не mem-mapped.
> А теперь пусть напишет на асемблере бизнес логикуНу, блин, не всем же бизнес-логика нужна. Вот зачем мне твоя бизнес логика например? Спекулянтам ее втюхивай, пока их не раскулачили.
Почему нет lua¿
Потому что у lua слишком много версий и трансляторов и весь этот зоопарк вроде как кем-то поддерживаются. А ещё это в первую очередь, имхо, встроенный скриптовый язык, а уже потом что-то самостоятельное.
У луа все три версии, прям как у пихона, если у последнего не больше
У Lua есть официальный стендэлон.
перевёрнутые знаки в начале ставятся.
Free Pascal 3: syscalls: 12 taskclock: 0,20 instructions: 120939
/usr/bin/echo: syscalls: 33 taskclock: 0,96 instructions: 785291
Lua 5.3 JIT: syscalls: 77 taskclock: 1,81 instructions: 1900679
Lua 5.3: syscalls: 104 taskclock: 2,97 instructions: 2757088
Bash: syscalls: 178 taskclock: 2,70 instructions: 3045210
Perl 5.26: syscalls: 212 taskclock: 3,78 instructions: 3567224
TCL 8.6: syscalls: 246 taskclock: 6,39 instructions: 8794403
Python 2.7: syscalls: 766 taskclock: 23,54 instructions: 28200486
Ruby 2.5: syscalls: 1915 taskclock: 129,62 instructions: 224858707
Python 3.6: syscalls: 2392 taskclock: 321,96 instructions: 423332563
Ну вот теперь я доволен :) лучше любого скриптового языка, даже баш обошел, хотя он еще тот тормоз. Обычный sh/csh бы еще.
Это надо было отдельной веткой комментариев пустить
Это откуда циферки?
запустил скрипт Джеффа, ссылка в статье
для третьего питона неверные результаты, так точнее плюс csh:Python 3.6: syscalls: 760 taskclock: 65,81 instructions: 83990520
csh 20110502: syscalls: 2250 taskclock: 6,79 instructions: 7491956
Может, никто не написал? Напишите и доложите.
Технически, это камень в сторону компиляторов.
> Технически, это камень в сторону компиляторов.Или рантаймов/библиотек.
И снова нет Pascal.
Да, недоработочка.
fpc-3.0.0: syscalls - 12... Вот так вот.
Думаю мы раскрыли заговор Паскаль топят за то что он слишком быстрый. И это мешает производителям железа продавать новое железо.
паскаль никогда не был тормозом. проблема его в том что синтаксис слишком замудренный, долго писать, тяжело читать исходники.
> паскаль никогда не был тормозом. проблема его в том что синтаксис слишком
> замудренный, долго писать, тяжело читать исходники.Пришлось мне когда-то делать проектик на Pascal, который на практике я не использовал. Реализовал всё в срок, сначала написал и отладил на плюсах, потом день читал PDF от Free Pascal и день переводил исходник. Непривычно, не более. Считаю, что язык был закопан исключительно по политическим мотивам.
> Считаю, что язык был закопан исключительно по политическим мотивам.Скорее — по быдлокодерским. В отрочестве будущих обезьян часто обучают Паскалю, из-за чего они его начинают люто ненавидеть. Это иррациональное, на уровне условного рефлекса. При такой ненависти к Паскалю _эти же_ люди роняют сопли вожделения в адрес жлобоскрипта и пихтона. Лечить только биореактором.
Вот этих упомянутых умело сыграли политики. Как раз в такую среду легко заходит аргумент "профессор не шарит!", с которым они прыгали.
> Вот этих упомянутых умело сыграли политики. Как раз в такую среду легко
> заходит аргумент "профессор не шарит!", с которым они прыгали.На Лурке про это есть:
lurkmore.to/Pascal#.D0.93.D0.BB.D1.83.D0.B1.D0.B8.D0.BD.D0.BD.D1.8B.D0.B5_.D0.BF.D1.80.D0.B8.D1.87.D0.B8.D0.BD.D1.8B_.D0.BD.D0.B5.D0.BD.D0.B0.D0.B2.D0.B8.D1.81.D1.82.D0.B8_.D0.BA_Delphi.2FPascal
«Человеческий фактор».
По-моему, роль России в закапывании Паскаля несколько преувеличена. Точнее, у нас наоборот он и производные получили большее распространение, чем на родине Кернигана и Риччи.
> По-моему, роль России в закапывании Паскаля несколько преувеличена. Точнее, у нас наоборот
> он и производные получили большее распространение, чем на родине Кернигана и
> Риччи.На, вот, сам почитай, был уже здесь такой спор:
https://www.opennet.me/openforum/vsluhforumID3/118392.html
Некоторые индивиды именно _ненавидят_ Паскаль.
> Некоторые индивиды именно _ненавидят_ Паскаль.Будто бы именно они что-то решали в комитете по стандартизации, где по понятным причинам продвинули продукт своих соотечественников.
> Некоторые индивиды именно _ненавидят_ Паскаль.Я вот учился на паскале, но в конце концов перешел на си. Системные вещи на паскале - ну не то чтобы совсем нельзя, чуваки даже в досе саундбластер из паскаля напрямую программировали. Но выглядело это порнографически.
>> паскаль никогда не был тормозом. проблема его в том что синтаксис слишком
>> замудренный, долго писать, тяжело читать исходники.
> Пришлось мне когда-то делать проектик на Pascal, который на практике я не
> использовал. Реализовал всё в срок, сначала написал и отладил на плюсах,
> потом день читал PDF от Free Pascal и день переводил исходник.
> Непривычно, не более. Считаю, что язык был закопан исключительно по политическим
> мотивам.Если говорить по турбо, он же борланд паскаль, то там имхо было две главных проблемы :
- отсутсвие возможности создания obj файла для последующего использования с дру6ими языками, можно было лишь линковать чужие. Вторая - отсутвие множественного наследования в классах как в турбо/борланд си. Хотя в последнем могу ошибаться, давно не касался ни первого ни второго.При этом засчет компеляции модулей существенно сокращалась время компиляции всего проекта. На ЕС1840-1841 это было особенно заметно.
> Думаю мы раскрыли заговор Паскаль топят за то что он слишком быстрый. И это мешает
> производителям железа продавать новое железо.Он просто glibc наверное не пользуется :). Сишники тоже так могут - просто не все об этом догадываются. Можно вообще стандартные либы не линковать, взял да и сделал сам все syscall()-ы. Ну да, неудобненько и портабельность хромает. Но если с ассемблером зарубаться - на нем еще неудобнее и портабельность еще хуже, так что не аргумент.
Вот это поворот!
Думаю, на уровне С++.А Java впечатляет 👍
Java не покажет хорошего результата на таком коротком тесте, JVM требует прогрева. Это было ожидаемо.
> Java не покажет хорошего результата на таком коротком тесте, JVM требует прогрева.А она вообще может показать хороший результат? Сколько я ни пытался использовать жабософт, положительных эмоций от него не испытывал ни разу. Тормозит и жрёт всю память, что видит. Нет, не так: ТОРМОЗИТ ДАЖЕ НА РОВНОМ МЕСТЕ и жрёт всё, до чего может только дотянуться. И ещё прогрева какого-то требует, как жигуль в морозы. Если это — новые и современные технологии, то мой член — первый заместитель Папы Римского.
Плохому танцору Ява мешает. Кошка бросила котят - это Ява виноват.Использую продукцию джетбрейнс - не тормозит. Использую онлайн-банк, о котором доподлинно известно, что он на Ява ЕЕ - не тормозит.
Ява - это не КГИ, который запускается с нуля на каждый ХТТП-реквест. Ява для долгоиграющих приложений.
Если конкретно у тебя все тормозит, пиши мне на почту, хочу купить твой комп, - я коллекционирую железо 80-90 годов.
На нетбуке, где geany летает, нетбинс адово тормозит.
Пишу промышленные банковские приложения на нетбуке. Звонить 333-333-333, спросить Толю.
Я согласен с тем мистером. Ява действительно тормозит. И всегда будет тормозить. Лучше уж пайтон использовать, или нод, или любой другой аналог, заточенный под конкретные нужды. Всегда есть выбор.
Когда говорим про долгоиграющие приложения, то Ява существенно быстрее ноды. А нода быстрее пихона. (Уже запущенная Ява тормознее с++ всего в полтора раза.) Более того, в Яве тру многопоточность, а в пихоне и ноде ее нет. Далее, в пихоне нет нормальной jit, а в ноде и Яве есть. Единственное, когда Ява тормознее - запуск. Поэтому одноразовые скрипты (написал, запустил и удалил) лучше писать на ноде или пихоне. А серьезные долгоиграющие приложения - на Яве. Особенно если важна скорость отклика.
Ява, как и Нода, как и Питон всего лишь инструменты. Меня всегда поражали умники, которые сравнивают ЯП и приходят к тому, что один хуже другого, потому что [подставить своё]... Естественно у одного ЯП это удобнее и лучше, а другое нет.
Это я в общем о тенденции, а не о конкретно вашем комментарии. Он, в отличие от распространённой тенденции на опеннете, адекватный
> Плохому танцору Ява мешает. Кошка бросила котят - это Ява виноват.А и я не пишу на этом фекалоиде, у меня хватает ума выбирать инструменты получше.
> Использую продукцию джетбрейнс - не тормозит.
На хэллоуворлдах что угодно не тормозит. Ты попробуй нормальный проект в ней открыть, а лучше — поразрабатывать. Тогда-то и поймёшь, что твои студенческие поделки в тысячу строк — херня.
> Использую онлайн-банк, о котором доподлинно известно, что он на Ява ЕЕ - не тормозит.
А теперь прикинь хотя бы приблизительно, сколько бабла банк потратил на оборудование, которое это тянет, и сколько ещё по дороге распилили. И вообще, зачем взяли именно самое неадекватное по потреблению ресурсов решение.
> Ява - это не КГИ, который запускается с нуля на каждый ХТТП-реквест.
> Ява для долгоиграющих приложений.Жаба для того, чтобы показывать её как пример максимально отвратительной реализации как ЯП, так и рантайма, VM и всего остального, что к ней относится.
> Если конкретно у тебя все тормозит, пиши мне на почту, хочу купить
> твой комп, - я коллекционирую железо 80-90 годов.У меня свеженький десктоп и околотоповый ноут 2013 года. Летает всё, кроме этой вашей жабы. Даже всякое безобразие на пыхтоне нормально крутится, ибо не сжирает под себя всю доступную память, залезая своими грязными ручищами в мой девственно чистый своп.
> прикинь хотя бы приблизительно, сколько бабла банк потратил на оборудованиеА прикинь, сколько он бы потратил на программистов, пиши и сопровождай они бизнес логику на ассемблере/с/спп?
Тем более, что в Яве тормозит только гуйная подсистема. И то не настолько, чтобы это было заметно. Скажем, к отзывчивости гтк-приложений у меня больше претензий, чем к идее, хотя они написаны на си. Допустим, gedit напрочь зависает при попытке открыть текстовый файл с единственной, но очень длиной строкой. Понятно, что это не из-за си, а из-за гедита, но зато демонстрирует, что гуй тормозит в первую очередь из-за конечного приложения или гуйной подсистемы. В случае с Явой тормозит свинг.
А веб-приложения от свинга не зависят, поэтому твой аргумент про то, что (лично) у тебя тормозит гуй, идёт мимо (банковской) кассы.
> Жаба для того, чтобы показывать её как пример максимально отвратительной реализации как ЯП, так и рантайма, VM и всего остального, что к ней относится.
Конкретики не хватает. Звучит громко, но не убедительно.
> А прикинь, сколько он бы потратил на программистов, пиши и сопровождай они
> бизнес логику на ассемблере/с/спп?И тем не менее, LSE однажды познали что иной раз проще и дешевле не только писать на си++ но и всю команду купить. По сравнению с выплатами дотнетчикам за устранение их же клюков.
>> Java не покажет хорошего результата на таком коротком тесте, JVM требует прогрева.
> А она вообще может показать хороший результат? Сколько я ни пытался использовать
> жабософт, положительных эмоций от него не испытывал ни разу. Тормозит и
> жрёт всю память, что видит. Нет, не так: ТОРМОЗИТ ДАЖЕ НА
> РОВНОМ МЕСТЕ и жрёт всё, до чего может только дотянуться. И
> ещё прогрева какого-то требует, как жигуль в морозы. Если это —
> новые и современные технологии, то мой член — первый заместитель Папы
> Римского.У Жаббы ощутимо тормозит прежде всего ГУЙ, да и то не всегда. А если консольное и «после разогрева», как тут уже заметили, то Жаба не хуже Сишечки, ЦПП и других «быстрых» ЯП. Попробуй написать на Жаббе простое консольное приложение, которое принимает от пользователя какие-то числа и считает их по каким-то твоим формулам — сам всё увидишь.
> А если консольное и «после разогрева», как тут уже заметили,То как тут уже заметили, это нужно только полутора корпорациям для их бизнес хрени. Все остальное в таком виде никуда не годится.
>> А если консольное и «после разогрева», как тут уже заметили,
> То как тут уже заметили, это нужно только полутора корпорациям для их
> бизнес хрени. Все остальное в таком виде никуда не годится.Чувак, ты просто попробуй. Если тебе нужно что-нибудь кроссплатформенно считать для твоего малого бизнеса — напиши на Жабе и познай смысл жизни и её удовольствий. Компилировать ничего не надо, достаточно JRE на каждой машине. Уж извини, что мне приходится выступать за КО.
> Чувак, ты просто попробуй.У меня нет юзкейсов для этой фигни.
> удовольствий. Компилировать ничего не надо, достаточно JRE на каждой машине. Уж
> извини, что мне приходится выступать за КО.Компилировать ничего не надо, потому что это фуфло не только кряхтит GC, но и тащит с собой весь компилятор и поэтому тормозить своей компиляцией будет прямо в процессе работы. При том сгенерить именно оптимальный код - надо убить море ресурсов. И одно дело если это билдферма где-то там сделала месяц назад и другое - если это вотпрямща под текущим юзером, тудыть.
Это уже даже до веб-хомяков доперло. Вон go - таки компилируемый. И одно это ему дает 100 очков форы. А вот прямо по сравнению с явой - он своим компилером будет тупить не при обслуживании юзера. И это хорошо и правильно.
>> удовольствий. Компилировать ничего не надо, достаточно JRE на каждой машине. Уж извини, что мне приходится выступать за КО.
> Компилировать ничего не надо, потому что это фуфло не только кряхтит GC,
> но и тащит с собой весь компиляторhttps://docs.oracle.com/javase/specs/jvms/se7/html/jvms-6.html
> Chapter 6. The Java Virtual Machine Instruction Set
> aaload
> bipushhttps://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.ht...
> A Code attribute contains the Java Virtual Machine instructions and auxiliary information for a single method,
The Code attribute has the following format:Code_attribute {
u2 attribute_name_index;
u4 attribute_length;
u2 max_stack;
u2 max_locals;
u4 code_length;
u1 code[code_length];
u2 exception_table_length;
{ u2 start_pc;
u2 end_pc;
u2 handler_pc;
u2 catch_type;
} exception_table[exception_table_length];
u2 attributes_count;
attribute_info attributes[attributes_count];
}
Ох уж эти опеннетные знатоки жабы, оба два.> и поэтому тормозить своей
> компиляцией будет прямо в процессе работы. При том сгенерить именно оптимальный код - надо убить море ресурсов. И одно дело если это
> билдферма где-то там сделала месяц назад и другое - если это
> вотпрямща под текущим юзером, тудыть.И процесса компиляции с оптимизацией - тоже.
секрет в том что там где жабософт хороший и не тормозит ты его даже не заметишь, а там где джаву не к месту запихнули выходит ожидаемое неуместное говно..
> там где жабософт хороший и не тормозит ты
> его даже не заметишь, а там где джаву не к месту
> запихнули выходит ожидаемое неуместное говно..Тогда возникает резонный вопрос: а нахрена её пихают туда, где она даром не нужна? Может, жабософт и правда бывает хорошим, но ни одного примера хорошей, годной программы на жабе пока ни диванные аналитики, ни реальные практики, не привели. Сидят, читают мантру «память дешёвая, процессоры тоже», и с примерами не спешат.
Так она не на то создана, насколько вообще понимаю в этих колбасных обрезках. А чтоб сановские железо+софт не провалились под напором винтела, потому как манагерам удобней стало бы писать софт дольше, но зато предсказуемей (в т.ч. за счёт распараллеливания по индус-триальным кодерам).
> Так она не на то создана, насколько вообще понимаю в этих колбасных
> обрезках. А чтоб сановские железо+софт не провалились под напором винтела,
> потому как манагерам удобней стало бы писать софт дольше, но зато
> предсказуемей (в т.ч. за счёт распараллеливания по индус-триальным кодерам).Да, но чуть дополню.
Сановские манагеры искали "прорывные идеи" и жава с автоматическим управлением памятью подходила. Одновременно инженеры со стороны железа подтверждали, что в перспективе они смогу сделать и итеративно улучшать java-процессор. В том числе это коррелировало с идеями взять лучшее от микрокода CISC и IBM-овской z.
Потом всё это начали быстро и "эффективно" реализовывать, приправляя евангелизмом и маркетингом. Но видимо сильно торопились в уходящий поезд, недоинженирили язык в купе с итоговой моделью памяти и т.д. и т.д. Что до сип под выражается в потере производительности из-за нелокальности обращений к памяти и других затрат, ради идеи абстрактно-красивой виртуальной машины...
Java на сегодня единственный язык для живучих больших проектов, для которых живучесть и надежность важнее скорости разработки и скорости приложения. Её нишу возможно займёт кристалл, но пока это лишь мечты(....
> Java не покажет хорошего результата на таком коротком тесте, JVM требует прогрева.Поэтому если у вас не энтерпрайзный сервак считающий неделю какую там бизнеслогику - получается нечто ужасное, старт hello world на этом больше похож на запуск космической ракеты. И то там наверное меньше действий требуется.
Надо учитывать запуск JVM. Тоже самое можно было бы сказать и про шарп (которого тут нет). При запущенном результат был бы куда лучше.
А накуя поделка от Майкрософт? От Майкрософт нам ничего не нужно.
Не говори за всех. Если тебе не нужно - это не означает, что никому не нужно
Вам - это вам и вашему супругу?
C#: syscalls: 117.net core 3.1
> C#: syscalls: 117
> .net core 3.1Смотрел и судил по скриншоту, там почему то его нет. Но в любом случае показатели не достоверны, так как не ясно насколько быстро работат сам язык, а не просто инициализация + работа языка.
А ты не думай, а проверь... fpc-3: всего 12 сисколов, между асмом и си.
Наглядно демонстрирует раздутость современного ПО
Наглядно демонстрирует, любителя забивать гвозди микроскопом, и что кроме хелоуворлда на асме ничего не пишется.
Си позволяет делать прямые ассемблерные вставки для радикального увеличения скорости конкретных фрагментов.
На данном историческом этапе эта задача успешно решается интринсиками.
> Наглядно демонстрирует, любителя забивать гвозди микроскопом, и что кроме хелоуворлда
> на асме ничего не пишется.Наглядно демонстрирует, что новость можно комментировать не читая и не заходя на сайт автора
rwasa is our full-featured, high performance, scalable web server designed to compete with the likes of nginx. It has been built from the ground-up with no externel library dependencies entirely in x86_64 assembly language, and is the result of many years' experience with high volume web environments. In addition to all of the common things you'd expect a modern web server to do, we also include assembly language function hooks ready-made to facilitate Rapid Web Application Server (in Assembler) development.
>entirely in x86_64 assembly languageудачи ему в запуске этого говна на risc-v и arm. Да даже просто на x86.
Удачи тебе понять, надо ли ему это. ;)
Рряяя! Это вы не понимаете! Люди должны даже пукать с оглядкой на risc-v! Как так, оно кому-то не нужно?! Ррряяя!
Ну а если серьезно, то за почти 10 лет своего существования риск-пять стала своего рода вейландом среди архитектур. Мы только и слышим, что "вот-вот победим!", а по факту оно так и болтается на уровне микроконтроллеров.
Да, нужно поддерживать монополию x86_64 такими проектами и славить Intel ME и AMD PSP. А все остальные архитектуры, включая i586 и i686, не нужны, нужно сидеть на опеннете и раздавать советы выкинуть компы и телефоны на помойку.
Чтобы не поддерживать монополию, у юзеров должна быть возможность приобрести альтернативы, способные полностью заменить, а то и превзойти продукт монополистов. Что могут предложить Риска и прочие подобные проекты, чтоб юзеры вот прям сейчас бросились их покупать? Идеологическую чушь про "свободу используемых команд от корпораций" для полутора поехавших фанатиков? Нет, ребята, рынок так не работает. По факту это ноль целых нифига десятых.
Чтот не вижу его https://www.techempower.com/benchmarks/#section=data-r18
> Наглядно демонстрирует, любителя забивать гвозди микроскопом,
> и что кроме хелоуворлда на асме ничего не пишется.Еще кодеки и крипто забыли. Хорошая ассемблерная реализация может чисто сишную разика этак в три подвинуть если компилер с кодогенерацией в неудачном месте протупляет.
Сишники правда немного жульничают сейчас с intrinsics, но по большому счету, это по сути тот же ассемблер и получается, просто чуть более кроссплатформенно и портабельно. Но из-за привязки к особенностям процессоров - именно чуть. Ну то-есть простой фрагмент может быть даже и соберется не только на SSE2 но и на neon каком. Но половина кода завалится за отсутствием потребных эквивалентов команд у железа.
Руби как всегда.
Восхитительно! :-)Удивляет Игогошечка. Всё остальное не удивляет.
Ага, как-же новый системный язык Раст то ей слил по числу инструкций.
Раст использует c runtime library под капотом, но в пару строк конфигруации можно статически прикомпилить себе стандатрную библиотеку rust, естественно со всеми оптимизациями. https://github.com/japaric/xargo
Тем не менее меньше чем у Си не будет в инструкциях из-за cruntime. Есть также реимплементация, но только для redox и линукс. https://github.com/redox-os/relibc
игогошечка как и баш - годится только для мелких скриптецов.
игогошечка годится для мелких серверцов, ну вообще совсем не как баш.
> результаты бенчмарка
> 23-минутное видеоМда.
rust уделал плюсы по полной, учитывая нафаршированность языка - вывод очевиден
А Go уделал Раст.
А плюсы уделали бы обоих, еслиб использовали printf/write, а не iostreams
У раста еще и выполняемый образ под 6 Mb, против 1 Mb у Go и 12 Kb у C/C++
Интересно как это получилось, у меня ни в какую не вышло собрать также, даже с дефолтными опциями компиляторов.
На C вышел бинарник 8 кб, на расте (дебажный билд, по дефолту) 2,5мб.
Как он получил 6мб?
Я уж молчу про прочие характеристики типа числа системных вызовов. У меня для C вышло 24, у него 54.
o_O
P.S Троллинг, не иначе.
Да уж, загадка века.$ cat x.rs
fn main() {
println!("hello");
}$ rustc x.rs
$ ls -lh x
-rwxr-xr-x 1 burjui users 2.5M Dec 8 12:22 x$ strip x
$ ls -lh x
-rwxr-xr-x 1 burjui users 207K Dec 8 12:22 xОй, а что это? Оказывается, в бинаре 90% занимает отладочная и прочая служебная информация, не влияющая на работу программы (кроме как на стектрейсы).
Я ни на что не намекаю, ноgovno@pc /tmp $ rustc x.rs
govno@pc /tmp $ ls -lAh x
-rwxr-xr-x 1 govno govno 276K Dec 8 13:59 x
govno@pc /tmp $ strip x
govno@pc /tmp $ ls -lAh x
-rwxr-xr-x 1 govno govno 199K Dec 8 14:00 xКак ни пытался я так и не смог собрать бинарник больше этого. Может у вас там ночнушки?
Нет:$ rustup toolchain list
stable-x86_64-unknown-linux-gnu (default)$ rustc --version
rustc 1.39.0 (4560ea788 2019-11-04)
$ rustc --version
rustc 1.39.0Это что же получается, раст продуцирует рандомный код? Хотелось бы иметь хоть какую-то воспроизводимость, а то так на одной машине код будет выполняться за минуту, а на другой за тысячу. Хотя... llvm у меня в расте 9.0.0 - может, это как-то связано.
> Хотелось бы иметь хоть какую-то воспроизводимостьГоворят, что они к этому весьма близки: https://github.com/rust-lang/rust/issues/34902#issuecomment-...
> -rwxr-xr-x 1 govno govno 199K Dec 8 14:00 xОтличное название, суть передает верно.
> Может у вас там ночнушки?
Это горшки которые?!
Ну ладно, а чего там на 207 кило? А то сишный бинарь с этим вот, после strip - 14 кило... Ну или с отладкой - так и быть, 16. Это такой пример насколько у растоманов руки из неправильного места? Или они там с go конкурируют за жирноту программ в дефолтном билде?
На этот вопрос я вам ответить не могу, не разбирался, а из какого места руки растут, покажет история. Rust пока что молодой, а у старика C за плечами почти 50 лет развития и полировки. Учитывая, как приятно писать на Rust, и какова его производительность, можно точно сказать одно - для 9-летнего щегла весьма неплохо. А компилятор доработают.
> На этот вопрос я вам ответить не могу, не разбирался, а из
> какого места руки растут, покажет история.По-моему размер сгенеренных бинарей - показывает. Go конечно еще и не так умеет.
> Rust пока что молодой, а у старика C за плечами почти 50 лет развития и полировки.
Не помню использования компиляторов с 50-летней историей... да и си 50-летней давности был не очень похож на актуальный.
> Учитывая, как приятно писать на Rust, и какова его производительность, можно
> точно сказать одно - для 9-летнего щегла весьма неплохо. А компилятор доработают.Маркетинговый булшит и субъективщина, в отличие от результатов забега. В этом вся хипсотота - наобещают в рекламе золотые горы. По факту горы будут из другого материала и их замучаешься вычищать.
Аноним демагогировал-демагогировал, да не выдемагогировал.
> Аноним демагогировал-демагогировал, да не выдемагогировал.Признаю: в порожней демагогии ты меня сделал как с куста. Но маркетинг у тебя все же лажовенький.
> Ну ладно, а чего там на 207 кило? А то сишный бинарь
> с этим вот, после strip - 14 кило... Ну или с
> отладкой - так и быть, 16. Это такой пример насколько у
> растоманов руки из неправильного места? Или они там с go конкурируют
> за жирноту программ в дефолтном билде?Это такой пример, как на опеннете обычно сравнивают жопу с пальцем - в этом случае дин. прилинкованный рантайм со статистическим.
rustc hello_rust.rs -O -C prefer-dynamic && strip hello_rust && ls -al hello_rust
-rwxr-x--- 1 аноним аноним 15296 11 Dez. 17:06 hello_rust
6mb потому что это debug сборка, если собрать релиз с оптимизациями будет 980kb и количество syscall будет 78 а не 120...
только по количеству инструкций, но не по производительности
Смешно, что мы сравниваем Rust - убийцу C 21 века, с Go - убийцей PHP 21 века.
> Rust - убийцу C 21 векаНе C, а C++. Второй уже, кстати, убийца, после D. Может быть, у третьего и получится.
> с Go - убийцей PHP 21 века
Какой ещё PHP в XXI веке? Python, Java.
На C++ никто не предлагает писать операционки, а на раст не только предлагают, так еще и писать пытаются.
Дело в том, что даже сами авторы языка С++ не советуют на нём писать.
Конечно, нет и никогда не было ни BeOS, ни Haiku, ни Symbian…
О, кстати да, про Symbian забыл. Хотя там использовалась очень кастрированная версия C++ без исключений, со своими строками. Для лучшего управления ресурсами. Про остальные не в курсе, не сталкивался.
Исключения - один из множества механизмов С++, далеко не самый важный и большой. Называть отсутствие исключений "очень кастрированный" - это показывать свою техническую неграмотность.
https://www.top500.org/
Где?
> На C++ никто не предлагает писать операционкиА как же реактос? Им конечно не пользуются даже сами разработчики, но это им не мешает наворачивать ядро на плюсах. Наверное потому что поддержка C VS'ом - уг.
> Какой ещё PHP в XXI веке? Python, Java.с каждым новым релизом пхп и так движется в сторону питона и явы.
> Смешно, что мы сравниваем Rust - убийцу C 21 века, с Go - убийцей PHP 21 века.Кто эти вы и зачем эти "вы" лезут сюда с "выводами" о ЯП после сравнения теплых хелловордов и мягких, дефолтных опций и рантаймов конкретной реализации конкретного компиялтора (или интерпретатора)? o_O
Убийство - преступление.
> Убийство - преступление.Killall - вообще сплошной геноцид демонов.
> плюсы уделали бы обоих, еслиб использовали printf/write, а не iostreamsТогда не было бы отличий от реализаций на C.
Да, rust язык очень полезный. Программистом, которые пишут код на С++, работающий медленнее написанного на расте дорога одна, переходить на раст. Им ничто уже не поможет
Это не тестирование, это троллинг недалекого человека.
Жалуешься что тебя затроллили ?
Как сказал когда-то мой препод: "писать на ассемблере под Линукс - это самоубийство".
Что он имел в виду? Под linux писать на асме гораздо приятнее чем под DOS или под Windows.
> Что он имел в виду? Под linux писать на асме гораздо приятнее
> чем под DOS или под Windows.¿А что не так с MS/PC/DR DOS?
Ровно два прерывания: одно для вывода текста, второе для завершения процесса.
>> Что он имел в виду? Под linux писать на асме гораздо приятнее
>> чем под DOS или под Windows.
> ¿А что не так с MS/PC/DR DOS?
> Ровно два прерывания: одно для вывода текста, второе для завершения процесса.Не, так оно только в первой половине учебника ассемблера для дос. Дальше выясняется, что всё гораздо-гораздо интереснее, и в учебнике не написано как работать с мышью, со звуком так вообще надо с железом общаться напрямую, причём с разными звуковухами по разному, работа с видеокартой -- это отдельная песня, и про неё написаны отдельные книги, и много других очень увлекательных вещей можно узнать.
Для мыши есть int 33. И в учебниках это было описано еще тогда, когда вас у родителей и в планах не было.
> Для мыши есть int 33. И в учебниках это было описано еще
> тогда, когда вас у родителей и в планах не было.Возможно в каких-то и было описано. Я не видел ни в одном, выяснял как работать с мышью дизассемблированием. Когда вас в планах родителей не было, у меня не было не то что интернета, даже и FIDO никакого не было, и поэтому знания приходилось выгрызать.
У меня тоже ни интернета, ни фидо не было. Но мне, видимо, повезло - я жил не в ебенях и походы по вычислительным лабораториям местных институтов зачастую приносили хорошие плоды в виде файлов документации (а иногда и распечаток).
> Для мыши есть int 33. И в учебниках это было описано еще
> тогда, когда вас у родителей и в планах не было.Ага, а у современного железа с IOAPIC это может быть... эээ... у APIC много прерываний. И кстати что такое int33, допустим, в контексте usb? USB как таковой вообще прерываниями не оперирует. Хоть какие-то приколисты и назвали один из типов транзакций interrupt, но это не имеет ничего общего с прерываниями проца.
>> Что он имел в виду? Под linux писать на асме гораздо приятнее
>> чем под DOS или под Windows.
> ¿А что не так с MS/PC/DR DOS?
> Ровно два прерывания: одно для вывода текста, второе для завершения процесса.У x86 (16-ти разрядный набор команд) нет плоской модели памяти, приходится заморачиваться с сегментами, а регистры "общего назначения" заметно специализированы. Если бы всё было так же просто как в 32-х и 64-х режимах, в то время больше бы писали на ассемблере, поскольку тогда компиляторы заметно отставали по скорости сгенерированного кода.
В то время на ассемблере больше и писали. Ассемблер был везде. И никаких "заморочек" с сегментами не было.Дожили, помнить что "физический адрес = сегмент*16+смещение", это заморочки. Поколение вебмакак уже в элементарную математику второго класса общеобразовательной школы не может.
А селекторы в 32 и 64 - не заморочки? Кто из вас сможет с ручкой в руках привести линейный адрес в физический? Кто из вас вообще в курсе, что в памяти есть специальная таблица трансляции, куда надо обратиться по специальному селектору, чтобы узнать куда и как смещать линейный адрес, какой размер страницы в памяти и присутствуют ли они вообще физически? А перед этим еще надо права доступа проверить... "Заморочки" у них, тьфу.
> В то время на ассемблере больше и писали. Ассемблер был везде. И
> никаких "заморочек" с сегментами не было.Ты ещё заяви, что асм PDP11 столь же прост, как этот ваш 8086.
> Дожили, помнить что "физический адрес = сегмент*16+смещение", это заморочки.
Сразу видно мосье теоретика-математика. Данные занимают 16 байт, адрес 24, что накладывает ряд ограничений на древовидные структуры данных.
> А селекторы в 32 и 64 - не заморочки?Столь много и красиво написал, и так бездарно слился. Знай: в юзермоде не используются.
> бла-бла-бла
Ну, расскажи нам, зачем нужен префикс lock.
Ахахахах, обезьянка обиделась и с головой бросилась повторно позориться.> Сразу видно мосье теоретика-математика. Данные занимают 16 байт, адрес 24, что накладывает ряд ограничений на древовидные структуры данных.
Сразу видно вебмакаку, ни разу не использовавшую 16-битную архитектуру. Цпу сам, представь себе, автоматически делает операцию умножения и сложения между значением сегмента и смещения при доступе к данным. Ты совершенно свободно можешь использовать весь мегабайт под свои деревья (ну, кроме биоса, адресов замапленых на порты в/в устройств, текущей экранной части видеопамяти, таблицы прерываний и ОС - крч 640КБ плюс хвостик) - главное, не забыть одну простую вещь..., тадаааааам..., внимание, сейчас вылетит птичка..., вот: использовать два слова под указатели, а не один! одно под сегмент, одно под смещение.
> Столь много и красиво написал, и так бездарно слился. Знай: в юзермоде не используются.
А-ха-ха-ха-ха-ха-ха-ха!!!! Ну вы бы, детки, хоть в интернет заглядывали прежде чем позориться прилюдно на таких элементарнейших вещах.
Вся вышеописанная математика 32 и 64 архитектуры используется всегда! Включая так называемый "реальный" режим работы 32 бит, когда при переключении из защищенного, надо было сначала подготовить и загрузить в селекторы правильно приготовленные вышеперечисленные чиселки (они при этом дублировались в теневые "типа кеш" регистры и только потом прыгать в реальный.
Вот так вот - трансляция линейного адреса в физический - очень непростая задача.> Ну, расскажи нам, зачем нужен префикс lock.
Достижение атомарности операций. Учись, студент, пока я жив.
> Ахахахах, обезьянка обиделась и с головой бросилась повторно позориться.Да, бомбануло её знатно. Под ДОС на асме она исписались, а читать русский язык не научилась.
Напоминаю тебе исходное утверждение "Под linux писать на асме гораздо ПРИЯТНЕЕ чем под DOS или под Windows".
Или тут кто-то сомневался, что ты первая в ДОСе после бога?
>> Сразу видно мосье теоретика-математика. Данные занимают 16 байт, адрес 24, что накладывает ряд ограничений на древовидные структуры данных.
> Сразу видно вебмакаку, ни разу не использовавшую 16-битную архитектуру. Цпу сам, представь
> себе, автоматически делает операцию умножения и сложения между значением сегмента и
> смещения при доступе к данным. Ты совершенно свободно можешь использовать весь
> мегабайт под свои деревья (ну, кроме биоса, адресов замапленых на порты
> в/в устройств, текущей экранной части видеопамяти, таблицы прерываний и ОС -
> крч 640КБ плюс хвостик) - главное, не забыть одну простую вещь...,Кто ей сказал, что я могу? Её обманули. Меня жаба давит, я не привык так памятью разбрасываться.
> тадаааааам..., внимание, сейчас вылетит птичка..., вот: использовать два слова под указатели,
> а не один! одно под сегмент, одно под смещение.А что не 10? Чё мелочиться то, давай, вперёд. Я могу _в_ _некоторых_ случаях две ноды вместо одной использовать.
>> Столь много и красиво написал, и так бездарно слился. Знай: в юзермоде не используются.
> А-ха-ха-ха-ха-ха-ха-ха!!!! Ну вы бы, детки, хоть в интернет заглядывали прежде чем позориться
> прилюдно на таких элементарнейших вещах.
> Вся вышеописанная математика 32 и 64 архитектуры используется всегда! Включая так называемый
> "реальный" режим работы 32 бит, когда при переключении из защищенного, надо
> было сначала подготовить и загрузить в селекторы правильно приготовленные вышеперечисленные
> чиселки (они при этом дублировались в теневые "типа кеш" регистры и
> только потом прыгать в реальный.
> Вот так вот - трансляция линейного адреса в физический - очень непростая
> задача.У тебя комплекс непризнанного автора никому ненужной ОС, или зачем ты это пишешь? Я теряюсь в догадках.
Повторяю: Под linux писать на асме.
Это значит, что мы говорим о написании приложений, где плоская модель памяти.
>> Ну, расскажи нам, зачем нужен префикс lock.
> Достижение атомарности операций. Учись, студент, пока я жив.Когда ты предположил, что оппонент на может прочитать книжку, и возвёл свое предположение в догму ты чем руководствовался?
>Ты ещё заяви, что асм PDP11 столь же прост, как этот ваш 8086.А что там сложного то ?
Кол ассигн по k-ому каналу, по n-ому флагу и т.д.
>>Ты ещё заяви, что асм PDP11 столь же прост, как этот ваш 8086.
> А что там сложного то ?
> Кол ассигн по k-ому каналу, по n-ому флагу и т.д.В том то и дело, у PDP11 простая и понятная система команд, позволяющая кодировать непосредственно в восьмеричном представлении машинного кода без мнемоник. Той гиперболой проверял, знаком ли адресант с упомянутой системой команд.
> Что он имел в виду?Ух как заминусовали то... А то, что прикладное ПО под линукс предпочтительно должно быть мультиархетиктурным, наверно, забыли.
Под вынь, конечно же, которая до недавнего времени только x86, ясен пень легче, тем более ДОС.
>> Что он имел в виду?
> Ух как заминусовали то... А то, что прикладное ПО под линукс предпочтительно
> должно быть мультиархетиктурным, наверно, забыли.Ой, ну это же совершенно отдельный вопрос. Это сильно зависит от того, что ты пишешь и зачем ты это пишешь. Кому предпочтительна мультиархитектурность? Мне? Зачем? У меня есть amd64 и arm64, и как-то так выходит, что если я чего-то пишу, то только для одной из этих платформ. Какая мне разница, будет ли такая писанина мультиархитектурной?
> Под вынь, конечно же, которая до недавнего времени только x86, ясен пень
> легче, тем более ДОС.ДОС сложнее, поверь мне. Там костыли на костылях, костылями погоняют. Если глянуть на историю DOS и программ под него, там можно увидеть, что официальной документации на DOS программистам как правило не хватало, поэтому они лезли в кишки доса и биоса, и поэтому очень быстро DOS'у, для того, чтобы развиваясь не ломать совместимость с существующим софтом, пришлось отказаться от внутренних архитектурных изменений, поэтому всё что появлялось нового реализовывалось в виде наслоений на старое. То же самое с bios'ом. То же самое с самой архитектурой x86. И поэтому программирование под DOS -- это всегда увлекательный квест. Я очень люблю его, и люблю я его именно за те анальные боли, которые он причиняет. Хотя надо признаться, уже лет десять не страдал подобным.
Венда чем-то лучше DOS, но там нет никакого кайфа писать на асме, ты всё равно точно так же будешь дёргать функции из всяких там kernel32.dll, user32.dll, и десятка других, потому что иначе никак. Ну и нафиг это надо?
В лине же, ты берёшь список констант для сисколлов, и по большому счёту это и всё. Да, если ты хочешь общаться с X11, неплохо было бы взять xlib или xcb, чтобы не реализовывать X-протокол самостоятельно, но даже это не очень обязательно: не так уж сложно реализовать те кусочки протокола, которые тебе нужны.
Почему в лине плохо писать на ассемблере -- это потому, что никто не пишет. Поэтому всё очень плохо с утилитами заточенными под написание программ на ассемблере. Элементарно отладка без debug-инфы вызывает кучу проблем. gdb можно использовать для этого, но крайне неудобно. Может его можно заточить под это -- в конце-концов его можно расширять скриптами, -- но я не уверен с каким результатом.
Вы прочитали монолог типичного диванного враля.Начиная с того, что у него "есть amd64 и арм64" (арм-32 у него уже в прошлое ушел, хотя выпускается и продается на ура; да и какой, кстати, арм то? их довольно много и они сильно несовместимы в зависимости от производителя)% продолжая тем, что не знает об апи разных осей и заканчивая тем, что он знает также и об отладке.
Ordu, признайтесь - вы ничего сложнее хелловорлда не писали. Это отлично видно по вашим комментариям.
Начиная с того, что в досе был большой и стабильный список интов (типа сисколов), для которых достаточно было помнить номера (типа то, что вы в линуксе хвалите) и в какие регистры что пихать. Дополнительный софт приносил свои дополнительные номера. Были справочники, у меня был даже очень большой бумажный, где были расписаны возможные конфликты. Еще где-то на антресолях лежит.
В винде сразу был отличный стабильный WinAPI, еще с 16-битной тянулся и до сих пор остается. Который тысячу лет не менялся, просто обрастая новыми функциями. То же самое, что и в линуксе.
> Элементарно отладка без debug-инфы вызывает кучу проблем. gdb можно использовать для этого, но крайне неудобно.
Бездарь!!! Ты НЕ программируешь, ты просто звездишь на форуме.
Все есть, и дебажная инфа (волшебные буквы -g2) и профайлинг (волшебные слова gprof, valgrind, callgrind).
Я прямо сейчас дебажу с помощью F5/F6/F7 через vscode+gdb нейтивные бинари на ведроиде и винде (один код, две разные архитектуры) с полным комфортом - с колстеком, вочем, мгновенным состоянием переменных и брекпоинтами.
> Вы прочитали монолог типичного диванного враля.
> Начиная с того, что у него "есть amd64 и арм64" (арм-32 у
> него уже в прошлое ушел, хотя выпускается и продается на ура;А мне какое дело до того, что он продаётся? У меня его нет. И покупать его я не собираюсь. Нафиг он мне сдался?
> да и какой, кстати, арм то? их довольно много и они
> сильно несовместимы в зависимости от производителя)% продолжая тем, что не знает
> об апи разных осей и заканчивая тем, что он знает также
> и об отладке.Какое мне дело до апи разных осей? Речь идёт о линуксе, все эти железные детали он вполне инкапсулирует, но ежели вам так важно знать, что за железка, то это raspberri pi.
> Ordu, признайтесь - вы ничего сложнее хелловорлда не писали. Это отлично видно
> по вашим комментариям.Ещё один диагност по юзерпикам. Вот что меня всегда забавляет в программистах, почему-то каждый программист уверен в том, что он умнее всех остальных, и что никто кроме него компилятора никогда в руках не держал. Что ещё больше забавляет, из десяти этих программистов, девять не умеют кодить.
> Начиная с того, что в досе был большой и стабильный список интов
> (типа сисколов), для которых достаточно было помнить номера (типа то, что
> вы в линуксе хвалите) и в какие регистры что пихать.Гнусь. Ну, некоторые было сложно обойти, типа работу с файлами, или взаимодействие между процессами, типа как восстановить перехваченный вектор прерывания, чтобы не поломать те программы, которые успели тоже его перехватить, пока я с ним игрался. Но вывод на экран совершенно определённо был там лишним. Дос полагался на биос, а биос настолько тормозно выводит на экран, что его использовать допустимо только в примерах в первой половине учебника.
> Дополнительный
> софт приносил свои дополнительные номера. Были справочники, у меня был даже
> очень большой бумажный, где были расписаны возможные конфликты. Еще где-то на
> антресолях лежит.Да-да.
> В винде сразу был отличный стабильный WinAPI, еще с 16-битной тянулся и
> до сих пор остается. Который тысячу лет не менялся, просто обрастая
> новыми функциями. То же самое, что и в линуксе.Стабильный -- это да, но вот насчёт отличного я бы поспорил.
>> Элементарно отладка без debug-инфы вызывает кучу проблем. gdb можно использовать для этого, но крайне неудобно.
> Бездарь!!! Ты НЕ программируешь, ты просто звездишь на форуме.Я приму твоё мнение к сведению. Оно очень важно для меня.
> Все есть, и дебажная инфа (волшебные буквы -g2) и профайлинг (волшебные слова
> gprof, valgrind, callgrind).Ты вообще читаешь, что я пишу или нет? Один из бонусов писания на ассемблере, что ты можешь отлаживать релиз не сложнее, чем отладочную сборку. Но не в линуксе, потому что в линуксе нет софта, заточенного под отладку без отладочной информации. Так понятнее стало?
> Я прямо сейчас дебажу с помощью F5/F6/F7 через vscode+gdb нейтивные бинари на
> ведроиде и винде (один код, две разные архитектуры) с полным комфортом
> - с колстеком, вочем, мгновенным состоянием переменных и брекпоинтами.vscode слишком сложно для меня, я его только на скриншотах разглядывал.
Если бы вы не писали с таким пафосом, словно вы суперпрофессионал, при этом неся чушь - я бы спокойно прошел мимо. А так вы каждым предложением подчеркиваете что диванный эксперт без опыта, но зато гонору как у гейтса.поотвечаю как и вы, по пунктам:
> У меня его нет. И покупать его я не собираюсь. Нафиг он мне сдался? ... Какое мне дело до апи разных осей?
Мб такое, что если вы не в курсе - то нечего и лезть со своим мнением туда, где в курсе? Я вот пишу для всего этого; причем одновременно и для того, чего еще не выпустили - куча ифдефов, интринсики% совсем изредка ассемблерные вставки. И я знаю о чем говорю.
> Что ещё больше забавляет, из десяти этих программистов, девять не умеют кодить.
Я рад что вас эти 9 забавляют. Им это и рассказывайте. А я тут при чем?
>> Начиная с того, что в досе был большой и стабильный список интов...
> Ну, некоторые было сложно обойти, типа работу с файлами, или взаимодействие между процессами...Во-первых, процессов и их взаимодействия в ДОСе не было. PSP - это Program Segment Prefix, а не Process. Никакой мультизадачности, никаких мьютексов с семафорами; никакой реентерантности - все ручками через локи и велосипеды. И да, я в курсе резидентных программ - разошедшаяся тулза по убиванию программ по Ctrl+Alt+Del - моя работа. Помните такую?
> Дос полагался на биос, а биос настолько тормозно выводит на экран, что его использовать допустимо только в примерах в первой половине учебника.
И вы, конечно же, реализовали свои функции для CGA, Hercules, VGA и всех их режимов? И это все отлично умещалось в сотню байтов - у нас же дискетки еще большие но маленькие, места обмаль.
>> Были справочники...
> Да-да.Забавно, что вы не верите в существование такого справочника.
> Один из бонусов писания на ассемблере, что ты можешь отлаживать релиз не сложнее, чем отладочную сборку.
Во-первых, не можешь. Любую математику из любого кодека в ассемблерном виде вам будет не по силам отладить ни за год, ни за пять - алгоритмы сложнее хелловорлда из асма не восстанавливаются. Любые ошибки по двойному освобождению памяти - тоже. И т.д. и т.п.
Хотя в вашей малинке, где программы по 100 байт размером и ничего такого нет - может быть, может быть...> Но не в линуксе, потому что в линуксе нет софта, заточенного под отладку без отладочной информации. Так понятнее стало?
А, так вы хакир. Так бы сразу и сказали..
Ну да, аналога ollydbg (x32dbg) в лине действительно нету. Но он там и не нужен, ибо есть исходники и никто не запрещает самому собрать с отладочной информацией. А дальше gdb с фронтэндами.
> - алгоритмы сложнее хелловорлда из асма не восстанавливаются.Ложное обобщение.
Попытка съехать на буквоедстве.
> Попытка съехать на буквоедстве.Да лан, расслабься. Если ты не способен восстановить алгоритмы сложнее хелловорлда из асма, это многое объясняет. ;)
>>> Были справочники...
>> Да-да.
> Забавно, что вы не верите в существование такого справочника.Речь о справочнике по Win32 API? Да, был и есть. На сайте Майкрософта можно читать совершенно бесплатно:
https://docs.microsoft.com/en-us/windows/win32/api/
В открытом доступе есть также сконвертированные в CHM версии, о полноте и корректности оных не могу судить:
При чем здесь винапи? Я писал про справочник интов - биоса, доса и дополнительного софта; всяких там БД, мышки, и кучи остального.
Был, да вроде и есть, правда в бумажном виде не видел, Ralf's Brown Interrupt List/
> Если бы вы не писали с таким пафосом, словно вы суперпрофессионал, при
> этом неся чушь - я бы спокойно прошел мимо. А так
> вы каждым предложением подчеркиваете что диванный эксперт без опыта, но зато
> гонору как у гейтса.А, вы из этих, кому обязательно повоспитывать окружающих? Вы из тех, кто на дороге догоняет, обгоняет и ставит машину поперёк дороги тем, кто его подрезал, дабы потом рассказать им, как им следует и не следует водить автомобиль? SJW русского разлива? Вы видяшки снимаете, как вы это делаете? SJW в США когда тормозят родителей, чтобы поорать на них за то, что те ребёнка в машине на парковке оставили, когда отвозили корзину к супермаркету, снимают это на видео и потом выкладывают в интернет летопись о своих подвигах.
> поотвечаю как и вы, по пунктам:
>> У меня его нет. И покупать его я не собираюсь. Нафиг он мне сдался? ... Какое мне дело до апи разных осей?
> Мб такое, что если вы не в курсе - то нечего и
> лезть со своим мнением туда, где в курсе? Я вот пишу
> для всего этого; причем одновременно и для того, чего еще не
> выпустили - куча ифдефов, интринсики% совсем изредка ассемблерные вставки. И я
> знаю о чем говорю.Какое мне дело до того, что вы там пишете? У меня складывается ощущение, что вам не удалось прочитать кусок беседу, предшествующий вашему вмешательству в неё.
>> Что ещё больше забавляет, из десяти этих программистов, девять не умеют кодить.
> Я рад что вас эти 9 забавляют. Им это и рассказывайте. А
> я тут при чем?Меня забавляют не только 9, но и десятый тоже. Он отличается от этих девяти в лучшую сторону только тем, что умеет кодить, но это принципиально ничего не меняет.
>>> Начиная с того, что в досе был большой и стабильный список интов...
>> Ну, некоторые было сложно обойти, типа работу с файлами, или взаимодействие между процессами...
> Во-первых, процессов и их взаимодействия в ДОСе не было. PSP - это
> Program Segment Prefix, а не Process. Никакой мультизадачности, никаких мьютексов с
> семафорами; никакой реентерантности - все ручками через локи и велосипеды.Ну да, да. Но я не помню всех этих терминологий и более того, не стремлюсь помнить, всё это давно быльём поросло и нафиг никому не нужно. Вы же поняли о чём речь?
> да, я в курсе резидентных программ - разошедшаяся тулза по убиванию
> программ по Ctrl+Alt+Del - моя работа. Помните такую?Нет, простите. К тому моменту когда у меня появились интернеты, у меня стоял линукс, и дос я использовал к тому моменту исключитально в эмуляторе либо для запуска игрушек, либо для ностальгии.
>> Дос полагался на биос, а биос настолько тормозно выводит на экран, что его использовать допустимо только в примерах в первой половине учебника.
> И вы, конечно же, реализовали свои функции для CGA, Hercules, VGA и
> всех их режимов? И это все отлично умещалось в сотню байтов
> - у нас же дискетки еще большие но маленькие, места обмаль.Это вы приводите для того, чтобы подтвердить мою позицию о том, что программирование для DOS -- это отстой, даже если писать на асме?
>>> Были справочники...
>> Да-да.
> Забавно, что вы не верите в существование такого справочника.Почему не верю? Верю, но толку-то мне с них теперь? Вон даже у вас эти справочники пыляться на антресолях невостребованными. У меня тоже парочка пылится, я их купил было, когда денег начал зарабатывать, полистал, и... где-то они должны лежать, не нужные никому в силу ненужности доса.
>> Один из бонусов писания на ассемблере, что ты можешь отлаживать релиз не сложнее, чем отладочную сборку.
> Во-первых, не можешь. Любую математику из любого кодека в ассемблерном виде вам
> будет не по силам отладить ни за год, ни за пять
> - алгоритмы сложнее хелловорлда из асма не восстанавливаются.Если эту математику найти в исходных текстах, то понять их не проще, чем в асме. И даже комментарии не помогают, ежели конечно они не в стиле literate programming, когда их можно скомпилять в статью-описание математики. Бывает что описание алгоритма на внятном русском языке не даёт понимания того, как алгоритм работает, и приходится несколько часов ломать голову.
> Любые ошибки по
> двойному освобождению памяти - тоже. И т.д. и т.п.
> Хотя в вашей малинке, где программы по 100 байт размером и ничего
> такого нет - может быть, может быть...У меня складывается ощущение, что вы никогда не пытались отлаживать программу без дебаг-инфы. Я не спорю, это сложнее, но если исключить антиотладку как фактор (её нет или она успешно снята), то дальше нужна лишь небольшая поддержка со стороны софта, чтобы давать осмысленные для меня имена адресам, и тогда единственным принципиальным усложнением по сравнению с исходными текстами, остаются данные -- статическая память и структуры нигде не описаны. И если со статической памятью ещё худо-бедно можно разобраться, найдя все обращения к интересующему адресу, то со структурами такое не прокатывает.
Ну и да, это дос, детка. Там биос влезал в 1Mbit, вместе со всеми его прерываниями, настройками железа, ldt/gdt и прочими штучками. DOS целиком влезал на дискету, и ещё места оставалось. Чё там отлаживать?
>> Но не в линуксе, потому что в линуксе нет софта, заточенного под отладку без отладочной информации. Так понятнее стало?
> А, так вы хакир.Как скажете.
> Ну да, аналога ollydbg (x32dbg) в лине действительно нету. Но он там
> и не нужен, ибо есть исходники и никто не запрещает самому
> собрать с отладочной информацией. А дальше gdb с фронтэндами.Вот поэтому я и говорю, что у линя, как у платформы для написания на асме, есть недостатки. Не фатальные недостатки, но недостатки.
Прерываниыми биоса для вывода текста никто и не пользовался. Серьезные поцанчики работали напрямую с видеопамятью, борясь со снегом для CGA. Ну или досовскими, если речь была про хелловорлд.
Возможно. На ассемблере под Linux не писал, а вот под FreeBSD было дело.
Версия кажется была 4.11, точно не помню.
Я тогда студентом был, а первые появившиеся бесплатные хостинги позволяли либо php4 (как-то выглядело непривлекательно :/ ) либо CGI.
А мы с одногруппником хотели чат сбацать, тогда это было в тренде, свой чатик.
Он на html лепил это всё, а мне досталась серверная часть.
Я, преодолевая отвращение, слепил на php, оно тормозило безбожно и периодически вместо фрейма с чатом вылезала врезка от хостера, что мол ресурсы превышены :))
Не помню как я пришел в этому решению, студент все-таки, времени полно. Я сделал бинарник для CGI на ассемблере. Есстественно он был статический, какие нафиг libc. Три-четыре нужных системных вызова, типа read,write и shared memory вызовов попросту подсмотрел в исходниках libc как оно вызывается, какая конвенция и все такое.
Работало не то слово - летало. Все CGI бинарники писали в общую память, при обновлении страницы попросту выдавался хвост этого кольцевого буфера с текстом чата.
Смутно припоминаю размер ELF результирующий был меньше килобайта и без ld.so запускался, так что куда уж быстрее-то?
Во времена четверочки делал перл скрипт, который изображал из себя хттп сервер. Т. к. памяти на эти ваши апачи с похапе не хватало. 128м было на железке и ей нужна была память для более важных вещей, чем мониторинг.
Тогда модно было lighttpd, когда апача было чересчур.
На фоне этого безобразия с апачем для статики и nginx как раз поднялся. Конечно, спрос есть есть и предложение.
Тогда boa был :-)
У автора сабжа есть тоже вебсервер https://2ton.com.au/rwasa/
Ещё в природе существует https://github.com/nemasu/asmttpd
Тот перл скрипт был и сервером и полезной нагрузкой. И занимал копейки памяти.
8ачем сейчас так извращаться - для меня загадка. Уж лучше написать модуль для нжинкс.
> Ещё в природе существует https://github.com/nemasu/asmttpdЭто про который в опеннетной новости писали
> Интересно, что несмотря на то, что код написан на ассемблере, проведённые (https://news.ycombinator.com/item?id=9571827) пользователями тесты производительности показывают
> существенное отставание по скорости обработки запросов от современных http-серверов, написанных на языке Си.(а еще сам автор собирался делать:
https://github.com/nemasu/asmttpd/issues/9
My current plan for handling 10k+ connections, will edit as it's improved.
Comments are welcome :)Idea: Don't block on anything until it's ready. When waiting for I/O, accept more connections.
+Asynchronous I/O.
+Non-blocking sockets.
+Multi-threaded.
+Self contained threads.
Может asmhttpd не на производительность заточен, а на потребление памяти. Вон в rwasa бенчмарке от производителя тоже написано что при определенных видах запросов nginx его обгонят.
> Может asmhttpd не на производительность заточен, а на потребление памяти.А lwan'а он делает? Этот и на производительность и на потребление памяти смотрит, автор явно шпарит в оптимизациях. И к тому же он может делать более-менее практичные вещи - вплоть до шаблонов и БД (см примеры, там реализации ряда вебапликушных бенчей - даже с базами и ответами в JSON). Правда lwan на си. Да и основная фича - удобный API handler'ов. А coroutines обеспечивают довольно прозрачную работу всего этого.
> У автора сабжа есть тоже вебсервер https://2ton.com.au/rwasa/
> Ещё в природе существует https://github.com/nemasu/asmttpdНе хочу обижать автора, но rwasa - это примерно смесь бутафории и паранойи в духе "назло бабушка на ассемблере пишу".
В частности, все более-менее сложные функции вовсе не "handmage assembly", а допиленный результат компиляции соответствующих реализации на C (например: https://github.com/floodyberry/curve25519-donna => https://2ton.com.au/library_as_html/curve25519.inc.html).
Сейчас и форумы на асме делают https://asm32.info/fossil/repo/asmbb/index
Похоже Преподаватель был не Писателем, а Учителем
Как же бесят все эти бенчмарки на хелловорлдах. Только вводят в заблуждение новичков, которые стоят сейчас перед выбором и черпают информацию у таких вот фанатиков.
Каких фанатиков? Это же просто шутка.
В каком месте смеяться?
А потом бывшие новички, не попавшие в заблуждение, начинают писать многопоточчный код на джаве, дающий 300% оверхеда на порождение этого самого множества потоков. Т.е. на 6-8 ядерниках оно в принипе выиграет, но отзывчивость...
Вы не знали, что во названных в статье языках можно реализовать любые многопоточные модели?
Удачи тебе на гошке реализовывать неродные для нее модели. У нее интероп с сишкой сделан настолько хорошо, что если вставлять sleep(1) в каждый вызов к сишному коду, то получится лишь ненамного хуже.
И в какой-то момент они узнают, что поток порождается один раз, а потом ему только задания подкидывают. А так же 100500 других приёмов. И что?Впрочем, с тех пор, как джава оказалась в андроиде, я сам на неё чертыхаюсь. Хотя она была и есть на своём месте в больших сложных приложениях, в которых проблема - сделать, чтобы они просто работали, а скорость - ну это уже как выйдет.
> Хотя она была и есть на своём месте в больших сложных приложенияхТолько там сложность зачастую искусственная.
Там другая джава, ее даже джавой называть, наверное, нельзя. Хотя теперь уже и не она тоже.Напомню, что гугель (точнее ребята, которых он купил), написали свою джаву с блекджеком и мигалками; регистровую(а не стековую!!), просто бинарно совместимую с оракловой.
> простейшего приложения (вывод 'hello')Я не пишу такие простейшие приложения, кому они нужны?
Если же писать что-то более полезное, чем «привет мир», то результаты будут, скажем, другое
Так в том и дело, что особой разницы не будет. Жаба, как и гадюка, будут всасывать у всех остальных; разница между нормальными языками будет минимальной.
Конец списка переместится в начало достаточно быстро, просто потому что ты не сможешь оптимизировать ассемблер на лету в зависимости от данных, как это делает жит.
> Конец списка переместится в начало достаточно быстро, просто потому что ты не
> сможешь оптимизировать ассемблер на лету в зависимости от данных, как это
> делает жит.То есть, ты обожрался диссоциативов и теперь утверждаешь, что жаба обгонит ассемблер и нормальные нативно компилируемые языки? Можно пруфца, что ваше тормозное гуано для копипастеров так может?
Изи, надо только взять substratevm и выкинуть гц. Но, как и везде, "есть нюанс".
Он про JIT говорит. JIT хорошая штука, которая позволяет генерировать эффективный код, а не ограничиваться кодом "который везде будет работать". Посмотри на гентушников собирающих софт под конкретную машину и радующихся своим нескольким дополнительным процентам производительности. Мелочь, а приятно. И иногда эта мелочь отделяет количественное изменеие от качественного.
Ага JIT за те мс которые есть у него делает оптимизации лучше чем статический компилятор, ну да, верьте, верьте.
Существуют опции gcc -fprofile-generate -fprofile-use, что позволяют оптимизировать с учётом той же информации, что имеет JIT. В таком случае никаких даже теоретических преимуществ у JIT не остаётся. Но по личным наблюдениям могу сказать, что может быть как двукратный прирост(php), так и нулевой(zlib).
> наблюдениям могу сказать, что может быть как двукратный прирост(php), так и
> нулевой(zlib).У Zlib проблемы производительности просто не там. Есть всякие zlib-ng и проч, разгоняющие его раза в 2-3. А еще можно несколько тредов сделать. А есть наоборот, библы которые например пакуют плотнее оригинала, при совместимости формата с zlib. Просто это несколько нишевое и нужно не всем. Обладатели большого парка серверов - может и заморочатся, на предмет как снизить нагрузку или объем трафа, смотря что больше жмет. Но рядовому юзеру и zlib - либа. Хоть на нее и забили все кому не лень и это уже и близко не state of art.
Ну и вообще - кто сказал что профайлинг серебряная пуля? Иди вон LZ4 обгони, хоть с профайлером, хоть с JIT, хоть с ассемблером. Там человек сделал железу удобно. А даже и просто сями. Настолько, что профилировать особо нечего: узнал ты что алгоритм уперся в скорость RAM. А дальше, собственно, чего?
Никто не заставляет оптимизировать "вотпрямщас" (хотя есть и такая возможность и в рантайме есть _намного_ больше вариантов), никто не заставляет оптимизировать в 1 проход, никто не заставляет оптимизировать только под 1 вариант входных данных.
JIT довольно дорог сам по себе и выгоден далеко не во всех ситуациях. Собственно, у статически скомпилированного кода он выиграет только на приложениях, которые крутятся очень долго с похожими входными данными.
> Собственно, у статически скомпилированного кода он выиграет только на приложениях, которые крутятся очень долго с похожими входными данными.Где, собственно, Java и применяется.
> Где, собственно, Java и применяется.Поэтому она "где-то там" :)
Там не мелочь, производительность может и на порядки отличаться в результате работы pgo. Это без модификации исходников, да. Ручками тоже можно сделать необычные оптимизации, но они будут не универсальны, профиты жита с аот именно в оптимизации под данные.
> Конец списка переместится в начало достаточно быстро, просто потому что ты не
> сможешь оптимизировать ассемблер на лету в зависимости от данных, как это
> делает жит.А делает он это бесплатно, посредством привлечения чёрной магии. Пока твой JIT только-только сообразит, как перепилить программу под меняющиеся данные на входе, программа на нормальном языке уже выдаст результат.
go-дюка? 8)
какие? большая программа состоит из тривиальных блоков
Ждем ваш тест
Отлично, спасибо за информацию. Это мотивирует изучать Assembler
Справедливости ради на Сишечке можно добиться приблизительно тех же результатов. Но от main придётся отказаться. Как и от большинства функций стандартной библиотеки и некоторых функций компилятора. Конечно, сейчас не так много архитектур процессоров как во времена появления Си, но переписывания кода с x86-64 на ARM по прежнему не приносит радости.
> Конечно, сейчас не так много архитектур процессоров как во времена появления СиВообще-то дофига и продолжают появляться новые.
> во времена появления Си, но переписывания кода с x86-64 на ARM
> по прежнему не приносит радости.К счастью на си это можно и не делать. Ну так, глядя на 25519 перепертый 1 в 1 с писючного tweetnacl в микроконтроллер. Да, на асме он будет быстрее...
1. Исходники не на гитхабе, не на гитлюбе, не в gitwebе, а в каком-то архиве. Даже открывать не буду: автор явно нас не уважает.
2. Сравнение некорректно. На С++ можно писать в стиле C. И е
Более того, на си можно писать в стиле ассемблера. Уже по результатам си возникают некоторые вопросы, как-то очевидно шуточное сравнение выходит.
Здесь используются рекомендованные языком техники, так что с этим все нормально. То что стримы в C++ тормозные и так все знают. Так-то можно и из PHP С-шный модуль дергать. А вот языки со своими виртуальными машинами действительно могут показать некорректные результаты. Так что тест правда скорей шуточный. Им только растоманов троллить :)
В том то и дело, что стримы в C++ не тормозные. Нужно просто отключить синхронизацию с выводом в stdio. https://en.cppreference.com/w/cpp/io/ios_base/sync_with_stdio
Спасибо, буду знать
Вспомнился c-- :-)
Пошто заминусили человека, макаки?Представьте себе, был такой язык. И одно время даже достаточно распространенный. Именно С-- (минус минус).
он не просто был https://www.cs.tufts.edu/~nr/c--/
он и сейчас есть, например в КолбриОСь используется и развивается http://kolibri-n.org/inf/hll/hll#cmm
Хех, я был уверен что давным-давно умер.Спасибо.
> Исходники не на гитхабе, не на гитлюбе, не в gitwebе, а в каком-то архиве.Это чтобы заодно подсунуть бинарники в расчёте, что их кто-нибудь да запустит…
ну вот!
a говорили, что лапша на баше тормозит загрузку - а оказывается в первой четверке по скорости ;)
там видать парсинг скрипт "echo hello" и вызов echo
В bash "echo" - это builtin. Выжимка strace ./hello_world.sh:stat("./hello_world.sh", {st_mode=S_IFREG|0755, st_size=30, ...}) = 0
ioctl(3, TCGETS, 0x7ffecf9069c0) = -1 ENOTTY (Inappropriate ioctl for device)
lseek(3, 0, SEEK_CUR) = 0
read(3, "#!/bin/bash\necho Hello World!\n", 80) = 30
lseek(3, 0, SEEK_SET) = 0
prlimit64(0, RLIMIT_NOFILE, NULL, {rlim_cur=16*1024, rlim_max=16*1024}) = 0
fcntl(255, F_GETFD) = -1 EBADF (Bad file descriptor)
dup2(3, 255) = 255
close(3) = 0
fcntl(255, F_SETFD, FD_CLOEXEC) = 0
fcntl(255, F_GETFL) = 0x8000 (flags O_RDONLY|O_LARGEFILE)
fstat(255, {st_mode=S_IFREG|0755, st_size=30, ...}) = 0
lseek(255, 0, SEEK_CUR) = 0
read(255, "#!/bin/bash\necho Hello World!\n", 30) = 30
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x1), ...}) = 0
write(1, "Hello World!\n", 13Hello World!
) = 13
read(255, "", 30) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
exit_group(0) = ?
+++ exited with 0 +++
Знатно Поттеринга протроллил.
Системд на С так что Поттеринг все правильно сделал. Слава Леониду.
> Системд на СКак и (ba/da/z/k/c/ok/mk)sh.
Впрочем, как и куча реализаций брейнфака (но там и на асме реализации есть). Ждем переписывания на BF.
Ну и спрашивать зачем все по десять раз интерпретировать, когда можно сразу написать на C хотя системд и интерпретирует свои юнит файлы, зато он делает это с уважением и с благословения Лёни Поттеринга.
Зачем, зачем... Десятое правило Гринспена жы!
>реализованной на ассемблере x86_64 свободной (GPLv3) библиотеки HeavyThing, предлагающей в том числе реализации протоколов TLS 1.2 и SSH2Интересно, как образец, чтобы сделать подобное для микроконтроллеров RV32, RV64, где ограничено количество ПЗУ и ОЗУ.
вывсеврети джава нитармазит!!11
Почему он свой скрипт писал на баше, а не на ассемблере?
Если бы он писал на ассемблере, то ты бы не досмотрел видео до конца.
Можно было хотя бы на си, обожаю смотреть на сишку с https://ioccc.org/
Всё неймётся ассемблерщикам
https://github.com/mrprint/HelloTiny
Кто интересуется ассемблером могу еще порекомендовать https://github.com/Number571/asmlib набор простых библиотек типа печать строк, чисел.Да и видосы от автора тоже могу порекомендовать хорошие видосы https://www.youtube.com/watch?v=TuNiVG2hYuU&list=PLd-kTafWJC...
> Кто интересуется ассемблером могу еще порекомендовать https://github.com/Number571/asmlib
> набор простых библиотек типа печать строк, чисел.Ты лучше расскажи, почему иссую не закрыл. Там даже по-русски объяснили, почему либа полурабочая.
Я не автор, но от себя скажу что ваши syscall это вкусовщина, а int 0x80 работает и на 32 и на 64 битных системах. Да и тем более исходники открыты.
> Я не автор, но от себя скажу что ваши syscall это вкусовщина,
> а int 0x80 работает и на 32 и на 64 битных
> системах. Да и тем более исходники открыты.Да, исходники открыты. Вот возьми их и почитай, посмотри, с какими ограничениями он работает.
С незначительными.
> С незначительными.Ну так то да. Всего-то наполовину меньше. Действительных разрядов в адресе. ;)
Тот же nasm текст вида mov rax, 1 ... syscall оптимизирует до mov eax, 1 ... syscall на выходе. Так как считает что так эффективнее.
В eax номер вызова. Параметры передаются в других регистрах.
> а int 0x80 работает и на 32 и на 64 битных системах...прям стесняюсь спросить, Вы точно про ARM, MIPS или даже e2k?..
...прям стесняюсь спросить а в fasm уже подвезли поддержку e2k? Из коробки он и ARM и MIPS тоже не поддерживает. Так что шутка мимо.
> ...прям стесняюсь спросить а в fasm уже подвезли поддержку e2k? Из коробки
> он и ARM и MIPS тоже не поддерживает.The FASMARM package is a free ARM cross-assembler add-on for FASM
Runs under Win32 (9x/NT/2K/XP/Vista/7/8/8.1/10) and LINUX. Plus a linkable object file for UNIX/LibC
FASMARM currently supports the full range of instructions for all 64-bit and 32-bit ARM processors and coprocessors up to v8.
https://arm.flatassembler.net/
Ну и откройте уже для себя fasm g, который из коробки вообще ни одну архитектура не поддерживает, всё реализуется макросами.
THIRD-PARTY RESOURCES
i8080/85 support by shoorick.
MCS-48 macros by shoorick.
MOS 6502 assembler by codestar.
PIC 14-bit by edfed.
eZ80 includes by jacobly (GitHub).
EFI x64 sample by Akeo (GitHub).
EBC assembler for UEFI by Akeo (GitHub).
Intel MCS-8 I8008 instructions by halak.
STM8 MCU instruction set by shoorick.
aarch64 instructions and formats by tthsqe (GitHub).
PRELIMINARY PROJECTS
WebAssembly
Advanced x86 encoder
https://board.flatassembler.net/topic.php?t=19389
> Так что шутка
> мимо.
То-то я смотрю они из коробки этого франкенштейна боятся распространять. Да и тема MIPS и e2k не раскрыта.
> То-то я смотрю они из коробки этого франкенштейна боятся распространять."У меня нет телевизора: я ем грибы и смотрю ковёр". (с)
Он (автор у fasm-а один) распространяет только свой продукт и как считает нужным. Точно так же отдельно идёт gcc, отдельно boost и прочие библиотеки.
>Джефф Мэррисон (Jeff Marrison), автор реализованной на ассемблере x86_64 свободной (GPLv3) библиотеки HeavyThingдля каллибриОС штоли
А что, нельзя прилинковать её к сишной программе и дёргать из сишного кода?
Perl молодец, собственно, как и ожидалось.
Удивительно, как Питон почти на порядок просел относительно него.
Совсем не удивительно.
> Удивительно, как Питон почти на порядок просел относительно него.Удивительно - что это говорит разработчик из, кажется, BSD. Который мог бы и догадываться почему.
Попробовал самостоятельно провести тест, исплользуя Си (puts) и tcc. Получил 24 taskclock.
gentoo ~/code/perfomance # tcc hello_puts.c -o hello_puts
gentoo ~/code/perfomance # strace -fc ./hello_puts
hello
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
0.00 0.000000 0 1 read
0.00 0.000000 0 1 write
0.00 0.000000 0 2 close
0.00 0.000000 0 3 fstat
0.00 0.000000 0 5 mmap
0.00 0.000000 0 3 mprotect
0.00 0.000000 0 1 munmap
0.00 0.000000 0 3 brk
0.00 0.000000 0 1 1 access
0.00 0.000000 0 1 execve
0.00 0.000000 0 1 arch_prctl
0.00 0.000000 0 2 openat
------ ----------- ----------- --------- --------- ----------------
100.00 0.000000 24 1 total
У tcc есть один нюанс: компилим им какую-нибудь алгоритмику... и убеждаемся что gcc его очень сильно обижает с -O2/-O3. И дальше радости с уменьшения числа сисколов будет маловато.
Попробуй слинковать статически. Лучше с musl. У меня получилось 5 для hello_c_stdio и 4 для hello_c_syscall.
Это против правил.
Делал как-то текстовый парсер на асме и для сравнения тот же парсер сделал на C++ (на самом деле все было наоборот). Код на асме работал в три раза быстрее и при этом 75% времени по strace занимали операции чтения файлов. Самым близким по производительности для моей задачи была реализация xpath из lxml для питона написанная на cython очень близка к коду на C++. А например grep очень сильно отстал. Не претендую на точность и оптимальность алгоритмов поэтому такой новости как сабже и не публиковал.
>xpath из lxml для питона написанная на cython очень близка к коду на C++libxml2 на си написан, не порите чушь - ей больно
Начнем с того что lxml это биндинг для libxml2 и libslt https://lxml.deЗаканчивая тем что даже на сайте libxml2 написано применять lxml http://xmlsoft.org/python.html для питона.
Note that some of the Python purist dislike the default set of Python bindings, rather than complaining I suggest they have a look at lxml the more pythonic bindings for libxml2 and libxslt and check the mailing-list.
И в конце концов lxml каким-то мистическим образом работал быстрее применяя cython и выше названные библиотеки.
Вполне вероятно в природе есть более производительные решения я в целом и не настаивал на истину в последней инстанции.
Всё ещё не понятно, при чём тут питон и плюсы, если сравнение было с сишечкой.
"Once upon a time my boss asked me to study if we should use C++ or Erlang for a specialist XML parser to be used in a product (for reasons of speed not energy).
My recommendations was an FPGA
We built an FPGA.
Relative speed of C++/Erlang was irrelevant compared to FPGA."
https://twitter.com/joeerl/status/1115990630793207808
Тот же Ragel позволяет выдать код лексера, который примерно в 10 раз быстрее сгенерированного flex'ом.
> "Once upon a time my boss asked me to study if we
> should use C++ or Erlang for a specialist XML parser to
> be used in a product (for reasons of speed not energy).
> My recommendations was an FPGA
> We built an FPGA.
> Relative speed of C++/Erlang was irrelevant compared to FPGA."
> https://twitter.com/joeerl/status/1115990630793207808Ничего, придёт ему на смену задорная молодёжь и перепишет всё это окаменевшее на жлобоскрипте (пихтона они уже знать не будут).
Блин, а ларчик то так просто открывался. Вы сделали мой день.
https://github.com/ip1981/gcd
Таки да, ассемблер - отличный инструмент для написания хэлловорлдов
Как этот чел может спать спокойно, осознавая, что все инструменты, которыми он пользовался при записи видео, написаны не на ассемблере?
Ты еще скажи что они не из машинного кода состоят)
Что?
Не увидел чтобы автор видео агитировал за написание всего кода на асме. Просто на практике показал что все удобства даются не бесплатно. Обещал ещё показать в следующих частях какие-то преимущества. Скорее всего покажет что компилеры способны генерировать оптимальный код только в простейших случаях, а толково применять SSE/AVX вообще толком не могут, и ручная оптимизация тут рулит на всю катушку. Полагаю, что основной посыл будет использовать асм там где это имеет смысл. Его и используют. Для оптимизации кодеков, например. Надо же чтобы кто-то это рассказал подрастающему поколению, вот автор видео и старается.
> Компилеры способны генерировать оптимальный код только в простейших случаяхЛол что? Это человек способен генерировать оптимальный код на ассемблере только в простейших случаях. Для большого куска кода у человека от писанины на ассемблере крыша поедет, а о том, чтобы превзойти по оптимальности код компилятора даже речи идти не будет. Современные компиляторы далеко ушли по сравнению с 80-ми, а вы похоже там и остались. Сейчас оптимизация кода производится на многих уровнях, особенно хорошо разработаны оптимизации AST-дерева, которое человек в принципе в голове удержать целиком не способен.
Вот куда ушли современные компиляторы и технологии:
How new-lines affect the Linux kernel performance.https://nadav.amit.zone/linux/2018/10/10/newline.html
Думаю, заголовок статьи говорит сам за себя.
Недавно видел историю где слово register (то самое против которого все топят) применённое к переменной-счётчику, ускоряло код в 9999 раз. Компиляторы такие умные сегодня.
> Вот куда ушли современные компиляторы и технологии:
> How new-lines affect the Linux kernel performance.
> https://nadav.amit.zone/linux/2018/10/10/newline.html
> Думаю, заголовок статьи говорит сам за себя.Думаю, читать все же желательно не только заголовки:
> New lines in inline assembly...
> The reason turns to be the newline characters (marked as ‘\n’ above [asm volatile("1: ud2\n"]). The kernel compiler, GCC, is unaware to the code size that will be generated by the inline assembly. It therefore tries to estimate its size based on newline characters and statement separators (‘;’ on x86). In GCC, we can see the code that performs this estimation in the estimate_num_insns() function:...
> Solving the problem is not trivial. Ideally, GCC would have used an integrated assembler, similarly to LLVM, which would give better estimation of the generated code size of inline assembly.
> Experimentally, LLVM seems to make the right inlining decisions and is not affected by new-lines or data that is set in other sections of the executable ... GCC, however, uses the GNU assembler after the code is compiled,Разъясняю для опеннетных аналитиков современного компиляторостроения:
Т.к. ассемблер запускается после компиляции кода, то размер вставок на момент компиляции - не известен и компилятор вынужден гадать по кол. строк и ";".
Решается проблема ручками (указание размера/оверрайд и т.д.) или же включением ассемблера непосредственно в компилятор.
Надеюсь, что ты не много времени потратил на "онализ" статьи:https://www.opennet.me/opennews/art.shtml?num=49412
> Надеюсь, что ты не много времени потратил на "онализ" статьи:
> https://www.opennet.me/opennews/art.shtml?num=49412Ну и?
> GCC принимает решение об использовании inline-развёртывания функций в зависимости от результатов косвенной оценки размера результирующего кода (даже если функция определена с ключевым словом "inline"). Компилятор не учитывает фактический размер результирующего кода, а пытается прогнозировать его. Для ассемблерных вставок прогнозирование делается на основе числа переводов строк ("\n") и разделителей (";") в исходном тексте.Ты считаешь, что то перевод оригинала:
ссылка из новости == предыдущая ссылка анонима
https://nadav.amit.zone/blog/linux-inline => https://nadav.amit.zone/linux/2018/10/10/newline.html(с некоторыми домыслами, т.к. "inline" по стандарту c99 - только хинт
> A function declared with an inline function specifier is an inline function. The function specifier may appear more than once; the behavior is the same as if it appeared
> only once. Making a function an inline function suggests that calls to the function be as fast as possible.
> The extent to which such suggestions are effective is implementation-defined.и компилятор си не может учитывать фактический размер вставок "foreign" кода:
> Разъясняю для опеннетных аналитиков современного компиляторостроения:
> Т.к. ассемблер запускается после компиляции кода, то размер вставок на момент компиляции - не известен и компилятор вынужден гадать по кол. строк и ";".более "убедителен" или опять "онализировал" только заголовки?
Мечтать не вредно, конечно, но компилеры далеки от того, чтобы самостоятельно задействовать SSE/AVX так, как это мог бы сделать человек.Возьмём в качестве примера libjpeg-turbo. Этот проект - оптимизация обычного libjpeg. Проект проспонсирован кучей видных компаний (https://libjpeg-turbo.org/About/Sponsors), результат используется во всех браузерах и Android. А если заглянете в исходный код, чтобы посмотреть как оптимизировали, то найдёте пачки *.asm файлов (https://github.com/libjpeg-turbo/libjpeg-turbo/tree/master/s...).
Некоторые используют соответствующие различным машинным инструкциям интринсики. Например, такой подход для оптимизации используется в кодеке Opus. Но это, по сути, ассемблер с синтаксисом C.
Что касается качества генерируемого кода C компилеров для обычного кода (который не оптимизируешь с использованием SSE/AVX), то он был весьма посредственного качества не только в 80-х, но и в 90-х (я провёл много времени дизассемблируя игры того времени, знаю о чём говорю). Современные компилеры - да, достаточно умны, чтобы в общем случае генерировать достаточно оптимальный код.
Я делал часть работы по оптимизации libjpeg-turbo.Могу объяснить в чем вы правы и в чем не правы. Если вы взглянете внимательнее на асм код, то заметите что 99% его - это векторные инструкции. Причем зачастую сам алгоритм приходилось переделывать, чтобы он хорошо векторизовался; простых циклов без внутренних зависимостей в коде очень мало.
А это работа уже не компилятора, но ИИ; который в компиляторы пока еще не завезли. Вот и приходилось оплачивать работу человеков.Что же касается оптимизации обычного, не векторизуемого кода - то тут компиляторы дают гарантированную фору человеку. Просто потому, что уже никто не может удержать в памяти весь тот зоопарк сложностей, с которыми работает современный микропроцессор. Все эти микрооперации, кроссзависимости по регистрам и их переименования, реордеринг, кеширование, разные вычислительные устройства и правила их одновременной работы; все эти гипертрединги и т.д. и т.п.
Последний процессор, для которого человек еще хорошо справлялся, был pentium2, с его U и V каналами, которые могли работать одновременно (но не для умножения - умножение работало параллельно c с другой арифметикой только если уходило в U канал). Да и то, есличестно, занятие это было дико муторным и в основном не оправдывало вложенных усилий.
Сейчас оптимизация в основном выглядит так: запускаем профайлер, ищем очень редкие узкие места и задрачиваем их в полуслепом режиме. И так для каждой(!) архитектуры.
Ох, промахнулся немного комментом.
"Что же касается оптимизации обычного, не векторизуемого кода - то тут компиляторы дают гарантированную фору человеку. Просто потому, что уже никто не может удержать в памяти весь тот зоопарк сложностей, с которыми работает современный микропроцессор. Все эти микрооперации, кроссзависимости по регистрам и их переименования, реордеринг, кеширование, разные вычислительные устройства и правила их одновременной работы; все эти гипертрединги и т.д. и т.п."Вот как раз всего этого компилятор "удержать в памяти" и не может, потому что этой информации у него просто нет и взять ее неоткуда.
Именно этот прискорбный факт и стал основной причиной безвременной кончины интеловского итаниума.
Ну здрасьте, приехали. Как это нет - у компилятора есть множество того, что мы не сможем сделать; например, возможность построить граф зависимостей по коду и данным; по использованию регистров и самому "попереименовывая" их разбросать в наилучшем порядке.У gcc специально для вас в асм вставках предлагается использовать не регистры, а условные обозначения с указанием что именно ваша функция (которую гцц не понимает и понимать не должен) использует, что хочет на вход и на выход; после чего гцц с учетом этой инфорации подберет конфигурацию получше, размещая промежуточные данные в одних или других регистрах.
Да много чего есть, чего вам, как человеку, уже недоступно ввиду слишком низкой скорости обработки данных и ограниченности по объему их же.
И поэтому сплошь и рядом компиляторы устраивают в коде какой-то бл..cкий цирк с жонглированием регистрами, выкинув при этом действительно важные переменный на стек.
И кстати куда же делось вот это все: "микрооперации, кроссзависимости по регистрам и их переименования, реордеринг, кеширование, разные вычислительные устройства и правила их одновременной работы; все эти гипертрединги" ? Дошло что написали глупость ?
Да, кстати. Итаниум умер не поэтому.
Умер он потому, что его время новых инструкций без сохранения обратной совместимости еще не пришло.Через десять лет время пришло, но повезло в этот раз арму. Итаниум - это же современный арм, разве что с увеличенной адресной шиной.
Именно поэтому, как и многие другие VLIW процессоры.Не получился всемогущий компилятор, который сможет строить бандлы инструкций, достаточно длинные чтобы получить нормальную производительность.
> Да, кстати. Итаниум умер не поэтому.
> Умер он потому, что его время новых инструкций без сохранения обратной совместимости
> еще не пришло.
> Через десять лет время пришло, но повезло в этот раз арму. Итаниум
> - это же современный арм, разве что с увеличенной адресной шиной.История не знает сослагательного наклонения, но мне думается, что если бы Итаниум был дешевле, меньше грелся и меньше жрал электричества, то его судьба была бы иной.
А ещё жаль, что ХаПэ отправила в музей Альфу.
Бабушка-с-членом-и-усами.jpg
> Итаниум - это же современный арм, разве что с увеличенной адресной шиной.Блин, слона-то я и не приметил. Больше вопросов не имею.
>> Итаниум - это же современный арм, разве что с увеличенной адресной шиной.
> Блин, слона-то я и не приметил. Больше вопросов не имею.Да уж, кучу выдающийся специалист Урри отложил размером с гору.
Так я как бы о том же о чём и вы говорил в предыдущем комментарии. Хочешь по максимуму задействовать возможности SSE/AVX - переписывай код ручками. На асме или интринсиками в C - уже дело вкуса. А полагаться на то что компилер сам догадается - не приходится. Хотя иногда он таки догадывается как какие-то простые циклы можно векторизовать, но это не точно =)
>Некоторые используют соответствующие различным машинным инструкциям интринсики. Например, такой подход для оптимизации используется в кодеке Opus.Это все следствие того, что поддержку векторных типов и операций над ними в стандарт С не завезли.
>Но это, по сути, ассемблер с синтаксисом C.
Нет, по сути это не ассемблер. Не нужно вручную распределять регистры, есть проверка типов.
> Нет, по сути это не ассемблер. Не нужно вручную распределять регистры,
> есть проверка типов.По сути это возможность использовать почти ассемблерные вещи из типа-сей. Правда, начинаются те же проблемы - а такие интринсики компилятся лишь немногим портабельнее ассемблера, фичи бывают слишком уж специфичными для конкретных архитектур.
Тут бы лучше взять пример какой-нибудь прикладной задачи, причем не обязательно с плавающей точкой и векторными операциями.
Полно алгоритмов, где важны DMIPS-ы. Тот же поиск короткого пути в графе или например всякие алгоритмы на строках, типа наибольшей общей подпоследовательности.
Поиск на карте (с частым построением графов), кстати, одна из тех задач, где языки со сборкой мусора уделывают С и плюсами. Кастомные аллокаторы в виде реализации сборки мусора не в счет, естественно.
> Поиск на карте (с частым построением графов), кстати, одна из тех задач,
> где языки со сборкой мусора уделывают С и плюсами. Кастомные аллокаторы
> в виде реализации сборки мусора не в счет, естественно.Фича сей и тому подобных в том что если тебе надо GC - его можно сделать. Поэтому кому было надо - у них и си стал довольно высокоуровневым. А вот если в каком-нибудь Go этот самый GC мешается - уже упс.
>а толково применять SSE/AVX вообще толком не могутOpenCL-компиляторы -- могут.
> OpenCL-компиляторы -- могут.У них даже и не SSE/AVX. У типичного GPU алушек и регистров больше чем у дурака фантиков.
> Скорее всего покажет что компилеры способны генерировать оптимальный
> код только в простейших случаях, а толково применять SSE/AVX вообще
> толком не могут, и ручная оптимизация тут рулит на всю катушку.Вы представляете себе хотя бы количество регистров в нынешних камнях (плюс-минус лапоть)? А таблицы длительности команд под рукой держите?..
Рассказать-то рассказать, да не сказочку, а быль.
Таблицы, коих на самом деле уже давно нет. Так как конвеер длинный и микрооперации сильно зависят друг от друга и окружающей среды (например, предсказания переходов или кеширования памяти).
Почему нет примера на Форте? Это дискриминация.
а джава молодец, уцепился таки зубами за последний вагон уходящего поезда
Ассемблер рулез
Интересно, что perl чуть-чуть проиграл bash, с другой стороны все эти тесты говорят об одном - о нагромождение ненужных прослоек в фреймворках.
Вспоминаю молодость, студент, была дадена ес-1840, в качестве задания писал программу на паскале, потом профилирование и переписывание кусков кода с него на ассемблер, благо там это легко было сделать, когда первый раз сделал слегка удивился...
> ес-1840*пустил скупую мужскую слезу*
+1 :-)Хотя чего там пускать -- айда опять же в Яндекс-музей, можно со своими ластами.
Искра-1030(1031)
Это все говорит не о том что надо писать на Ассемблере, а о том, что подходы к компиляции и особенно к "линковке" в языках программирования ужасно устарели. Если на ассемблере программа занимает 9 инструкций, то и на высокоуровневом ЯП она должна занимать 9 инструкций, не больше. А почему занимает больше? А потому что процесс линковки - это тупо вбухать кучу стандартного кода без разбора, нужен он или нет.
> процесс линковки - это тупо вбухать кучу стандартного кода без разбора, нужен он или нетПочему же, с разбором. Иди, учи матчасть. Рекомендую: https://linker.iecc.com/ (да, за 20 лет мало что изменилось, но это не значит, что подход устарел).
>> процесс линковки - это тупо вбухать кучу стандартного кода без разбора, нужен он или нет
> Почему же, с разбором. Иди, учи матчасть. Рекомендую: https://linker.iecc.com/ (да, за
> 20 лет мало что изменилось, но это не значит, что подход
> устарел).Напомните, пожалуйста, на какой странице там LTO описано.
Зачем ему про LTO? Пусть сначала хоть это осилит.
> Зачем ему про LTO? Пусть сначала хоть это осилит.Автор сообщения #141 описал, какой LTO должна быть. В теории. На практике пока недотягивает... немножко.
Не хочу показаться занудным, но в случае с ассемблером он сначала просто запустил бинарик, а потом второй раз через strace. Во время второго запуска программа считывалась из памяти а не с винта. В случае с СИ он сразу запускал бинарик через strace, то есть были доп затраты на чтение с винта. Как-то так.
Количество вызовов от этого не меняется в среднем.
Я просто шокирован как он быстро пишет код в real-time и по памяти может воспроизвести код (пусть и простейший) нескольких языков.
Ты уверен что это был первый дубль и без подготовки? И без бумажки?
Почему у Си-плюсов на порядок больше инструкций чем у чистого Си? А как же оптимизирующие компиляйторы, которые якобы компилируют код Си и Си++ выполняющий одни и те же действия в одни и те последовательности инструкций? Кто то нам врёт, только вот кто?
Потому что набор вызовов на холодном старте у всех свой.
> Почему у Си-плюсов на порядок больше инструкций чем у чистого Си?Из-за использования потоков ввода-вывода. Иначе говоря, дело в реализации стандартной библиотеки, а не в языке.
Потому что у них разные стандартные загрузчики (stub'ы), у плюсов стандартная библиотека толще.
Потому-что в этом тесте запуск приложения на Си требует загрузки ld.so и libc.so, на для приложения на С++ дополнительно требуется libstdc++.so, а также вызова конструкторов и деструкторов для всех статических объектов (включая инфраструктуру Thread Local Storage).Если различной "магией" избавиться от вышеуказанного, то разницы с ассемблером для C, C++ и Rust не будет _совсем_.
Delphi Pascal forever!
Хорошие языки, ничего против не имею, кстати интересно было бы увидеть и их тесты
Выше есть Паскаль обогнал всех кто не ассемблер.
Что же в делфи хорошего? Разве что, если с Жавой сравнивать.
> Что же в делфи хорошего? Разве что, если с Жавой сравнивать.В прямых руках не хуже сей++ и скорость разработки П.О. выше и косяков меньше. А если руки из опы тут увы извиняйте нечего на язык пинать коли с головой руки из опы, тут никакой язык не поможет.
В своё время писал на нём игры и 64кб демки, особых проблем не видел. А с применением FPC портировал под Linux и Darwin ...
Не вижу ничего особого в этих тестах, да это только холодный запуск и выход... Да для каждого языка эти процессы уникальные, хотелось бы видеть расчёт производительности непосредственно... правда тогда эти расхождения не будут столь существенными.Ассемблер это конечно хорошо и Я сам часто им пользовался в ускорении математических операций, но что то тяжёлое делать на нём я бы всё же не стал, имхо поддерживать это будет очень и очень сложно, да и выстрелить себе в ногу в разы легче чем в том же си...
Теперь подумаем по поводу разумного соотнесения плюшек и производительности. На ассемблере программист должен сам за всё отвечать за каждый пук... Другие языки же решают свои задачи и предоставляют те или иные плюшки чем облегчают работу программисту и уменьшают количество возможных ошибок.
имхо, нужно было бы проверить на циклах, математики к (примеру умножение двух матриц) и работы со строками... тогда можно увидеть более интересную картинку, многие языки будут в этом тесте вести себя одинаково.
Еще один хипстор опубликовал видосик. И как я его в Links посмотрю?
> Еще один хипстор опубликовал видосик. И как я его в Links посмотрю?на хоткей вешаем связку
youtube-dl | awk '... извлечь имя_видеофайла ...'
mpv имя_видеофайла
echo 1-Удалить видео
echo 2-Еще раз посмотреть видео
echo 3-Выход
accept
> Еще один хипстор опубликовал видосик. И как я его в Links посмотрю?Да, видосики без ссылок для скачивания — это серпом по опенсорсам. Но выковырять можно:
https://2ton.com.au/videos/tvs_part1/tvs_part1.mp4 (350 МБ)
https://2ton.com.au/videos/tvs_part1/tvs_part1.webm (155 МБ)
Спасибо, братиш.
Вот аналог программы на ассемблере, написанный на C:
/*
*!gcc -e_Main -nostdlib -o "%<" % -lmsvcrt -lkernel32 && "%<"
*/
#include <stdlib.h>
#include <stdio.h>
#include <windows.h>
void Main()
{
char s[] = "hello\n";
const unsigned sSize = sizeof(s)/sizeof(s[0]) - 1;
/*fwrite(s, sSize, 1, stdout);*/
DWORD outCnt;
WriteConsole(
GetStdHandle(STD_OUTPUT_HANDLE), //handle to a console screen buffer
s, //pointer to buffer to write from
sSize, //number of characters to write
&outCnt, //pointer to number of characters written
NULL //reserved
);
/*WriteFile(
GetStdHandle(STD_OUTPUT_HANDLE), // handle to file to write to
s, // pointer to data to write to file
sSize, // number of bytes to write
&outCnt, // pointer to number of bytes written
NULL // pointer to structure needed for overlapped I/O
);*/
}
И, внезапно, окажется что это то же самое что и асм, только приятней и проще.
Mscvrt, windows.h? Это ты так пошутил? Плохое место ты для этого выбрал.
На Windows для всех языков не будет такой большой разницы, т.е. все сильно сместится в сторону Java. Это просто последствия намеренного дизайна Windows, и уже без возможности что-либо существенно изменить.Но если же предложенное проделать в нормальных ОС, то действительно, для C, C++ и Rust с ассемблером существенных различий не будет. Точнее говоря, разница будет определяться только объемом оставленного "сервиса" (stdio, std::iostream, etc).
>[оверквотинг удален]
> /*WriteFile(
> GetStdHandle(STD_OUTPUT_HANDLE), // handle to file to write to
> s, // pointer to data to write to file
> sSize, // number of bytes to write
> &outCnt, // pointer to number of bytes written
> NULL // pointer to structure needed for overlapped I/O
> );*/
> }
> И, внезапно, окажется что это то же самое что и асм, только
> приятней и проще.Оказывается, ты не понимаешь, что этот "аналог" использует kernel32.dll и ntdll,dll, а вариант для Linux вызывает непосредственно ядро.
Все правильно, использует API ос.
Не угадал. Вызывает kernel32.dll, то есть API подсистемы Win32. API операционной системы Windows NT является Native API. Впрочем, это не имеет отношения к тому, что подобное сравнение некорректно. В Windows NT так же возможно вызывать ядро, но номера системных вызовов различаются от версии к версии.
Нет, это не другое. Подсистема входит в ос, апи публичный, практически все приложения используют его. WriteFile и GetStdHandle от write и open принципиально не отличаются.
> Нет, это не другое.Вызов ядра непосредственно через шлюз идентичен динамическому связыванию?))
> Подсистема входит в ос, апи публичный, практически все
> приложения используют его.Аналогично можно сказать про libc.so
> WriteFile и GetStdHandle от write и open принципиально
> не отличаются.Вот оно что.))) Пример на асме вызывает не write и open из библиотеки пространства пользователя. Функции определены как sys_write и sys_open макросами, подобными нижеприведённому:
#define SYSCALL_DEFINE0(sname) \
SYSCALL_METADATA(_##sname, 0); \
asmlinkage long sys_##sname(void); \
ALLOW_ERROR_INJECTION(sys_##sname, ERRNO); \
asmlinkage long sys_##sname(void)
https://github.com/torvalds/linux/blob/v5.4/include/linux/sy...
На будущее, анон, пиши код в тегах:
[CODE]твой говнокод
[/CODE]
На опеннете негодный парсер, так что запоминай, ибо повторять напряжно.
А чо девять-то? У меня восемь вышло.
ты особенный, гордись этим
Промерял Ocaml - 59 syscalls. Программа:let _ = print_string "hello\n"
Компиляция
ocamlopt.opt -O3 -inline 1000 hello_ml.ml -o hello_ml
> Промерял Ocaml - 59 syscalls. Программа:
> let _ = print_string "hello\n"
> Компиляция
> ocamlopt.opt -O3 -inline 1000 hello_ml.ml -o hello_mlТоже померял:
ocamlc hello.ml -o hello_ocamlbytecodestrace -fc ./microcaml hello_ocamlbytecode
hello
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
0,00 0,000000 0 1 write
0,00 0,000000 0 1 open
0,00 0,000000 0 1 close
0,00 0,000000 0 1 fstat
0,00 0,000000 0 1 mmap
0,00 0,000000 0 1 rt_sigaction
0,00 0,000000 0 1 execve
0,00 0,000000 0 1 sigaltstack
------ ----------- ----------- --------- --------- ----------------
100.00 0,000000 8 total
Но сразу оговорюсь: в более сложных случаях проигрывает штатному интерпретатору.
/usr/bin/echo - язык программирования? Внезапно ...
Эта утилитка представлена как образец выводящий хэлоуворлд.
> Эта утилитка представлена как образец выводящий хэлоуворлд.Странная версия, однако.
truss -fc /bin/echo hello
hello
syscall seconds calls errors
cap_enter 0.000011729 1 0
cap_ioctls_limit 0.000029684 3 0
__sysctl 0.000024730 2 0
issetugid 0.000026926 2 0
writev 0.000041989 1 0
sysarch 0.000009844 1 0
sigprocmask 0.000154586 14 0
readlink 0.000021708 1 1
...
close 0.000061911 5 0
cap_rights_limit 0.000036024 3 0
cap_fcntls_limit 0.000029448 3 0
------------- ------- -------
0.001061477 74 1
почти в 2 раза меньше сисколов, несмотря на обертку в капсикум.
assembler - не язык программирования. Это транслятор кода. Вы ведь не пишете на компиляторе? Правильно говорить "язык ассемблера". Традиционная ошибка русскоговорящих.
Не занудствуй.И вообще - javac это транслятор, компилятор и/или линковщик? Особенно учитывая, что выходной байткод будет интерпретировать, транслироваться и/или компилироваться в зависимости от фазы луны и настроения jit?
Ты же не пишешь на языке программирования, а печатаешь? Хотя возможно с таким синдромом граммар-наци у тебя и есть парочка скриптов, накарябанных на бересте...
Пых неплох
Кто хочет глянуть на реализацию хелловорлда на 441(четырехста сорока одном!) языке программирования - велкам на розеттукод: https://rosettacode.org/wiki/Hello_world/Text
> Кто хочет глянуть на реализацию хелловорлда на 441(четырехста сорока одном!) языке программирования
> - велкам на розеттукод: https://rosettacode.org/wiki/Hello_world/TextТы открыл для себя Розеттский Камень, надо же! :)
Там не только хелловорлды, но много всякой разной твари, в том числе игрушки.
ЗЫТем не менее, плюсую за комментарий.
А может проблема не в языках и компиляторах, а в том, что x86 просто неадекватна для реализации высокоуровневых ЯП? В 70-х Xerox Alto с тактовой частотой 5,88 МГц и 128-256 Кбайт памяти поддерживал весьма продвинутую мультимедийную ОС с оконным интерфейсом и интерактивной средой разработки, которая была написана на объектно-ориентированном языке с поздним связыванием и динамической типизацией (Smalltalk, кто не слишком представляет, что это за язык, представьте себе ОС полностью на Ruby). Здесь можно почитать, как это все разрабатывалось (и про аппаратную архитектуру): http://worrydream.com/EarlyHistoryOfSmalltalk/
> А может проблема не в языках и компиляторах, а в том, что
> x86 просто неадекватна для реализации высокоуровневых ЯП? В 70-х Xerox
> Alto с тактовой частотой 5,88 МГц и 128-256 Кбайт памяти поддерживал
> весьма продвинутую мультимедийную ОС с оконным интерфейсом и интерактивной средой разработки,
> которая была написана на объектно-ориентированном языке с поздним связыванием и динамической
> типизацией (Smalltalk, кто не слишком представляет, что это за язык, представьте
> себе ОС полностью на Ruby). Здесь можно почитать, как это
> все разрабатывалось (и про аппаратную архитектуру): http://worrydream.com/EarlyHistoryOfSmalltalk/По большому счёту, x86 — это только «внешняя» система команд. А как оно внутри там устроено, никто из присутствующих, скорее всего, не знает. Скорее всего, внутри современных x86-процессоров от x86 и следа не осталось.
То, что вы в своем детском саду не знаете, еще не значит что никто не знает.
Почитайте, хотя бы, мануалы интела - можете погуглить по страшным словам "микрооперация", "реордеринг", "бренч предикшн", "конвеер", "переименование регистров", "лейтенси".Другое дело, что весь этот конвеер настолько сложен, что все сложнее хелловорлда в голове уже не уместится.
> То, что вы в своем детском саду не знаете, еще не значит
> что никто не знает.
> Почитайте, хотя бы, мануалы интела - можете погуглить по страшным словам "микрооперация",
> "реордеринг", "бренч предикшн", "конвеер", "переименование регистров", "лейтенси".А ты, я гляжу, прямо знаток по всем вопросам. И слова какие умные знаешь, молодец. Ну так расскажи всем: есть внутри интеловских процессоров x86 или нету?
Есть интеловский манул https://www.intel.com/content/dam/www/public/us/en/documents...
> Есть интеловский манул https://www.intel.com/content/dam/www/public/us/en/documents...У меня на диске вся пачка этих мануалов, а ещё несколько ревизий документации AMD. На какой странице какого тома написано про место, которое x86 занимает в современном процессоре?
Ой, а что это у нас там чорненькое белеется в чулане? Это же «80386 Hardware Reference Manual» (1986)! Пока ты ищешь нужную страницу в современных мануалах, я в этой книжке посмотрю.
Может в этом то все и дело что создать что-то действительно разухабистое на языке с динамической типизацией достаточно трудно. А работало быстро потому что ничего сложно и не делали. Да и вообще этот Xerox Alto это попытка внедрить разработки Дугласа Энгельбарта в жизнь. https://www.youtube.com/watch?v=yJDv-zdhzMY и как все знают неудачная.
Здесь Кэй демонстрирует ту систему из 70-х в эмуляторе, суди сами: https://youtu.be/AnrlSqtpOkw?t=2m37s
Мультимедийность-то ты там где нашёл?
Спасибо господину Джеффу Мэррисону, теперь я знаю на чём надо писать программу, которая выводит строку "hello".
Что сразу бросилось в глаза, у него второй питон а не третий, также не указаны версии интерпретаторов и компиляторов.
> Что сразу бросилось в глаза, у него второй питон а не третий,
> также не указаны версии интерпретаторов и компиляторов.
truss -fc python3.6 -c "print('hello')"
hello
syscall seconds calls errors
getgid 0.000009173 1 0
getegid 0.000009092 1 0
getuid 0.000009299 1 0
geteuid 0.000009966 1 0
...
dup 0.000031753 3 0
close 0.000591410 46 0
_umtx_op 0.000010842 1 0
------------- ------- -------
0.011674676 740 40truss -fc python3.5 -c "print('hello')"
hello
syscall seconds calls errors
getgid 0.000008866 1 0
getegid 0.000008899 1 0
getuid 0.000009029 1 0
...
fcntl 0.000010414 1 0
dup 0.000035829 3 0
close 0.000635601 48 0
_umtx_op 0.000011185 1 0
------------- ------- -------
0.018257540 781 40truss -fc python2.7 -c "print('hello')"
hello
syscall seconds calls errors
getgid 0.000008682 1 0
...
close 0.000917541 67 0
_umtx_op 0.000011242 1 0
------------- ------- -------
0.022091739 912 206
truss -fc micropython -c "print('hello')" #1.5.1
hello
syscall seconds calls errors
__sysctl 0.000025145 2 0
issetugid 0.000026012 2 0
write 0.000062763 2 0
sysarch 0.000010063 1 0
...
getdirentries 0.000028398 2 0
fstatfs 0.000012848 1 0
fstat 0.000072624 6 0
close 0.000085231 7 0
------------- ------- -------
0.001466043 100 5
От нас скрывают правду микропитон быстрее Go и Rust. Вот это скандалы, интриги, расследования показать все что скрыто. А казалось бы заурядная новость про какие-то левые тесты.
> От нас скрывают правду микропитон быстрее Go и Rust.А сказать аноним хотел что? Или в пальцах чесалось, аж мочи терпеть не было?
Вопрос выше был о версиях питона, а прикол тут в том, что у 2.7 при старте задействует заметно больше колов.
Кстати да релевантнее запускать уже разобраный pyc байт код, а не прост текст еще не разобранный. python -m compileall
Так цель была показать что скрипты это фу и все должны срочно начинать писать на ассемблере (ни в коем случае не на си).
> Кстати да релевантнее запускать уже разобраный pyc байт код, а не прост
> текст еще не разобранный. python -m compileallЗапускай - так и быть, разрешаю! Правда, сисколов будет ровно столько же, но …
Лол спасибо. Только ты очередной раз показал своё незнание. Сисколов будет не столько же. Ты бы вот чисто для разнообразие сам бы проверил, но нет это же надо голову включить средний анонн на такое не способен.Итак python 3.6.9
strace -fc python3 -c "print('hello')"
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
15.91 0.000867 5 175 39 stat
...
0.00 0.000000 0 1 getegid
------ ----------- ----------- --------- --------- ----------------
100.00 0.005449 730 62 totalstrace -fc python3 ./hello.py
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
23.89 0.000436 11 38 mmap
...
0.00 0.000000 0 1 getegid
------ ----------- ----------- --------- --------- ----------------
100.00 0.001825 753 65 totalstrace -fc python3 ./__pycache__/hello.cpython-3.6.pyc
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
19.24 0.000484 13 38 mmap
...
0.00 0.000000 0 1 getrandom
------ ----------- ----------- --------- --------- ----------------
100.00 0.002515 758 64 totalРазница в 5 сисколов между pyc и py. А между вызовом команды из стоки и из файла целых 23 сискола разница. Но ты продолжай жить в своём мирке с пони где количество сисколов постоянно.
> Лол спасибо. Только ты очередной раз показал своё незнание. Сисколов будет не
> столько же. Ты бы вот чисто для разнообразие сам бы проверил,
> но нет это же надо голову включить средний анонн на такое не способен.Плохая из тебя ванга, аноним. Ну и "знаток" похоже тоже - неважнецкий:
truss -fc python2.7 hello.py
hello
syscall seconds calls errors
getgid 0.000008887 1 0
getegid 0.000008694 1 0
...
close 0.000943776 69 0
_umtx_op 0.000011025 1 0
__getcwd 0.000016785 1 0
------------- ------- -------
0.014583719 934 208python2.7 -m compileall hello.py
Compiling hello.py ...truss -fc python2.7 hello.pyc
hello
syscall seconds calls errors
getgid 0.000009410 1 0
getegid 0.000009106 1 0
...
close 0.000885475 70 0
_umtx_op 0.000011768 1 0
__getcwd 0.000015304 1 0
------------- ------- -------
0.014424597 934 208python2.7 -m compileall -c "print 'hello'"
option -c not recognizedpython2.7 -c "print 'hello'" -m compileall
hello
# и что дальше?> Разница в 5 сисколов между pyc и py.
Ну, ты понял. Умный и уверенный вид - не всегда помогают.
> А между вызовом команды из стоки и из файла целых 23 сискола разница.
Это ты классно придумал приписать мне.
Еще бы показал, как анонимые гуру компиляют в байткод и запускают вызов из ком. строки. И что важнее - как (и зачем) потом результаты сравнивают. Чтение файла - это тоже сисколы, если ты не знал.> Но ты продолжай жить в своём мирке с пони где количество сисколов постоянно.
Главное, не забывай с умным видом надувать щечки и приписывать мне посторонние высказывания, а то же с опровержениями реальных и лажанутся можешь ;)
Ууу! Раст затащил ууу!!!!
На дно.
del
> delC#: syscalls: 117 taskclock
только тут 'hello' могло так взбудоражить умы и быть поводом для сра4eй )
В Haskell автор не смог? That's a shame.
> В Haskell автор не смог? That's a shame.Ну так смоги ты и выложи результаты, например?