Комментарии 181
>>программка “Hello World!” компилируется в файл 31 байт.
непонятное достижение. Если в .com файл компилировать под тот же DOS, то выйдет не больше
непонятное достижение. Если в .com файл компилировать под тот же DOS, то выйдет не больше
Меньше.
мув адрес строки куда-то
мов ах, что-то
инт 21ш или типа того ; печать строки
мов чего-то
инт чего-то ; выход
строка
а если инт 21ш нету? ;)
НЛО прилетело и опубликовало эту надпись здесь
Программирование в 1С накладывает свой отпечаток…
Никогда в жизни даже не видел 1С.
Теперь не отвертитесь
Если (ВидДок="РасходнаяКредит") Тогда
Если Конт.ПризнакНакладной=Перечисление.ПризнРасхНакл.Продажа Тогда
Операция="Продажа";
ИначеЕсли Конт.ПризнакНакладной=Перечисление.ПризнРасхНакл.ВозвратПоставщику Тогда
Операция="ВозвратПоставщику";
КонецЕсли;
ИначеЕсли (ВидДок="ПриходнаяКредит") Тогда
Если (Конт.ПризнакНакладной=Перечисление.ПризнПрихНакл.Закупка)
ИЛИ (Конт.ПризнакНакладной=Перечисление.ПризнПрихНакл.Импорт) Тогда
Операция="Закупка";
ИначеЕсли Конт.ПризнакНакладной=Перечисление.ПризнПрихНакл.ВозвратОтПокупателя Тогда
Операция="ВозвратОтПокупателя";
КонецЕсли;
КонецЕсли;
обоже. это же ад!!! какой сон разума породил это чудовище?? ===8-o
Я сильно подозреваю, что если бы писать можно было бы только латиницей, то мы наблюдали бы ровно то же самое, но уже в транслите… Так что пусть хоть так
Вы подумайте, как выглядят программы для англоязычного программера. Например, BASIC.
Когда такое уведел впервые в 1С Конфигураторе (это у них так среда разработки называется) решил для себя, что постараюсь сделать все, чтобы не пришлось писать на таком, хотя бы даже «Привет мир». Какое-то внутреннее отторжение нахлынуло. Правда ребята 1С кодеры успокаивали тем, что можно переключаться на англ.
Как правильно заметили тут рядом, на английском это было бы ужаснее, потому что англ. бухгалтерские термины не совпадают, следовательно, это был бы транслит.
Основная проблема даже не в этом, а в том, что если не писать свою конфигурацию с нуля, а пилить существующую, то получится дикая мешанина русского и английского.
Вместо того чтобы прививать новым разработчикам необходимость и желание развивать английский, решили пойти по пути быстрее поймут больше денег получим. 1С то ведь софт на рынок толкает, а дальше следующая ступенька (франчайзи) подключается. Зачем им голову морочить заморскими познаниями…
Это ещё ладно. Оцените следующее:
Только сегодня догнал тонкий юмор суровых девелов 1С.
В файлах обмена кодировка файла указана в этом файле строкой:
Кодировка=DOS
или
Кодироовка=Windows
Зато под 1С индусы поди не пишут.
Этот код выглядит как код FoxPro переведенные с помощью Magic Goody…
Впечатляет, первый раз такое вижу.
когда-то, в период юношеского максимализма, я мечтал о том, как русский язык станет главным в мире, и что именно он будет лежать в основе языков программирования.
Если бы мне тогда показали это, я бы гораздо раньше понял бредовость всей этой затеи.
Если бы мне тогда показали это, я бы гораздо раньше понял бредовость всей этой затеи.
Вы счастливый человек. И я вам завидую. Совсем немного, по белому, но завидую.
отчепяток...)
Я всё равно инструкции не помню, в прошлый раз писал на асме под DOS около 13 лет назад. Если бы написал латиницей, впаяли бы 10 минусов за ошибки в коде :)
habrahabr.ru/blogs/crazydev/72627/
цикл_пока откроем 1 закроем
начнемс
ошибка:
очистить_экран откроем закроем закончим_однако
обновить_однако откроем закроем закончим_однако
если откроем ход равно ложь закроем
начнемс
mov ah, 09h
mov dx, string_addr
int 21h
ret
mov dx, string_addr
int 21h
ret
тогда уж lea dx, msg или mov dx, offset msg :)
и да, выход по 4C тоже
и да, выход по 4C тоже
Код вполне может быть на fasm или nasm, где offset нет. BareMetal, к слову, использует nasm. lea вообще имеет смысл только когда mov'ом обойтись нельзя. Выход по ret из COM-программ совершенно законен, 4C — это расширенный вариант, в нагрузку заполняющий код завершения программы.
В 64-бит режиме — думаю больше :)
Еще одна 64-битная ОС, написанная на ассемблере — http://www.menuetos.net/.
>Цель этого проекта — избавиться от неэффективного машинного кода, который генерируют компиляторы высокоуровневых языков вроде C/C++
Спасибо, посмеялся :)
Спасибо, посмеялся :)
Написать вручную на асме — и код будет более быстрый, если делать все с умом. Другое дело, что это непомерные усилия, которые в 99% случаев не стоят того. Но в принципе они правы, компиляторы не идеальны.
Уже давно современные C++ компиляторы генерируют более эффективный код, чем это может сделать человек. Точно также, как калькуляторы давно умножают быстрее и точнее человека. Просто потому, что человек не может удержать в голове огромнейшее количество мелких деталей, которые влияют на производительность связанных с архитектурой процессора, шины данных, структурой программы, и пр. Далее, компиляторы делают очень хитрые оптимизации, которые крайне тяжело делать вручную, такие как размотки циклов.
Написать-то быстрее можно, особенно используя SSE и MMX, просто есть еще одна проблема: в процессорах полно ошибок («неточностей»), когда очень редкий набор данных и команд в каком-то процессоре работает не так, как ожидается. Учесть все их человеку невозможно, а тестировать программу на всех существующих процессорах крайне проблематично.
Ну у этой штуки нету такой проблемы. Основной юскейс — это сделать тот же вычислительный кластер на заданном железе. Чтобы софт работал у миллионов различных пользователей на всём зоопарке железа — такого не нужно.
Практика показывает, что компилятор C++ лучше человека справляется с использованием MMX и SSE.
Когда компилятор знает, как векторизовать алгоритм, он справляется чуть-чуть лучше. Но есть один нюанс: нетривальные алгоритмы они пока не умеют векторизовывать.
Проще в этом случае помочь компилятору разобраться.
Внушить что-то компилятору не проще, особенно если их 3 штуки для сборки под разные платформы, да ещё пара из них зафиксированы SDK и никуда не прыгнешь. Вот на интринсиках написать — вариант.
НЛО прилетело и опубликовало эту надпись здесь
Решается ассемблерной вставкой на 5-10 строчек или intrinsics.
Писать ВСЮ программу на asm — бессмысленное упражнение. Во-первых благодаря эмпирическому правилу 90-10 (90% времени расходуется в 10% кода). Во-вторых, программист на ассемблере все равно не будет тратить свое время на тчащетельную ручную оптимизацию каждого блока кода, так что большая часть программы все равно будет написана не лучше, чем это сделает компилятор.
Писать ВСЮ программу на asm — бессмысленное упражнение. Во-первых благодаря эмпирическому правилу 90-10 (90% времени расходуется в 10% кода). Во-вторых, программист на ассемблере все равно не будет тратить свое время на тчащетельную ручную оптимизацию каждого блока кода, так что большая часть программы все равно будет написана не лучше, чем это сделает компилятор.
>> Уже давно современные C++ компиляторы генерируют более эффективный код, чем это может сделать человек.
Забудьте эти глупости, которыми пичкают в университетах.
Чтобы код получался быстрым, его нужно долго и мучительно выпиливать драчёвым напильником.
В реальности компиляторы не могут сделать и 10% от того что может вменяемый программист.
Посмотрите MKL какой-нибудь и сравните с голой С-версией.
Компилятор не изменит формат данных в памяти на более оптимальный, не изменит порядок обхода данных или алгоритм в зависимости от микроархитектурных деталей или наличия SIMD.
Польза от компилятора в том, что он превращает всю программу во вменяемый код под таргет-платформу (особенно полезно если их несколько). Человек фокусируется на хот-спотах.
Можно попытаться писать быстрый код — профайлить и пытаться выжать из компилятора что-то вменяемое. Но часто на это уходит больше времени чем на асм-версию.
>> Далее, компиляторы делают очень хитрые оптимизации, которые крайне тяжело делать вручную, такие как размотки циклов.
Ну не смешите. Нет ничего сложного в размотке циклов =)
При оптимизации под in-order процессоры, мало какой компилятор может делать modulo sheduling,
а это примитивнейшая техника, которая позволяет ускорить выполнение циклов в разы. Например, на ЗЫ3 есть специальный ассемблер, который помогает делать modulo sheduling и переупорядочивает инструкции для эффективной загрузки пайплайна — снимая бОльшую часть груза с плеч программиста.
Забудьте эти глупости, которыми пичкают в университетах.
Чтобы код получался быстрым, его нужно долго и мучительно выпиливать драчёвым напильником.
В реальности компиляторы не могут сделать и 10% от того что может вменяемый программист.
Посмотрите MKL какой-нибудь и сравните с голой С-версией.
Компилятор не изменит формат данных в памяти на более оптимальный, не изменит порядок обхода данных или алгоритм в зависимости от микроархитектурных деталей или наличия SIMD.
Польза от компилятора в том, что он превращает всю программу во вменяемый код под таргет-платформу (особенно полезно если их несколько). Человек фокусируется на хот-спотах.
Можно попытаться писать быстрый код — профайлить и пытаться выжать из компилятора что-то вменяемое. Но часто на это уходит больше времени чем на асм-версию.
>> Далее, компиляторы делают очень хитрые оптимизации, которые крайне тяжело делать вручную, такие как размотки циклов.
Ну не смешите. Нет ничего сложного в размотке циклов =)
При оптимизации под in-order процессоры, мало какой компилятор может делать modulo sheduling,
а это примитивнейшая техника, которая позволяет ускорить выполнение циклов в разы. Например, на ЗЫ3 есть специальный ассемблер, который помогает делать modulo sheduling и переупорядочивает инструкции для эффективной загрузки пайплайна — снимая бОльшую часть груза с плеч программиста.
> Посмотрите MKL какой-нибудь и сравните с голой С-версией.
Вы сравнивали? Я вот на своих задачах сравнил. Пока что моя C-версия выигрывает. Без SIMD.
Вы сравнивали? Я вот на своих задачах сравнил. Пока что моя C-версия выигрывает. Без SIMD.
Код в студию.
Кстати МКЛь не пишут на ассемблере.
Кстати МКЛь не пишут на ассемблере.
pastebin.com/NpffQwdy
Это аналог mkl_dcsrsymv. На матрице n=500K, nnz=7.5M, CPU i5-750 мой вариант 56 мс, MKL 63 мс. Причём тут ещё префетч не оптимально выставлен (чтобы было оптимально, нужно развернуть цикл на 8 шагов — 1 префетч на 8 итераций, так как длина строки кеша 64 байта). Но я этого делать не стал, так как вопрос был в том, насколько можно обогнать MKL тупым кодом.
Это аналог mkl_dcsrsymv. На матрице n=500K, nnz=7.5M, CPU i5-750 мой вариант 56 мс, MKL 63 мс. Причём тут ещё префетч не оптимально выставлен (чтобы было оптимально, нужно развернуть цикл на 8 шагов — 1 префетч на 8 итераций, так как длина строки кеша 64 байта). Но я этого делать не стал, так как вопрос был в том, насколько можно обогнать MKL тупым кодом.
Разговор интересный, возьму пока на анализ.
С этой функцией не сталкивался, возможно что она вообще не оптимизирована руками — т.е. собрали интеловским компилятором и все. А компилятор на х86 префетчи не вставляет (если очень не попросить).
Но тривиальный код с интринсиками — вы перегнули палку =)
Если у вас это хотспот — можно засабмитить баг и получить пофикшенный мкль.
С этой функцией не сталкивался, возможно что она вообще не оптимизирована руками — т.е. собрали интеловским компилятором и все. А компилятор на х86 префетчи не вставляет (если очень не попросить).
Но тривиальный код с интринсиками — вы перегнули палку =)
Если у вас это хотспот — можно засабмитить баг и получить пофикшенный мкль.
сидим, отмечаем на бамашке использованные регистры, на стене пишем в столбик оффсеты на глобальные переменные.
Эх, прям молодость вспомнил
Эх, прям молодость вспомнил
Увы, я не программист, но на Speccy набирал простенькие BASIC-программки, набирая их на слух — щелчок клавиши был слышен, а видео на тот момент подключить было банально некуда.
этот ваш шедулинг по зависимым данным — это почти тривиальная и хорошо изученная вещь, которая была реализована во многих компиляторах. В современных компиляторах ей почти не уделяется внимание, потому что на x64 шедулинг нужен только для помощи распределителю регистров, а эти самые
> in-order процессоры
фактически мертвы.
> in-order процессоры
фактически мертвы.
>>это почти тривиальная и хорошо изученная вещь, которая была реализована во многих компиляторах
А потом, что? Вдруг пропала?
FYI Ни один консольный компилятор не умеет такого (VC/GCC/etc)
>> фактически мертвы.
Слухи о смерти сильно преувеличены.
Консоли, 95% мобильных устройств, сервера на Sparc, Power6.
На самом деле in-order на порядки больше чем OoO процессоров.
В каждом современном PC есть несколько ARM ядер.
А остальные оптимизации остались практически на уровне 90х.
А потом, что? Вдруг пропала?
FYI Ни один консольный компилятор не умеет такого (VC/GCC/etc)
>> фактически мертвы.
Слухи о смерти сильно преувеличены.
Консоли, 95% мобильных устройств, сервера на Sparc, Power6.
На самом деле in-order на порядки больше чем OoO процессоров.
В каждом современном PC есть несколько ARM ядер.
А остальные оптимизации остались практически на уровне 90х.
Шедулинг для х86 неактуален — поэтому и не делают.
Это не Итаниум.
>А остальные оптимизации остались практически на уровне 90х.
Зуб дадите?
Это не Итаниум.
>А остальные оптимизации остались практически на уровне 90х.
Зуб дадите?
> В каждом современном PC есть несколько ARM ядер.
Не расскажите ли, где они там? Или может быть подскажите несколько ключевых слов…
Не расскажите ли, где они там? Или может быть подскажите несколько ключевых слов…
> А потом, что? Вдруг пропала?
шедулинг живёт почти в каждом более-менее старом бэкенде, но обычно никак не тестируется и не дорабатывается, и не факт, что вообще работает, ибо для x86/x64 не актуален, а под другие мало кто тестирует.
> FYI Ни один консольный компилятор не умеет такого (VC/GCC/etc)
Вам именно modulo scheduling? «gcc -fmodulo-sched». Разработан, кстати, похоже IBMом в двухтысячных, опять же, потому что никому нафиг не сдался.
> сервера на Sparc
мертво
> Power6
почти мертво
> Консоли, 95% мобильных устройств
На самом деле единственный, кто тут может представлять интерес, это ARM. IBM с ppc в последние годы пытается вырваться за счёт консолей, но это мало что значит. Раньше playstation была на MIPS, но это не помешало MIPS умереть, вместе с SGI и SiCortex.
Всякие mips и ppc уходят в прошлое, суперкомпьютеры строятся на интелах и вообще видеокартах, с точки зрения высокопроизводительных вычислений мало что представляет интерес, кроме x64.
шедулинг живёт почти в каждом более-менее старом бэкенде, но обычно никак не тестируется и не дорабатывается, и не факт, что вообще работает, ибо для x86/x64 не актуален, а под другие мало кто тестирует.
> FYI Ни один консольный компилятор не умеет такого (VC/GCC/etc)
Вам именно modulo scheduling? «gcc -fmodulo-sched». Разработан, кстати, похоже IBMом в двухтысячных, опять же, потому что никому нафиг не сдался.
> сервера на Sparc
мертво
> Power6
почти мертво
> Консоли, 95% мобильных устройств
На самом деле единственный, кто тут может представлять интерес, это ARM. IBM с ppc в последние годы пытается вырваться за счёт консолей, но это мало что значит. Раньше playstation была на MIPS, но это не помешало MIPS умереть, вместе с SGI и SiCortex.
Всякие mips и ppc уходят в прошлое, суперкомпьютеры строятся на интелах и вообще видеокартах, с точки зрения высокопроизводительных вычислений мало что представляет интерес, кроме x64.
ы…
MIPS — 90% роутеров малого и среднего звена. Хотите сказать, там производительность непринципиальна?
ppc, sparc… ну, наверно я в пьяном бреду ставил и ставлю десятки промышленных решений (в частности, Documentum) именно на данные архитектуры. И доля интеловых процов в подобных решениях существенно ниже, чем sparc и ppc.
MIPS — 90% роутеров малого и среднего звена. Хотите сказать, там производительность непринципиальна?
ppc, sparc… ну, наверно я в пьяном бреду ставил и ставлю десятки промышленных решений (в частности, Documentum) именно на данные архитектуры. И доля интеловых процов в подобных решениях существенно ниже, чем sparc и ppc.
Точно, а еще в холодильники АРМ ставят.
Только вы к чему это?
Только вы к чему это?
> MIPS — 90% роутеров малого и среднего звена. Хотите сказать, там производительность непринципиальна?
Непринципиальна. Много вы роутеров знаете на mips64? Попробуйте найти компилятор или собрать кросс-компилятор gcc для mips64el. Будете «приятно» удивлены.
> ppc, sparc… ну, наверно я в пьяном бреду ставил и ставлю…
это всё пережитки прошлого, оставшиеся по инерции у корпоративных монстров
Непринципиальна. Много вы роутеров знаете на mips64? Попробуйте найти компилятор или собрать кросс-компилятор gcc для mips64el. Будете «приятно» удивлены.
> ppc, sparc… ну, наверно я в пьяном бреду ставил и ставлю…
это всё пережитки прошлого, оставшиеся по инерции у корпоративных монстров
>> шедулинг живёт почти в каждом более-менее старом бэкенде
Я говорил конкретно о способе оптимизации циклов
>> ибо для x86/x64 не актуален, а под другие мало кто тестирует.
Вы наверное разработчик gcc или icc?
instruction scheduling актуален всегда. Под x86-OoO процессоры есть много нюансов расположения команд. В т.ч. переупорядочивания обращений памяти несмотря на наличие в интеловских процах спекулятивного load-а.
Вобщем тут огромный простор для микрооптимизаций.
Опять же вы забываете про Atom.
>>Вам именно modulo scheduling? «gcc -fmodulo-sched»
Если бы он ещё и работал, было бы совсем хорошо.
В важных местах я делаю MS руками. Тупому оптимизатору GCC
веры нет (что подкрепляется дизассемблером и профайлером).
Хотя в простых местах можно поэкспериментировать.
Давненько я её не включал =)
>>потому что никому нафиг не сдался.
Ну да, увеличение производительности в разы никому не нужно.
Кроме бедолаг типа меня.
Логика из серии «мне не надо — значит и другим не надо» провальна изначально.
Рынок х86 в количественном соотношении относительно небольшой.
Одних только ARM-ов в год выпускается в 20 раз больше.
>> сервера на Sparc
>мертво
>> Power6
>почти мертво
Ловко вы ярлыки навешиваете
IBM то чай с пауеров и SystemZ наваривает некисло
>> не помешало MIPS умереть
Опять же рано хороните. В китае свои MIPS процы разрабатываются под господдежкой
>>это всё пережитки прошлого, оставшиеся по инерции у корпоративных монстров
Ага. Всякие там RAS features и прочее — пустой звук.
Наш выбор — атлоны с местного овощного рынка!
Слышь? Пакупай! Кароший працессар. Будит работать как пэрсик. Мамой клянусь
Я говорил конкретно о способе оптимизации циклов
>> ибо для x86/x64 не актуален, а под другие мало кто тестирует.
Вы наверное разработчик gcc или icc?
instruction scheduling актуален всегда. Под x86-OoO процессоры есть много нюансов расположения команд. В т.ч. переупорядочивания обращений памяти несмотря на наличие в интеловских процах спекулятивного load-а.
Вобщем тут огромный простор для микрооптимизаций.
Опять же вы забываете про Atom.
>>Вам именно modulo scheduling? «gcc -fmodulo-sched»
Если бы он ещё и работал, было бы совсем хорошо.
В важных местах я делаю MS руками. Тупому оптимизатору GCC
веры нет (что подкрепляется дизассемблером и профайлером).
Хотя в простых местах можно поэкспериментировать.
Давненько я её не включал =)
>>потому что никому нафиг не сдался.
Ну да, увеличение производительности в разы никому не нужно.
Кроме бедолаг типа меня.
Логика из серии «мне не надо — значит и другим не надо» провальна изначально.
Рынок х86 в количественном соотношении относительно небольшой.
Одних только ARM-ов в год выпускается в 20 раз больше.
>> сервера на Sparc
>мертво
>> Power6
>почти мертво
Ловко вы ярлыки навешиваете
IBM то чай с пауеров и SystemZ наваривает некисло
>> не помешало MIPS умереть
Опять же рано хороните. В китае свои MIPS процы разрабатываются под господдежкой
>>это всё пережитки прошлого, оставшиеся по инерции у корпоративных монстров
Ага. Всякие там RAS features и прочее — пустой звук.
Наш выбор — атлоны с местного овощного рынка!
Слышь? Пакупай! Кароший працессар. Будит работать как пэрсик. Мамой клянусь
> instruction scheduling актуален всегда. Под x86-OoO процессоры есть много нюансов расположения команд. В т.ч. переупорядочивания обращений памяти несмотря на наличие в интеловских процах спекулятивного load-а.
Шедулинг с точки зрения зависимости по данным никого не интересует в условиях:
1) нехватки регистров
2) двухадресных инструкций
3) наличия сложных режимов адресации
4) наличия инструкций, использующих фиксированные регистры (сдвиги, cmpxchg, mul, etc)
Любые перестановки инструкций будут делаться исходя из соображений минимизации количества используемых регистров. И в случае x86 это зависит не только от области жизни переменных, потому что в зависимости от порядка инструкций могут появляться возможности для:
1) использования более «удобного» режима адресации
2) уменьшения количества пересылок (или даже числа используемых регистров, а значит и возможных чтений/записей в память), которые требуются из-за двухадресности инструкций
3) уменьшения количества пересылок и дополнительных регистров (и чтений/записей в память) из-за инструкций, которым необходим один и тот же фиксированный регистр.
Кому вообще нужна мифическая возможность поэкспериментировать с влиянием переупорядочивания обращений к памяти на OoO процессор, если это переупорядочивание может легко привести к добавлению дополнительных операций с памятью? Можно конечно делать переупорядочивание уже после того, как код сгенерирован, только вряд ли там что-либо получится сильно попереставлять.
> Если бы он ещё и работал, было бы совсем хорошо.
Так он не нужен похоже никому, потому никто об этом и не заботится.
> Логика из серии «мне не надо — значит и другим не надо» провальна изначально.
А я такой логикой не пользуюсь. Я просто смотрю на существующие компиляторы и вижу, что бэкенды и оптимизации для архитектур, отличных от x86, плохо поддерживаются, мало разрабатываются, и генерируют поганый код. Тут может быть два варианта: вселенский заговор, или это не интересует почти никого.
> IBM то чай с пауеров и SystemZ наваривает некисло
SGI на своих MIPSах и SGI OS тоже наваривали…
Шедулинг с точки зрения зависимости по данным никого не интересует в условиях:
1) нехватки регистров
2) двухадресных инструкций
3) наличия сложных режимов адресации
4) наличия инструкций, использующих фиксированные регистры (сдвиги, cmpxchg, mul, etc)
Любые перестановки инструкций будут делаться исходя из соображений минимизации количества используемых регистров. И в случае x86 это зависит не только от области жизни переменных, потому что в зависимости от порядка инструкций могут появляться возможности для:
1) использования более «удобного» режима адресации
2) уменьшения количества пересылок (или даже числа используемых регистров, а значит и возможных чтений/записей в память), которые требуются из-за двухадресности инструкций
3) уменьшения количества пересылок и дополнительных регистров (и чтений/записей в память) из-за инструкций, которым необходим один и тот же фиксированный регистр.
Кому вообще нужна мифическая возможность поэкспериментировать с влиянием переупорядочивания обращений к памяти на OoO процессор, если это переупорядочивание может легко привести к добавлению дополнительных операций с памятью? Можно конечно делать переупорядочивание уже после того, как код сгенерирован, только вряд ли там что-либо получится сильно попереставлять.
> Если бы он ещё и работал, было бы совсем хорошо.
Так он не нужен похоже никому, потому никто об этом и не заботится.
> Логика из серии «мне не надо — значит и другим не надо» провальна изначально.
А я такой логикой не пользуюсь. Я просто смотрю на существующие компиляторы и вижу, что бэкенды и оптимизации для архитектур, отличных от x86, плохо поддерживаются, мало разрабатываются, и генерируют поганый код. Тут может быть два варианта: вселенский заговор, или это не интересует почти никого.
> IBM то чай с пауеров и SystemZ наваривает некисло
SGI на своих MIPSах и SGI OS тоже наваривали…
>> Кому вообще нужна мифическая возможность поэкспериментировать с влиянием >> переупорядочивания обращений к памяти на OoO процессор
Тем кто заинтерисован в производительности.
en.wikipedia.org/wiki/Memory_disambiguation
Тот же AMD k8-k10 не умеет такого, что его сильно тормозит
>Так он не нужен похоже никому, потому никто об этом и не заботится.
Не говорите за всех. Мне нужен и ещё куче инженеров, работающих с высокопроизводительным кодом.
>> Я просто смотрю на существующие компиляторы и вижу, что бэкенды и оптимизации для архитектур, отличных от x86,
Мир компиляторов не ограничивается GCC, VC.
Тем кто заинтерисован в производительности.
en.wikipedia.org/wiki/Memory_disambiguation
Тот же AMD k8-k10 не умеет такого, что его сильно тормозит
>Так он не нужен похоже никому, потому никто об этом и не заботится.
Не говорите за всех. Мне нужен и ещё куче инженеров, работающих с высокопроизводительным кодом.
>> Я просто смотрю на существующие компиляторы и вижу, что бэкенды и оптимизации для архитектур, отличных от x86,
Мир компиляторов не ограничивается GCC, VC.
> Тем кто заинтерисован в производительности.
Тем, кто заинтересован в производительности, нужна в первую очередь минимизация количества операций с памятью. Очень удобно наверное выдернуть из трёх абзацев одну фразу и обсуждать её.
> Мир компиляторов не ограничивается GCC, VC.
Ну так покажите нам крутые компиляторы, которые рожают высокопроизводительный код для ARM, MIPS, PPC
Тем, кто заинтересован в производительности, нужна в первую очередь минимизация количества операций с памятью. Очень удобно наверное выдернуть из трёх абзацев одну фразу и обсуждать её.
> Мир компиляторов не ограничивается GCC, VC.
Ну так покажите нам крутые компиляторы, которые рожают высокопроизводительный код для ARM, MIPS, PPC
НЛО прилетело и опубликовало эту надпись здесь
Тем не менее, библиотека GMP — которую сами по себе используют компиляторы и на которой основана MPFR, которую в свою очередь использует куча калькуляторов www.mpfr.org/#mpfr-sw — для функций нижнего уровня использует ассемблерные версии. Возрастающая сложность поддержки кода для многих архитектур вполне оправдывается возрастающей скоростью.
Среднестатистический код человека-ассемблерщика действительно скорее всего проиграет по скорости коду, который генерирует хороший компилятор с максимальной оптимизацией. Но делать отсюда вывод, что человек в принципе не может, вылизывая небольшой участок, соревноваться с компилятором, несколько странно — как минимум потому, что человек может написать любой код, в том числе идентичный сгенерированному компилятором, а компилятор может сгенерировать не любой код.
Среднестатистический код человека-ассемблерщика действительно скорее всего проиграет по скорости коду, который генерирует хороший компилятор с максимальной оптимизацией. Но делать отсюда вывод, что человек в принципе не может, вылизывая небольшой участок, соревноваться с компилятором, несколько странно — как минимум потому, что человек может написать любой код, в том числе идентичный сгенерированному компилятором, а компилятор может сгенерировать не любой код.
Сразу вспоминаю случай когда Линус на С написал более быструю имплементацию хеш алгоритма чем чуваки которые ее писали на асм.
Согласен. Я считаю, что хороший программист на ассемблере напишет код лучше, чем сгенерирует хороший компилятор ЯВУ. Но в то же время скорее всего плохой программист на ассемблере напишет код хуже, чем сгенерирует плохой компилятор ЯВУ.
Идея очень здравая, зря Вы так,
единственное, чему нужно уделить большое внимание — тестированию и тщательной отладке.
Писать на асме очень не легко, но и цена велика, если можно добиться в разы большей скорости
единственное, чему нужно уделить большое внимание — тестированию и тщательной отладке.
Писать на асме очень не легко, но и цена велика, если можно добиться в разы большей скорости
У Вас, видимо, есть успешный опыт, как вы однажды написали на ассемблере и в разы обогнали ICC? Ну или хотя бы MS C++?
Поделитесь!
А то я уже многих таких смелых видел :)
Поделитесь!
А то я уже многих таких смелых видел :)
Я писал код для AVR контроллеров как на асме, так и на gcc.
Разница ощутима не только в размере, но и в производительности.
Поэтому поддерживаю данную разработку, тем более
что они специализировано занимаются асмом в экспериментальных разработках в том числе.
Молодцы, что сказать :)!
Разница ощутима не только в размере, но и в производительности.
Поэтому поддерживаю данную разработку, тем более
Разработчики из канадской компании Return Infinity специализируются на низкоуровневом программировании и экспериментальных разработках
что они специализировано занимаются асмом в экспериментальных разработках в том числе.
Молодцы, что сказать :)!
C SSE успешно обгонял MSC и GCC почти в 4 раза, потому что компиляторы не смогли векторизовать алгоритм. Правда, я использовал интринсики, а не асм — куда читабельнее и портируемо.
Другой пример, который видел в жизни, asm уделал MSC на ARM — за счёт использования инструкций, которые он почему-то не использует.
А насчёт ускорения просто за счёт ассемблерности — не встречалось.
Другой пример, который видел в жизни, asm уделал MSC на ARM — за счёт использования инструкций, которые он почему-то не использует.
А насчёт ускорения просто за счёт ассемблерности — не встречалось.
Например, алгоритм перемножения матриц, скомпилированный исключительно icc работает более чем в 5 раз хуже аналогичного с ассемблерными вставками в нужных местах. Вот пример в одном из моих конкурсов. Там в конце поста таблица результатов. Чисто на icc работает 55 секунд, с ассемблером 11. С некоторыми оптимизациями ещё быстрее. Компиляторы умеют оптимизировать то, что буквально написано, но они не всегда понимают, что это и как сделать код быстрее, вникая в контекст задачи, учитывая тонкости алгоритма.
С другой стороны, весь код писать на ассемблере не всегда хорошо. Долго и трудно.
Так что у каждого подхода свои плюсы. Не надо начинать очередной холивар на пустом месте.
С другой стороны, весь код писать на ассемблере не всегда хорошо. Долго и трудно.
Так что у каждого подхода свои плюсы. Не надо начинать очередной холивар на пустом месте.
Посмотреть бы ещё код без ассемблерных вставок, а то я например попытался восстановить цикл в Sub, и gcc-4.5 сгенерил такой же код, как в ассемблерной вставке.
Если бы код был одинаковым, время работы тоже было бы одинаковым. Но это не так.
Спасибо, кэп. Я и говорю, что нужен код без вставок, и список опций, с которыми всё это собиралось, а то может там с -O1 собирали, кто его знает.
Код Вам уже никто сейчас не найдет. Можете написать свой если хотите проверить. Опции я применял все, что были, ни одна не давала ничего хорошего.
Если в чём-то сомневаетесь, напишите свою программу без ассемблерных вставок (любым способом) и компилируйте любыми ключами. Потом расскажите что получилось. Кое-кто в конкурсе использовал intrinsics, но это уже почти то же, что ассемблер, однако даже от этого пришлось отказаться, так как intrinsics оказался не оптимальным.
Если в чём-то сомневаетесь, напишите свою программу без ассемблерных вставок (любым способом) и компилируйте любыми ключами. Потом расскажите что получилось. Кое-кто в конкурсе использовал intrinsics, но это уже почти то же, что ассемблер, однако даже от этого пришлось отказаться, так как intrinsics оказался не оптимальным.
Целочисленное перемножение? Ну вы и нашли тест…
Во-первых, было предложено привести пример успешного опыта. Во-вторых, чем Вам целые числа не угодили? Они что, не используются? В-третьих, с вещественными числами будет почти то же самое, только разрыв будет меньше. Перемножение в MKL работает на матрице порядка 5000 около 28 секунд (там ассемблер), а ручная версия будет около 100 секунд (раза в два дольше целочисленной). Можете сами проверить, если не верите.
Почитал я ваш тест. Мне больше всего понравилась ваша идея номер один — транспонировать матрицу входящих данных. Отличное решение — но при чем тут компилятор? Думаете он может позволить себе такие фокусы?
Нет не может, но эта оптимизация не имеет отношения к обсуждаемой теме. Речь идёт о том, что компилятор самое быстрое что смог выдавить — только 55 секунд, а ассемблерные вставки, учитывающие особенность задачи (о которой компилятор не знает) обгоняют даже intrinsics.
Еще раз говорю: я просто привёл пример. Попросили привести пример, когда ручной ассемблер в разы обгоняет компилятор. Я привёл, и все.
Еще раз говорю: я просто привёл пример. Попросили привести пример, когда ручной ассемблер в разы обгоняет компилятор. Я привёл, и все.
Вы давайте ставьте одинаковые условия.
Ваши изыски не относятся к компилятором.
Иначе резултьтатом теста будет простой printf() — вы ведь уже знаете правильный ответ?
Компилятор вынужден работать с общими данными — выровненность, возможные ограничения на входные данные — он оперирует ими используя возможности исходящие из стандартов. И ассемблер тут вообщем то непричем — то же можно и на С написать, а прагмами и ключами сделать такой код, который вам нужен — отключая разнообразные ограничения и проверки одну за другой.
А предварительное транспонирование матрицы — это вообще алгоритмическая оптимизация. Это как бы вы победили компилятор собирая на С пузырьковую сортировку, а на асме написать квиксорт.
Ваши изыски не относятся к компилятором.
Иначе резултьтатом теста будет простой printf() — вы ведь уже знаете правильный ответ?
Компилятор вынужден работать с общими данными — выровненность, возможные ограничения на входные данные — он оперирует ими используя возможности исходящие из стандартов. И ассемблер тут вообщем то непричем — то же можно и на С написать, а прагмами и ключами сделать такой код, который вам нужен — отключая разнообразные ограничения и проверки одну за другой.
А предварительное транспонирование матрицы — это вообще алгоритмическая оптимизация. Это как бы вы победили компилятор собирая на С пузырьковую сортировку, а на асме написать квиксорт.
А предварительное транспонирование матрицы — это вообще алгоритмическая оптимизация. Это как бы вы победили компилятор собирая на С пузырьковую сортировку, а на асме написать квиксорт.
Вы не правы. Компилятору на вход подавалась максимально оптимизированная программа, в том числе с транспонированной матрицей. Я ещё раз говорю: хватит писать всякие домыслы, особенно по поводу printf, — это вы чушь полную написали. Если у вас какие-то сомнения, напишите свою программу, расскажите потом сколько секунд работала.
По поводу printf поясню на всякий случай (не все читают содержание темы): программа тестируется на нескольких десятках тестов, заранее неизвестных участникам. Даже точное количество тестов заранее неизвестно.
Если вы имеете ещё какие-то несостоятельные возражения, то прежде чем их выкладывать, напишите программу любым способом с ЛЮБЫМИ алгоритмическими оптимизациями и скормите её компилятору, если она будет работать меньше 7 секунд на матрице порядка 5000, я приму ваши возражения. А так нечего тут больше обсуждать.
Если вы имеете ещё какие-то несостоятельные возражения, то прежде чем их выкладывать, напишите программу любым способом с ЛЮБЫМИ алгоритмическими оптимизациями и скормите её компилятору, если она будет работать меньше 7 секунд на матрице порядка 5000, я приму ваши возражения. А так нечего тут больше обсуждать.
Предлагаю отписать в Intel и добавить в MKL самую быструю реализацию за 7 секунд, раз текущая сейчас работает 28 секунд.
Ни в коем случае! в MKL же универсальный решатель, который для вещественных чисел как раз работает очень даже хорошо. В нашем конкурсе были целые числа, причём ограниченные числом 600 по модулю (чтобы не переполнялось при умножении). Это совершенно разные задачи.
Сколько именно эта задача с целыми числами считалась бы на MKL? 28 секунд?
В MKL нет функции перемножения для длинных чисел. По крайней мере, я её не нашел. Нужно переводить в вещественные, перемножать и переводить обратно, да это было бы 28 секунд на одном ядре 3 ГГц процессора Core 2 Duo. Думаю, если бы им было надо, они бы такую функцию для маленьких целых чисел сами написали. Но раз не написали, значит это мало кому надо.
Интересно превратить эти секунды в Гигафлопсы, а потом сравнить с реализацией на GPU, например:
www.gpgpu.ru/articles/sgemm-7.html
forum.beyond3d.com/showthread.php?t=54842
www.gpgpu.ru/articles/sgemm-7.html
forum.beyond3d.com/showthread.php?t=54842
НЛО прилетело и опубликовало эту надпись здесь
Как то однажны, в студенчестве, поспорил что мой ассемблерный код обгонит c/c++, писали быструю сортировку. В соревновании использовались TASM и MS VC 6. Выйграл без проблем. Сейчас не проверял, но тогда VC компилировал весьма средненько с точки зрения оптимальности.
+1 как-то давно, я почти целые выходные изучал чего генерирует gcc -O3 из всякого сишного кода. На мой вкус, бороться именно с компилятором смысла нет.
Есть смысл бороться за простоту архитектуры системы и алгоритмы реализации.
Си давно уже стал portable assmebler.
Есть смысл бороться за простоту архитектуры системы и алгоритмы реализации.
Си давно уже стал portable assmebler.
В узких задачах да, идея супер. В больших проектах увы выигрыш скорости перебивается временем (читай стоимостью) разработки
Кажется, проще было написать свой компилятор с «крутыми» оптимизациями. С переупорядочиванием инструкций, размоткой циклов, SSE и т.д.
Стоит ли ожидать полноценной ОС, написанной так?
В MenuetOS, ссылку на которую дал выше, уже есть браузер, портирована libc, и есть еще много чего, хотя это всё скорее just for fun, нежели попытка написать полноценную ОС.
Зачем?
В статье делается акцент, что такая ОС будет компактнее и быстрее. Если это так, то это перспективно, если не для обычного пользователя, то для военных или производителей железа.
Или я чего не понимаю?
Или я чего не понимаю?
железо как-раз с каждым годом дешевле и мощнее
да и с энергопотреблением тоже получше становится
да и с энергопотреблением тоже получше становится
Только это не дает права так лениться при создании кода, как это многие сейчас делают. Скорость разработки, конечно, характеристика важная, но то, что многие программы, которые выполняют почти ту же функциональность, что и их аналоги десяти и даже двадцатилетней давности, ведут себя даже на топовых машинах странно, если не сказать безобразно… это раздражает. Потому как понимаешь, что люди больше не ученые, люди даже не специалисты. Они просто хорошо научились складывать из кубиков картины, похожие внешне на шедевры, но это иллюзия. Программирования как такового не осталось.
Есть еще жизнь на встраиваемых системах. Того же Эдама Данкелса следует вспомнить с его Contiki.
Ведь можно и на Си и на многих других языках писать эффективный код, оптимизировать. Но погоня за сверхприбылями, клиентами, все это имеет место быть.
Есть еще жизнь на встраиваемых системах. Того же Эдама Данкелса следует вспомнить с его Contiki.
Ведь можно и на Си и на многих других языках писать эффективный код, оптимизировать. Но погоня за сверхприбылями, клиентами, все это имеет место быть.
У этой ОС исключительно embedded перспективы, имхо. Никакие затраты на разработку assembler'ом десктопной ОС никогда себя не оправдают. Ближайшее будущее за Singularity OS и аналогами.
Почти родная Колибри.
Return Infinity to devlopment time!
640 килобайт хватит всем
нужно поставлять с машиной времени
иначе в реальные сроки написать что-либо сколько-нибудь значительное просто не реально
иначе в реальные сроки написать что-либо сколько-нибудь значительное просто не реально
Почему же? На C/С++ написать всю обвязку, а вычислительный блок на асме. Ну и ядро ОС на асме. Для многих задач это даже не удвоит время на разработку.
Вообще странно, так много людей из года в год пишут, что на ассемблере писать долго, что это сложно. Хотя на деле язык ассемблера настолько прост, и настолько прозрачен,… мало того, в том же fasm есть очень хороший макроязык (if, else, ...), есть структуры и «отображение» структур в заданные участки памяти (ключевое слово virtual). Естественно, писать на языке ассемблера всю логику — не слишком большое удовольствие. Но и создавать нечто лишь на нем не такое мучение, как может показаться на первый взгляд.
Если говорить о ядре, то в данном случае, это просто набор статически собранных процедур по работе с памятью, формированию пула потоков, вводу-выводу, синхронизации. Ну поддержка FAT и простой сетевой карточки в ту же кучу. Даже если и на ассемблере — объем работы не такой большой, особенно если на современном его диалекте.
Если говорить о ядре, то в данном случае, это просто набор статически собранных процедур по работе с памятью, формированию пула потоков, вводу-выводу, синхронизации. Ну поддержка FAT и простой сетевой карточки в ту же кучу. Даже если и на ассемблере — объем работы не такой большой, особенно если на современном его диалекте.
1. см habrahabr.ru/blogs/asm/120298/?reply_to=3943209#comment_3943137
2. макросы это замечательно. вот только их нужно либо написать, что тоже требует времени, либо взять чужие (качество неизвестно)
ЗЫ в отдельных случая оптимизация кода, в том числе с использованием ассемблера необходима/возможна. но таких случаев, в моей практике, было всего несколько. При этом оптимизацией приходилось заниматься скорей из-за бедности — организация не могла на тот момент использовать более мощное железо
2. макросы это замечательно. вот только их нужно либо написать, что тоже требует времени, либо взять чужие (качество неизвестно)
ЗЫ в отдельных случая оптимизация кода, в том числе с использованием ассемблера необходима/возможна. но таких случаев, в моей практике, было всего несколько. При этом оптимизацией приходилось заниматься скорей из-за бедности — организация не могла на тот момент использовать более мощное железо
Ребята молодцы, наиболее привлекательная часть проекта, которая родилась у них не так давно, если верить публичным источникам, — BareMetal Node. Да, пусть простой Ethernet внизу лежит (никаких TCP/IP, чисто канальный уровень), да задачи пока сугубо тестовые, но ведь это шаг к облаку! И оно работает.
Что касается самого ядра и того чуда, что их сподвигло к его написанию (я о MikeOS): очень милые системы, особенно для того чтобы показать, как это просто, написать ОС. Организация внутри очень няшная. Другое дело, что от таковой организации многое страдает.
На текущий момент BareMetal идет по пути "Nick Stacky", что неплохо конечно, но они не будут расти в сторону ОС общего назначения, почти уверен в этом. Лишь углубят тот успех, что есть. Вычислительные задачи (по потоку на ядро), коммуникация по сети, параллельные вычисления. Вот, собственно, и все. А больше и не надо. Зачем бороться с гигантами, стабильно засевшими в десктопах и серверах? Можно делать что-то свое, но делать это хорошо.
Архитектура простая и смелая (дальше своих узких целей не уползут, но в их рамках будут чувствовать себя хорошо). Только родной Long Mode, монозадачность, многопоточность, монолитность, ассемблер. Ну что же, удачи!
Что касается самого ядра и того чуда, что их сподвигло к его написанию (я о MikeOS): очень милые системы, особенно для того чтобы показать, как это просто, написать ОС. Организация внутри очень няшная. Другое дело, что от таковой организации многое страдает.
На текущий момент BareMetal идет по пути "Nick Stacky", что неплохо конечно, но они не будут расти в сторону ОС общего назначения, почти уверен в этом. Лишь углубят тот успех, что есть. Вычислительные задачи (по потоку на ядро), коммуникация по сети, параллельные вычисления. Вот, собственно, и все. А больше и не надо. Зачем бороться с гигантами, стабильно засевшими в десктопах и серверах? Можно делать что-то свое, но делать это хорошо.
Архитектура простая и смелая (дальше своих узких целей не уползут, но в их рамках будут чувствовать себя хорошо). Только родной Long Mode, монозадачность, многопоточность, монолитность, ассемблер. Ну что же, удачи!
>Если изначально писать на ассемблере, то код получается более производительным и компактным.
автор забыл добавить … и непереносимым а так да… круто… :)
автор забыл добавить … и непереносимым а так да… круто… :)
Вот когда добавят TCP/IP, да появится веб-сервер, можно будет с большим интересом это дело потестировать.
Revolution is coming…
Revolution is coming…
Пойду сайты перепишу на ASM.
Какой-то детский наброс, если честно.
Со времен первых пентиумов скорость выполнения команд процессором зависит от других выполняемых в этот момент команд. Удержать в голове все эти зависимости нереально, не говоря уже о том, что для разных процессоров они разные. А вот компилятору это под силу. Поэтому генераторы машинного кода в 99% случаев уделывают человека без шансов. Да, есть редкие ситуации, когда человек может применить «грязный трюк», не заложенный в компилятор. Но на таких трюках большую программу не напишешь.
Что же касается оптимизации вообще, то сначала нужно оптимизировать архитектуру, а затем алгоритмы.
Со времен первых пентиумов скорость выполнения команд процессором зависит от других выполняемых в этот момент команд. Удержать в голове все эти зависимости нереально, не говоря уже о том, что для разных процессоров они разные. А вот компилятору это под силу. Поэтому генераторы машинного кода в 99% случаев уделывают человека без шансов. Да, есть редкие ситуации, когда человек может применить «грязный трюк», не заложенный в компилятор. Но на таких трюках большую программу не напишешь.
Что же касается оптимизации вообще, то сначала нужно оптимизировать архитектуру, а затем алгоритмы.
Полный бред. Даже для мелких контроллеров, где каждый байт на счету, на асме пишутся только самые критические части, иначе получится жестко привязанное к платформе, не поддающееся нормальному сопровождению чудовище.
Ну и пусть на асме, а стоит ли овчинка выделки, да и видимо разработчики не в курсе как умеют оптимизировать современные компиляторы.
В современном мире чаще выгоднее чуть побольше заплатить за железо, чем тратить в разы больше времени на разработку и поддержку.
В современном мире чаще выгоднее чуть побольше заплатить за железо, чем тратить в разы больше времени на разработку и поддержку.
Я думаю, они всё же изучали вопрос и должны быть в курсе.
Когда на RIT++ Дмитрия Завалишина после презентации его PhantomOS спросили «а зачем, собственно?», он ответил, что для написания «велосипеда» одна причина. Его внуки когда-нибудь спросят деда, какие у него были мечты в жизни, которые он осуществил, и чтобы не мямлить в ответ «ну вот у меня была идея написать такую классную ОС, которая бы..., но я как-то не стал, побоялся», он сел писать свою ОС, чтобы потом, даже если проект провалится, ответить внукам, что он честно пытался.
Кто знает, чем руководствуются разработчики сабжа.
Когда на RIT++ Дмитрия Завалишина после презентации его PhantomOS спросили «а зачем, собственно?», он ответил, что для написания «велосипеда» одна причина. Его внуки когда-нибудь спросят деда, какие у него были мечты в жизни, которые он осуществил, и чтобы не мямлить в ответ «ну вот у меня была идея написать такую классную ОС, которая бы..., но я как-то не стал, побоялся», он сел писать свою ОС, чтобы потом, даже если проект провалится, ответить внукам, что он честно пытался.
Кто знает, чем руководствуются разработчики сабжа.
С этим согласен, у меня есть мечта написать компилятор, пусть не лучший, но свой, пишу :-)
Где можно посмотреть на этот компилятор? Каков формат создаваемых объектных файлов?
Да пока и негде смотреть, изучаю мат.часть, потихоньку начал писать лексический анализатор, мечта написать все это без привлечения каких-либо сторонних разнаботок, так что быстро не закончу, лишь бы терпения хватило.
Удачи! В наше время не так много людей, мечтающих написать свой компилятор.
Не нужно писать компилятор с нуля — это непрофессиональный подход.
Существуют инструменты для генерации тех же анализаторов — этого вполне достаточно чтобы сделать ЯВУ.
Кодогенератор правда придется покодировать…
Для общего понимания принципов работы — вполне достаточно… А так вас засосет рутина.
Существуют инструменты для генерации тех же анализаторов — этого вполне достаточно чтобы сделать ЯВУ.
Кодогенератор правда придется покодировать…
Для общего понимания принципов работы — вполне достаточно… А так вас засосет рутина.
Никому не нужена сверхскоростная ось, которая умеет загружаться и все. Никому ну нужен Hello World, даже если он весит 31 байт.
Сегодня намного важнее модульность, расширяемость и гибкость. В реальном мире, где решаются реальные задачи, никто не станет писать на асме, кроме разве что совсем специфичных случаях. Вычислительная мощность в большинстве случаев дешевле труда программиста.
Сегодня намного важнее модульность, расширяемость и гибкость. В реальном мире, где решаются реальные задачи, никто не станет писать на асме, кроме разве что совсем специфичных случаях. Вычислительная мощность в большинстве случаев дешевле труда программиста.
А кому нужно это всё для построения, например, числогрызки (возможно, кластерной), которая всю жизнь будет решать одну задачу, или, например компа, который работает контроллером какого-то девайса?
Врядли ему для перечисленных целей понадобится именно 64-ая операционная система на ассемблере.
Ну если не понадобится, то просто замечательно! Как же быть тому, кому понадобится? :)
В современном мире μClinux поместится на любое кастрированное железо.
64-ая операционная система на ассемблере нужна только если каждый будет носить электронные часы из китая, куда он не поместится, но будет возможность при этом использовать вычислительную мощность часов (хе-хе, даже самому смешно).
В общем я не вижу реального оборудования, где использование сабжа более оправдано, чем μClinux.
64-ая операционная система на ассемблере нужна только если каждый будет носить электронные часы из китая, куда он не поместится, но будет возможность при этом использовать вычислительную мощность часов (хе-хе, даже самому смешно).
В общем я не вижу реального оборудования, где использование сабжа более оправдано, чем μClinux.
Дело в том, что сабж запускается только на современных процессорах с архитектурой x86. Никакими часами тут и не пахнет. А за счет реализации на языке ассемблера, увидеть ее на чем-то еще пока невозможно (не переносим код).
TL1 имеет ввиду случаи, когда те же персоналки используются для управления, скажем, станком каким, при этом они тихо себе работают, исполняя только им известное колдовство, принимая изредка команды через Ethernet или COM-порт. И вот стоит этот компьютер такой одинокий, совсем даже без терминала, но делает свою работу, потому что если не будет делать, то подведет своих хозяев, ой как подведет.
Причем, порой, найти на предприятии персоналку для таких целей проще, чем разработать решение на базе микроконтроллера или специальной платформы. Да и дешевле.
А 64Bit и Long Mode… просто ребята поняли, что это уже стандартный режим. И давно пора на него переходить, полностью, а не совмещая с Legacy Mode, как это сейчас везде работает. И они правы. Ни реальный, ни режим защищенный (тот самый режим совместимости) уже в прошлом. Первый вообще не нужен, в принципе, только в целях совместимости держат, а второй больно монструозный.
TL1 имеет ввиду случаи, когда те же персоналки используются для управления, скажем, станком каким, при этом они тихо себе работают, исполняя только им известное колдовство, принимая изредка команды через Ethernet или COM-порт. И вот стоит этот компьютер такой одинокий, совсем даже без терминала, но делает свою работу, потому что если не будет делать, то подведет своих хозяев, ой как подведет.
Причем, порой, найти на предприятии персоналку для таких целей проще, чем разработать решение на базе микроконтроллера или специальной платформы. Да и дешевле.
А 64Bit и Long Mode… просто ребята поняли, что это уже стандартный режим. И давно пора на него переходить, полностью, а не совмещая с Legacy Mode, как это сейчас везде работает. И они правы. Ни реальный, ни режим защищенный (тот самый режим совместимости) уже в прошлом. Первый вообще не нужен, в принципе, только в целях совместимости держат, а второй больно монструозный.
>> Ни реальный, ни режим защищенный (тот самый режим совместимости) уже в прошлом.
Следует читать так:
Ни реальный, ни режим защищенный (тот самый режим совместимости) не нужны, уже в прошлом.
Следует читать так:
Ни реальный, ни режим защищенный (тот самый режим совместимости) не нужны, уже в прошлом.
Ой. Не заметил, что это для x86. Ну тогда это вообще нафиг не нужно. Ибо стабильней оно работать не будет. А писать 20-30 утилит для обслуживания програмного кода, которые уже давно реализованы для linux не нужно.
боюсь что портировать этот код на другой проц будет дороже покупки дешевой отладки и библиотеки + рабочего времени программиста
числогрызки (возможно, кластерной), которая всю жизнь будет решать одну задачу,
А эта кластерная числогрызка будет работать на каком чипсете? Сколько у одного узла ядер и сколько процессоров? Через какую сетевую карту она будет соединяться с кластером? И по какому протоколу, да? А всякие GPU она для ускорения расчётов не будет использовать? Откуда, с какого устройства она будет принимать входные данные, и куда будет выводить результаты?..
Черт побери, Билл Гейтс был прав на счёт 640Кб.
очередные бесполезные игрушки красноглазиков :)
лучше бы Linux пилили
лучше бы Linux пилили
6 лет назад написал программу для win32 полностью на ассемблере e-ivanov.ru/exactmouse/
Работала намного быстрее существующих аналогов на высокоуровневых языках, да и весила в 10 раз меньше.
Сейчас, с 2 Ггц процессорами и 4 Гб памяти, это незаметно, поэтому и неважно. Железо дешевле.
Работала намного быстрее существующих аналогов на высокоуровневых языках, да и весила в 10 раз меньше.
Сейчас, с 2 Ггц процессорами и 4 Гб памяти, это незаметно, поэтому и неважно. Железо дешевле.
Вы правы, но это если учитывать только одну маленькую программу, а Вы представьте, если каждую такую программу оптимизируют, и в том числе операционную систему — разница будет серьезная.
С этим я тоже согласен, раньше вообще был очень серьёзным сторонником ассемблера и не признавал ЯВУ (языки высшего уровня).
Но сейчас удобнее разрабатывать программы на ЯВУ, например, на том же js. Компиляторы стали быстрые, в том числе и интерпретаторы.
А ассемблер и машинные коды — удел драйверов и других узких мест. Писать интерфейс работы с кнопкой, который будет работать раз в час по клику пользователя на машинных кодах — маразм и лишняя потеря времени.
Но сейчас удобнее разрабатывать программы на ЯВУ, например, на том же js. Компиляторы стали быстрые, в том числе и интерпретаторы.
А ассемблер и машинные коды — удел драйверов и других узких мест. Писать интерфейс работы с кнопкой, который будет работать раз в час по клику пользователя на машинных кодах — маразм и лишняя потеря времени.
Вы правы! Однако я, например, не уверен что та же работа с кнопкой максимально оптимизирована. Я считаю, что из уже имеющихся инструментов, библиотек, фреймворков нужно выжать максимум. Это очень долгий процесс, но если все делать постепенно, то результаты будут колоссальны. А новая операционная система как фундамент таким изменениям — это очень большой плюс!
К сожалению, пока вы будете копаться в машинных кодах и экономить биты, прогресс уйдёт так далеко, что вам эти биты покажутся смешными.
Даже уже сейчас память компьютера стоит 1 тыр за 4 Гбайта.
А ведь когда то Билли сказал, что 640 кбайт хватит всем.
Вам никто не запрещает писать маленькие программы, но рынок есть рынок. Рынок драйверов и маленьких программ для каких-нибудь микроконтроллеров в холодильнике и т.п. — отличное приложение таланта высококвалифицированных специалистов, коих я считаю всех тех, кто понимает и разбирается в ассемблере.
Хотя сейчас компиляторы С++ так развиты, что позволяют писать эффективные программы не хуже чем на ассемблере (как в скорости работы программы, так и в скорости разработки и дальнейшей поддержки).
Даже уже сейчас память компьютера стоит 1 тыр за 4 Гбайта.
А ведь когда то Билли сказал, что 640 кбайт хватит всем.
Вам никто не запрещает писать маленькие программы, но рынок есть рынок. Рынок драйверов и маленьких программ для каких-нибудь микроконтроллеров в холодильнике и т.п. — отличное приложение таланта высококвалифицированных специалистов, коих я считаю всех тех, кто понимает и разбирается в ассемблере.
Хотя сейчас компиляторы С++ так развиты, что позволяют писать эффективные программы не хуже чем на ассемблере (как в скорости работы программы, так и в скорости разработки и дальнейшей поддержки).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
64-битная ОС на ассемблере