- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
#include <stdio.h>
void *labels[3];
void test(void *ptr)
{
if(ptr == NULL)
{
labels[0] = &&l1;
labels[1] = &&l2;
labels[2] = &&l3;
return;
}
goto *ptr;
l1:
printf("test1\n");
return;
l2:
printf("test2\n");
return;
l3:
printf("test3\n");
return;
}
int main(void)
{
test(NULL);
test(labels[0]);
test(labels[1]);
test(labels[2]);
}
Follow us!
Я пизданулся
Так даже чуть лучше
но ты так и не сказал чем тебе 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 ассемблере, и для меня именно это место является причиной тормозов
А если серьезно, то просто неприятно на такое говно анскильное смотреть, особенно от разрабов компиляторов, они-то должны понимать что это будет неэффективно, делать кучу сравнений. Ладно б еще какой-нибудь питонист или похапешник такое написал