Когда вы пишите код на ассемблере — вы можете сказать: «Ok, я знаю где вызывающая процедура хранит те или иные данные и передавать их никуда не нужно».
И на языках высокого уровня обычно функция имеет доступ к глобальным переменным и может их менять. Т.е. можно и не передавать данные, хотя это справедливо считается плохим стилем.ООП узаконило некоторые виды общих данных для методов класса. Но в общем случае надо делать такие функции, чтобы они вызывались не слишком часто — нпр., не всегда в тело цикла стоит вставлять вызов функции :)
Задача распределения регистров — NP-полная, а компиляторы, которые «колдуют над программой» часами почему-то никому не нравятся — потому в реальности все алгоритмы распределения регистров очень плохо работают при их нехватке.
Люди решают NP-полные задачи еще медленнее, чем машины :)
Или вы думаете зря эта возможность добавлена в некоторые компиляторы C?
Может, и не зря. Нужно сравнивать, насколько эта возможность делает быстрее реализации конкретных алгоритмов. И в стандартах Паскаля есть goto, но все учебники рекомендуют использовать этот оператор только в крайних случаях. Про goto много спорили и пришли к выводу, что исключительные ситуации, нпр., нужно обрабатывать иначе. И в Дельфи есть goto, но без него можно обойтись. Обычно и обходятся.
Выдавать желаемое за действительное — это богатое воображение? ;)
Практически всегда, когда у вас данные приходят «извне» и вы начинаете с ними манипулировать вам нужно проверять что при этих вычислениях не просиходит переполнения.
Далеко не всегда. Допустим, у меня есть какой то список и мне нужно его отсортировать. Очень частая стандартная задача и решается стандартными путями. Зачастую список заведомо небольшой и никакого переполнения вызвать не может.
Вопрос в другом: да, вы можете ускорить в 2-3 раза почти любой кусок кода. Однако на каждые 100 строк кода вам придётся потратить, примерно, день. Даст ли это вам адекватный выигрыш в деньгах или может на что-то другое время потратить? При размерах современных систем, измеряемых миллионами строк и новых архитектурах, выходящих каждые 2-3 года — вопрос далеко не очевиден.
Не будем говорить о системах в миллионы строк, а посмотрим на множество ежедневно публикуемых новых алгоритмов, реализация которых занимает в среднем несколько десятков строк. Большую долю составляют эвристические алгоритмы. В этом случае автору приходится демонстрировать, что его алгоритм на практике работает быстрее, чем ранее предложенные. Но почему-то такие демонстрации обычно проводятся на языках высокого уровня. Неужели все эти авторы не подозревают, что на ассемблере они получат сногосшибательные результаты? ;)
А в чем проблема соглашения о вызовах? По указанной ссылке никакой проблемы не нашел.
Да в конце-концов чудовищная нехватка регистров — тоже очень мешает!
Переход на ассемблер регистров не прибавит :) Можно какой иначе использовать и только.
Человек же не переводит программу с C на ассемблер — а потому гораздо более свободен в том, что он может делать!
Свобода не гарантирует успеха :) Выше говорили, что турбо-Паскаль позволяет писать «goto labels[index]^». И что дает эта дополнительная степень свободы? — Возможность написать запутанный код, трудный для человеческого восприятия. И больше ничего.
любой современный процессор в качество побочного действия от операции сложения порождает информацию о том произошёл перенос или нет — и может сложить два числа с учётом переноса.
Сходу затрудняюсь представить, где это может быть полезно. Разве только арифметика многократной точности. Ну так это очень специальная область, нужная не часто. Подобное можно предположить и про другие возможности, не используемые в языках высокого уровня. Бывают особые случаи, когда функцию стоит написать на ассемблере. С этим никто не спорит. Но это не значит, что любой критический участок можно ускорить в 2-3 раза, перейдя на ассемблер. Такой переход оправдан только в редких случаях.
затык возникает в другом месте: при переводе алгоритма с «математического псевдокода» на C возникают дополнительные ограничения, которые часто мешают компилятору сделать оптимальный код
В общем, это не проблема кодера, а проблема автора алгоритма, т.к. к настоящему времени сложилась довольно устойчивая традиция публиковать не только мат. псевдокод алгоритма, но и выкладывать его реализацию.
С переводом с C на ассемблер современные компиляторы справляются лучше человека
И я выше это утверждал, а мне в ответ:
и если что — я и мои знакомые можем делать на ассемблере код более быстрый, чем на языке высокого уровня
:))
Далее:
Не забывайте что чтение из памяти — тоже времени требует.
Звучит разумно, но сомнения остаются, как и про:
затык возникает в другом месте: при переводе алгоритма с «математического псевдокода» на C возникают дополнительные ограничения, которые часто мешают компилятору сделать оптимальный код, а когда вы пишите код на ассемблере — вы этих ограничений лишены.
думаю и CUDA C обгонит даже хорошо оптимизированный AVX512-ассемблер. И даже четырёхратная разница в тактовой частоте не спасёт
Это только предположения, пусть и разумные. Но статью бы об этом написали — тогда обсуждение станет конкретным.
Всё зависит от алгоритма, но если мы говорим о самом простом варианте (где живая/мёртвая клетка — это один бит)
Мы говорим о скорости, а память мы не экономим. На многих языках для скорости на клетку выгоднее отводить байт. И для ряда языков самым простым вариантом будет байт на клетку, а не бит на клетку.
С другой стороны ассемблер и AVX2 дают нам «сходу» возможность использовать не 64 бита, а 32 байта (AVX512 даст аж прямо 64 байта
Тут возникает «философское» возражение: что это уже другой алгоритм и что мы сравниваем — эффективность реализации или эффективность алгоритмов? ;))
и в любом случае GPU выиграет, так что практического смысла переписывать на ассемблер может и не быть.
Я совсем недавно занялся CUDA — до сих пор задач не было. М.б. поэтому не в курсе. CUDA Си есть, а вот не видел, что кто-то пишет на CUDA асме ;)
Часто, глядя на код, особенно простой ученической задачи, легко придумать контрпример. Нпр., нет обработки исключения деления на 0, не учтен ввод пустой строки и т.д.
на мой вопрос «у меня плохая память на имена потому слова „теорема Такого-то Сякого-то“ мне ни о чём не говорят — не могли бы вы сказать о чём она?» преподаватели реагировали всегда вполне благосклонно — при условии, конечно, что я на самом деле знал как доказать эту самую теорему.
Помнится, в коллоидной химии есть формула (не помню чьего имени),
полученная эмпирически. Эта формула — 4х этажная дробь, где много всяких буковок и коэффициентиков. Студенты должны были ее знать, чтобы сдать экзамен на ХФ МГУ :) А в физмат школе, где я учился, мы должны были помнить формулу синуса тройного угла и еще кучу подобного мусора, который можно посмотреть в любом справочнике.
хотя как раз Жизнь ускорить с использованием ассемблера можно изрядно
Который легко может обойти переносимую реализацию по скорости в 2-3 раза, иногда и больше.
А Жизнь можно таким образом в 2-3 раза ускорить? На мой взгляд, это неочевидно. М.б. на 10-20% — более реалистичное ожидание?
Почему я говорю о кусках кода с интринзиками как об «ассемблере»?
Пусть берет, главное, чтобы результат был правильный. Необязательно преподавателю знать все языки.
Разве учителя не должно волновать, что в коде «goto labels[index]^» и подобное? ;) Если преподаватель будет формально смотреть только на результаты работы программы, то такого преподавателя легко обмануть: скачать решение из инета или попросить приятеля решить задачку и идти сдавать, совершенно не понимая, как работает это решение. А вот если преподаватель будет спрашивать по деталям исходного кода, будут видны действительные знания ученика и стиль его кода. Правильно оценить код на совершенно незнакомом языке — проблематично.
Есть задачи, которые компилятор на языке высокого уровня решить лучше человека не сможет, по крайней мере пока
Наверное есть. Это можно предположить, исходя из общих соображений. Вопрос в том, велика ли доля таких задач? Может, это частные случаи, какие-то редкие мелочи, неучтенные при создании компилятора? Если вспомнить компиляторы для IBM 360/370, то там почти со 100%-ой гарантией перенос на ассемблер критического участка кода давал заметный выигрыш. Сейчас, благодаря прогрессу, не всегда очевидно, стоит ли игра свеч, т.е. время на перенос можно потратить много, а выигрыш может оказаться очень небольшим.
думаете люди от нечего делать там целые функции на ассемблере или интрисиками пишут?
На столь общее утверждение существует столь же общее возражение: некоторые люди иногда совершают странные и непонятные стороннему наблюдателю поступки ;) М.б., со времен IBM 360 сложилась традиция какие-то специальные функции на ассемблере писать? ;) Переносили старый код и, недолго думая, все, что на ассемблере, написали на ассемблере. (Я, конечно, несколько утрирую, но в столь общих рассуждениях это неизбежно :)
Я имел ввиду немного другое — неписанные стандарты, кто-то вот решил, что указатели это зло и сказал — в школе будем изучать язык без указателей — это будет стандарт обучения.
Бывают не только глупые/бездарные ученики, но и учителя :)
Зубрить ничего не надо, надо понимать суть, для остального есть справочники
Согласен. Но традиционно, даже в лучших универах, математику и естественные науки изучают путем зубрежки формул, теорем, доказательств и т.д. (А студенты-историки даты зубрят :))
а школьные задачи можно решить на любом языке — пусть ученик сам решает — на сколько он готов выпендриваться. У нас в школе так и было, кто-то писал на Бейсике, кто-то на Паскале, я писал на Си.
А если ученик возьмет совсем экзотический язык, который мало кто знает? Нпр., в моей коллекции есть описания и трансляторы языков T и Dee. Слышали о таких? ;)
А критические участки реализуют на ассемблере по сей день, и если что — я и мои знакомые можем делать на ассемблере код более быстрый, чем на языке высокого уровня
Сможете доказать? ;) Вот Вам и тема для очередной Хабр-статьи: возьмите какую ни будь задачку из общеизвестных (игра Жизнь, задача коммивояжера и т.д.), решите на языке высокого уровня, а потом ускорьте критические участки, переписав их на ассемблере. В статье сравните время выполнения и поделитесь секретами успеха, приложите исходный код. Уверен, что такая статья многих здесь заинтересует.
Да. Стандарты ограничивают и дисциплинируют. Прежде всего, производителей компиляторов и других инструментов программирования. Благодаря стандартам к «болту» одного производителя всегда можно подобрать «гайку» другого. От любого из существующих стандартов можно отказаться и оформить тот же текст в виде рекомендаций, но если среднего школьника, которому положено посещать уроки информатики и который не собирается стать профессиональным программистом, заставить вызубрить эти рекомендации – такая задача будет ему не по силам. А стандарты школьникам зубрить не нужно: компилятор обругает в том месте, где ученик отошел от стандарта. Думаю, что в школе и на первых курсах института самомодифицирующийся код изучать не надо: пусть сначала плавать научатся. И я любил работать на ассемблере: вплоть до Intel 80486 включительно удавалось творить чудеса (особенно для NP задач), а потом возросшие ресурсы позволили реализовать мощные оптимизаторы – я (и мои знакомые и сослуживцы по ассемблерным делам) быстро обнаружили, что из написанного на языке высокого уровня кода получается гораздо более быстрый «экзешник», чем нам удается сделать на ассемблере.
Turbo Pascal с первых версий ради удобств сильно отходил от стандартов. Поэтому, например, в США многие преподаватели считали его не учебным. Интерпретатор нашего бота не позволяет написать «goto labels[index]^», выдавая две синтаксических ошибки: «integer expected» и «illegal symbol».
Первоначально одной из основных целей Паскаля была «учебный язык», т.е. язык для обучения программированию. Поэтому даже неискушенному новичку на Паскале написать очень плохой код гораздо труднее, чем на других языках :) Си, например, тоже довольно простой язык (если сравнивать с С++), но он очень гибкий. Опытные кодеры считают эту гибкость достоинством, но новичкам она вредит: такого понаписать можно… Описание Паскаля занимает всего 30 страниц — по силам прочитать и понять любому фанату КР, даже если никогда до этого не программировал и в школе информатику не учил :) И на форумах фрагменты кода на Паскале обсуждать удобно — никто не говорит, что не понимает столь простого языка :))
Согласен, что скриптовые языки зачастую узко специализированы, но у нас другой случай: мы использовали язык общего назначения (Паскаль) в качестве скриптового :)
Согласен, что Паскаль развивается. В том числе и в виде Дельфи (есть еще и Free Pascal и др.). До Delphi-7 (включительно) развитие шло органично: делались пристройки, но сохранялось основное очень простое ядро. Отсюда была хорошая совместимость со старыми версиями. А потом стало несовместимым, и многие из тех, у кого много старого кода, продолжают использовать Delphi-7. Пример: игра КР (для которой упомянутый бот).
Простые языки подходят для решения очень многих задач. Не для рекламы, а только в качестве примера упомяну наш проект игрового бота. Там, на мой взгляд, совершенно обосновано в качестве языка скриптов взят стандартный Паскаль. А взяли бы мы что-то посложней (или что-то попроще — совсем примитивное), до сих пор бы на старте буксовали :)
Как законопослушный гражданин может застраховаться от судебной ошибки? Ни одна система, ни один антивирусник не дают 100%-ную гарантию от троянов. Вполне может сесть троян, который пошлет какое-нибудь нехорошее сообщение, пока я пишу этот текст. Или же быть уже посажен в бесплатно распространяемую программу или ОС. Например, найдется какая-нибудь очень удобная сборка Линукса, загружу live DVD, а что там троян, можно и не обнаружить. Как в других странах решается эта проблема?
Люди решают NP-полные задачи еще медленнее, чем машины :)
Может, и не зря. Нужно сравнивать, насколько эта возможность делает быстрее реализации конкретных алгоритмов. И в стандартах Паскаля есть goto, но все учебники рекомендуют использовать этот оператор только в крайних случаях. Про goto много спорили и пришли к выводу, что исключительные ситуации, нпр., нужно обрабатывать иначе. И в Дельфи есть goto, но без него можно обойтись. Обычно и обходятся.
Далеко не всегда. Допустим, у меня есть какой то список и мне нужно его отсортировать. Очень частая стандартная задача и решается стандартными путями. Зачастую список заведомо небольшой и никакого переполнения вызвать не может.
Не будем говорить о системах в миллионы строк, а посмотрим на множество ежедневно публикуемых новых алгоритмов, реализация которых занимает в среднем несколько десятков строк. Большую долю составляют эвристические алгоритмы. В этом случае автору приходится демонстрировать, что его алгоритм на практике работает быстрее, чем ранее предложенные. Но почему-то такие демонстрации обычно проводятся на языках высокого уровня. Неужели все эти авторы не подозревают, что на ассемблере они получат сногосшибательные результаты? ;)
Переход на ассемблер регистров не прибавит :) Можно какой иначе использовать и только.
Свобода не гарантирует успеха :) Выше говорили, что турбо-Паскаль позволяет писать «goto labels[index]^». И что дает эта дополнительная степень свободы? — Возможность написать запутанный код, трудный для человеческого восприятия. И больше ничего.
:))
Далее: Звучит разумно, но сомнения остаются, как и про: Это только предположения, пусть и разумные. Но статью бы об этом написали — тогда обсуждение станет конкретным.
Тут возникает «философское» возражение: что это уже другой алгоритм и что мы сравниваем — эффективность реализации или эффективность алгоритмов? ;))
Я совсем недавно занялся CUDA — до сих пор задач не было. М.б. поэтому не в курсе. CUDA Си есть, а вот не видел, что кто-то пишет на CUDA асме ;)
полученная эмпирически. Эта формула — 4х этажная дробь, где много всяких буковок и коэффициентиков. Студенты должны были ее знать, чтобы сдать экзамен на ХФ МГУ :) А в физмат школе, где я учился, мы должны были помнить формулу синуса тройного угла и еще кучу подобного мусора, который можно посмотреть в любом справочнике.
А Жизнь можно таким образом в 2-3 раза ускорить? На мой взгляд, это неочевидно. М.б. на 10-20% — более реалистичное ожидание?
Ok.
Наверное есть. Это можно предположить, исходя из общих соображений. Вопрос в том, велика ли доля таких задач? Может, это частные случаи, какие-то редкие мелочи, неучтенные при создании компилятора? Если вспомнить компиляторы для IBM 360/370, то там почти со 100%-ой гарантией перенос на ассемблер критического участка кода давал заметный выигрыш. Сейчас, благодаря прогрессу, не всегда очевидно, стоит ли игра свеч, т.е. время на перенос можно потратить много, а выигрыш может оказаться очень небольшим.
На столь общее утверждение существует столь же общее возражение: некоторые люди иногда совершают странные и непонятные стороннему наблюдателю поступки ;) М.б., со времен IBM 360 сложилась традиция какие-то специальные функции на ассемблере писать? ;) Переносили старый код и, недолго думая, все, что на ассемблере, написали на ассемблере. (Я, конечно, несколько утрирую, но в столь общих рассуждениях это неизбежно :)
Согласен. Но традиционно, даже в лучших универах, математику и естественные науки изучают путем зубрежки формул, теорем, доказательств и т.д. (А студенты-историки даты зубрят :))
А если ученик возьмет совсем экзотический язык, который мало кто знает? Нпр., в моей коллекции есть описания и трансляторы языков T и Dee. Слышали о таких? ;)
Сможете доказать? ;) Вот Вам и тема для очередной Хабр-статьи: возьмите какую ни будь задачку из общеизвестных (игра Жизнь, задача коммивояжера и т.д.), решите на языке высокого уровня, а потом ускорьте критические участки, переписав их на ассемблере. В статье сравните время выполнения и поделитесь секретами успеха, приложите исходный код. Уверен, что такая статья многих здесь заинтересует.
Согласен, что Паскаль развивается. В том числе и в виде Дельфи (есть еще и Free Pascal и др.). До Delphi-7 (включительно) развитие шло органично: делались пристройки, но сохранялось основное очень простое ядро. Отсюда была хорошая совместимость со старыми версиями. А потом стало несовместимым, и многие из тех, у кого много старого кода, продолжают использовать Delphi-7. Пример: игра КР (для которой упомянутый бот).