Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
Таким образом я могу убрать нахуй какой-нибудь злоебучий switch и вместо него хуйнуть сразу указатель. Это может быть например использовано для построения интерпретатора (шитый код)
зависит от архитектуры. на десктоп/сервер процах, за переход по указателю ты платишь производительностью: префетч/этц не работают.
но ты так и не сказал чем тебе switch не угодил.
с другой стороны, народ давно такое уже делал - просто с помощью указателей на функции. и этот подход сильно здравому рассудку не противоречит, по сравнению с computed goto.
switch не всегда будет оттранслирован компилятором в таблицу переходов, а computed goto - всегда.
> с другой стороны, народ давно такое уже делал - просто с помощью указателей на функции.
Может так оказаться, что от вызовов через указатели на функции будет больше оверхеда, чем через computed goto в пределах одной функции, если пишется интерпретатор(шитый код)
> switch не всегда будет оттранслирован компилятором в таблицу переходов
не от хорошей жизни же. и индексы часто не по порядку/с дырками, и кода часто слишком много для коротких переходов, и каких еще побочных эффектов с fall-through.
> вызовов через указатели на функции будет больше оверхеда, чем через computed goto в пределах одной функции
очевидно что у вызова выше оверхед, по сравнению с computer goto. с другой стороны, все те ограничения на которые ты жалуешься как раз и происходят то того что goto прологов/эпилогов не делает. поэтому и быстрее. но поэтому и только в пределах функции.
с другой стороны чувствую что ты на каких микро-контроллерах этим страдаешь. а там ведь что джамп, что колл - почти одинаково тормозят. "premature optimization".
Ну так если я запилю какие-то свои изменения в фронтэнд (clang) то он все равно будет зависеть от кривого LLVM говнокода, который мне категорически не нравится. Более того, у меня есть идеологическая неприязнь к той лицензии, под которой этот самый clang/llvm распространяется, я например не хочу чтобы мой код и мои наработки потом кто-то интегрировал в свои проприетарные хрени, не башляя мне денег за это. А вот в копилефт-опенсорс я еще могу поинвестировать свои усилия, так-то.
Но на самом деле все компиляторы говно, и надо чтобы компиляторы могли в символьнуые вычисления с логикой Хоара, формальная верификация, суперкомпиляция, гомоиконность, возможность написания domain-specific оптимизаций http://govnokod.ru/22687#comment379779
или вот например, есть две сортировки которые обе правильно работают т.е. без багов
char a[300];
scanf (a[0...299]);
char a1_sorted[300]
char a2_sorted[300]
qsort(a, a1_sorted);
bubble_sort(a, a2_sorted);
if( a1_sorted == a2_sorted) // тут компилятор эту проверку должен вообще выкинуть, оставив только printf("ok, good!");
printf("ok, good!");
else
printf("impossible");
и вот собственно компилятор чтоб мог логикой Хоара доказать что обе сортировки одинаковые последовательности байт выдадут, и соответственно нефиг вообще делать проверку if( a1_sorted == a2_sorted)
Кроме того, если сортированные массивы впоследствии никак не используются, то можно даже и scanf (a[0...299]); выкинуть, как и сам char a[300]; оставив только имитацию его работы, ну типа если пользователь должен по логике набрать через пробел 300 чисел, то оно будет это все как бы читать(наблюдаемое пользователем поведение будет таким же), но фактически никуда эти числа записываться в массив не будут, т.к. незачем потому что мы знаем точно что что бы туда не вводили, один хрен будет printf("ok, good!");
> Ну и bubble_sort должен в таком случае на qsort заменяться, когда массив слишком большой.
Не факт. bubble_sort вполне может уделать qsort на каких-нибудь почти сортированных данных, где в случайных местах перемешаны пары элементов, типа 1 0 2 3 4 6 5 7 9 8. Но вот слегка заоптимизировать bubble_sort было б совсем не лишним. Например, если bubble_sort проходится по массиву из начала в конец, то следующий обход можно делать на единицу меньше (т.е. сортировать уже не n элементов массива, а n-1) т.к. в самую последнюю позицию массива засунуто наибольшее значение, и учитывать его смысла никакого нет
>> Но вот слегка заоптимизировать bubble_sort было б совсем не лишним. Например, если bubble_sort проходится по массиву из начала в конец, то следующий обход можно делать на единицу меньше (т.е. сортировать уже не n элементов массива, а n-1) т.к. в самую последнюю позицию массива засунуто наибольшее значение, и учитывать его смысла никакого нет
> божественная оптимизация. Увеличиваем вес одной итерации вдвое, зато уменьшаем сложность с 0.5*n^2 до 0.5*(n-1)*n
Как оказалось, j123123 совершил прорыв в теории алгоритмов и обнаружил суть сортировки пузырьком: самый большой элемент "всплывает", из-за чего на следующей итерации количество неотсортированных элементов снижается и вместо n^2 получается 0.5 n^2. Но это уже и так сортировка пузырьком, в неё вшита эта "оптимизация". Соответственно, вес одной итерации остаётся прежним.
>> bubble_sort вполне может уделать qsort на каких-нибудь почти сортированных данных
Предлагаю шейкерную сортировку как пример. Для m неотсортированных элементов сложность не превысит (2m+1)n.
Ошибаетесь, коллега. Данное высоконаучное исследование сортировок в свое время было проведено на всемирно известном и популярном среди компьютер сраентистов сайте https://habrahabr.ru/post/204600/
А я, а я напишу!
Ибо в детстве я не додумался прочитать документацию по стандартным BlackBox'овским коллекциям, но додумался до пузырька, сортировки выбором и счётом. Последним алгоритмом я прямо очень гордился, линейная сложность, хули.
С этим связан позорный момент, что в первом софтварном рендере я не использовал z-буфер, а именно сортировал точки, включая невидимые.
<a href=http://cialisgenerikaindeutschlandkaufen.com/>cialis generika deutschland rezeptfrei </a>
<a href=" http://cialisgenerikaindeutschlandkaufen.com/ ">cialis generika aus deutschland paypal </a>
> if( a1_sorted == a2_sorted) // тут компилятор эту проверку должен вообще выкинуть, оставив только printf("ok, good!");
тут компилятор эту проверку должен вообще выкинуть, оставив только printf("impossible");*
можно будет подобные вещи делать на контрактах. Скажем, функция гарантирует, что при правильном использовании массив отсортирован. Но не в автоматическом режиме.
>Этот код попадает в critical path JIT'а или интепретатора, чтобы задумываться об оптимальности?
>Так то генереция инструкций - не самая ресурсоёмкая часть конпелятора. Всяко занимает на пару порядков меньше, чем оптимизации на предыдущих этапах...
А если я руками пишу супермегаоптимальный LLVM код на LLVM ассемблере, и для меня именно это место является причиной тормозов
А если серьезно, то просто неприятно на такое говно анскильное смотреть, особенно от разрабов компиляторов, они-то должны понимать что это будет неэффективно, делать кучу сравнений. Ладно б еще какой-нибудь питонист или похапешник такое написал
вот смотри. Ты великий разработчик компилятора LLVM, программист с большой буквы царь, а не какой-то там говно/быдло/методичко/веб-кодер. Зачем тебе оптимизировать каждую строчку кода компилятора, если ты можешь написать патч в оптимизатор этого самого компилятора, чтобы он делал это за тебя?
Я пизданулся
Так даже чуть лучше
но ты так и не сказал чем тебе switch не угодил.
с другой стороны, народ давно такое уже делал - просто с помощью указателей на функции. и этот подход сильно здравому рассудку не противоречит, по сравнению с computed goto.
switch не всегда будет оттранслирован компилятором в таблицу переходов, а computed goto - всегда.
> с другой стороны, народ давно такое уже делал - просто с помощью указателей на функции.
Может так оказаться, что от вызовов через указатели на функции будет больше оверхеда, чем через computed goto в пределах одной функции, если пишется интерпретатор(шитый код)
не от хорошей жизни же. и индексы часто не по порядку/с дырками, и кода часто слишком много для коротких переходов, и каких еще побочных эффектов с fall-through.
> вызовов через указатели на функции будет больше оверхеда, чем через computed goto в пределах одной функции
очевидно что у вызова выше оверхед, по сравнению с computer goto. с другой стороны, все те ограничения на которые ты жалуешься как раз и происходят то того что goto прологов/эпилогов не делает. поэтому и быстрее. но поэтому и только в пределах функции.
с другой стороны чувствую что ты на каких микро-контроллерах этим страдаешь. а там ведь что джамп, что колл - почти одинаково тормозят. "premature optimization".
Как она работает? Разве можно в чужую память лезть?
А еще можно /proc/12345/mem читать
Было б наверное норм
Я вот даже бенчмарк запилил
https://gist.github.com/j123123/2412d39ce79b52ff6d6069300f392056
Шланг же превращает сорцы в .llvm, так не так всё грустно.
Но на самом деле все компиляторы говно, и надо чтобы компиляторы могли в символьнуые вычисления с логикой Хоара, формальная верификация, суперкомпиляция, гомоиконность, возможность написания domain-specific оптимизаций http://govnokod.ru/22687#comment379779
или вот например, есть две сортировки которые обе правильно работают т.е. без багов
и вот собственно компилятор чтоб мог логикой Хоара доказать что обе сортировки одинаковые последовательности байт выдадут, и соответственно нефиг вообще делать проверку if( a1_sorted == a2_sorted)
Кроме того, если сортированные массивы впоследствии никак не используются, то можно даже и scanf (a[0...299]); выкинуть, как и сам char a[300]; оставив только имитацию его работы, ну типа если пользователь должен по логике набрать через пробел 300 чисел, то оно будет это все как бы читать(наблюдаемое пользователем поведение будет таким же), но фактически никуда эти числа записываться в массив не будут, т.к. незачем потому что мы знаем точно что что бы туда не вводили, один хрен будет printf("ok, good!");
Вот это действительно заебись будет
А сборка пыха таким компилятором вообще должна standalone-версию джумлы выплёвывать.
Не факт. bubble_sort вполне может уделать qsort на каких-нибудь почти сортированных данных, где в случайных местах перемешаны пары элементов, типа 1 0 2 3 4 6 5 7 9 8. Но вот слегка заоптимизировать bubble_sort было б совсем не лишним. Например, если bubble_sort проходится по массиву из начала в конец, то следующий обход можно делать на единицу меньше (т.е. сортировать уже не n элементов массива, а n-1) т.к. в самую последнюю позицию массива засунуто наибольшее значение, и учитывать его смысла никакого нет
> божественная оптимизация. Увеличиваем вес одной итерации вдвое, зато уменьшаем сложность с 0.5*n^2 до 0.5*(n-1)*n
Как оказалось, j123123 совершил прорыв в теории алгоритмов и обнаружил суть сортировки пузырьком: самый большой элемент "всплывает", из-за чего на следующей итерации количество неотсортированных элементов снижается и вместо n^2 получается 0.5 n^2. Но это уже и так сортировка пузырьком, в неё вшита эта "оптимизация". Соответственно, вес одной итерации остаётся прежним.
>> bubble_sort вполне может уделать qsort на каких-нибудь почти сортированных данных
Предлагаю шейкерную сортировку как пример. Для m неотсортированных элементов сложность не превысит (2m+1)n.
https://habrahabr.ru/post/204600/
Я тоже не напишу. Постоянно приходится гуглить, чем она отличается от нормальной сортировки вставками.
Ибо в детстве я не додумался прочитать документацию по стандартным BlackBox'овским коллекциям, но додумался до пузырька, сортировки выбором и счётом. Последним алгоритмом я прямо очень гордился, линейная сложность, хули.
С этим связан позорный момент, что в первом софтварном рендере я не использовал z-буфер, а именно сортировал точки, включая невидимые.
<a href=" http://cialis5mgohnerezeptbestellen.com/ ">cialis 5mg rezeptfrei bestellen </a>
<a href=" http://viagraohnerezeptapothekepernachnahme.com/ ">viagra ohne rezept apotheke per nachnahme </a>
<a href=" http://sildenafil100mgrezeptfreikaufen.com/ ">sildenafil basics 100mg fta 60 st </a>
<a href=" http://viagragenerikakaufenindeutschland.com/ ">viagra generika kaufen deutschland paypal </a>
<a href=" http://sildenafilratiopharmkaufenohnerezept.com/ ">sildenafil ratiopharm teilbar </a>
<a href=" http://cialisgenerikaindeutschlandkaufen.com/ ">cialis generika aus deutschland paypal </a>
<a href=" http://propeciaprixpharmacie.com/ ">propecia prix maroc </a>
<a href=" http://acheterpropeciasansordonnance.com/ ">achat propecia sans ordonnance </a>
<a href=" http://acheteramoxicillinepascherenfrance.com/ ">achat amoxicilline sans ordonnance </a>
<a href=" http://acheteramoxicilline500enligne.com/ ">acheter amoxicilline 500 en ligne </a>
тут компилятор эту проверку должен вообще выкинуть, оставив только printf("impossible");*
можно будет подобные вещи делать на контрактах. Скажем, функция гарантирует, что при правильном использовании массив отсортирован. Но не в автоматическом режиме.
P. S. Не анскилябры, а цори.
Этот код попадает в critical path JIT'а или интепретатора, чтобы задумываться об оптимальности?
Так то генереция инструкций - не самая ресурсоёмкая часть конпелятора. Всяко занимает на пару порядков меньше, чем оптимизации на предыдущих этапах...
>Так то генереция инструкций - не самая ресурсоёмкая часть конпелятора. Всяко занимает на пару порядков меньше, чем оптимизации на предыдущих этапах...
А если я руками пишу супермегаоптимальный LLVM код на LLVM ассемблере, и для меня именно это место является причиной тормозов
А если серьезно, то просто неприятно на такое говно анскильное смотреть, особенно от разрабов компиляторов, они-то должны понимать что это будет неэффективно, делать кучу сравнений. Ладно б еще какой-нибудь питонист или похапешник такое написал