gcc, SIGSEGV и try/catch теперь друзья :)

> у тебя там есть нормальные 32-разрядные беззнаковые?

В лиспе практически всё boxed, кусок регистра тратится на метаинформацию о типе. 32 значащих бита в регистре у SBCL можно получить на 64-битной платформе.

> В лиспе практически всё boxed, кусок регистра тратится на метаинформацию о типе. 32 значащих бита в регистре у SBCL можно получить на 64-битной платформе.

Тогда значит в том примере лисп в 4-8 раз тормознее тормозных плюсов. А вообще надо смотреть выхлоп, я не зря его сделал.

i=1073741824 i0=1072693248 i1=1048576 i0+i1=1073741824

i0=общее количество итераций, i1=итераций с киданием исключения

i=общее количество итераций, i1=итераций с киданием исключения // FIXED

Если они вообще возникают. Не раз и не два поднималась тема с бенчмарками итп. C++ так устроен что там громоздкие действия надо делать при эксепшене.

Там был бенчмарк который всё показывал. Я доверяю, но проверяю.

на 100млн sbcl 38 секунд, c++ 50

в 4-8 раз оно будет медленнее если как раз u32 поставить, потому как начнется арифметика на обобщенных функциях и прочие прелести.

ну и какой-то странный бенчмарк, все-равно
понятны опасения насчет заоптимизации излишней в c++, но исключения особо не оптимизируются, по моим наблюдениям, так что можно оптимизацию отключать, наверное, если сам тест кроме исключений ничего особо не меряет.
мой пример вот чем не устраивает?

это когда исключения дерьмовые, как в c++, то да
на них не то, что логику строить нежелательно, их вообще использовать нежелательно

> это когда исключения дерьмовые, как в c++

Да что в них дерьмового я никак не пойму? Такие же как и в других языках.

А как ты эту лямбду активируешь сверху стека?

> на 100млн sbcl 38 секунд, c++ 50

среди притензий: нельзя мерить скорость исключений, если их почти 100%, они должны быть наоборот оптимизированы быть не самым частым вариантом

ты лучше выхлоп своей проги покажи, посмотрим сколько там итераций было

Не столько дерьмовость даже в их сути, хотя тут есть что сказать, выше написал уже(ну стоит добавить про нарушение столь любимого плюсофилами принципа "вы не платите за то, что не используете"(или как там) - про обертку вокруг конструкторов), сколько в их состыковке с другими частями C++ - в нулевой, то есть, стыковке, не стыкуются они с остальным C++ вообще, и от этого представляют из себя поле граблей и мин(ну вот про те же конструкторы - если в нем исключение, но конструктор уже что-то наинициализировал в динамической памяти, какие-то внутренние указатели объекта, то память под сам то объект, конечно, осводится, а вот под то, что внутри? упс).

>среди притензий: нельзя мерить скорость исключений, если их почти 100%, они должны быть наоборот оптимизированы быть не самым частым вариантом
Почему? Мы тогда, получается, что-то другое мерить будем, не исключения.

>ты лучше выхлоп своей проги покажи, посмотрим сколько там итераций было
да неправильно я замерил твой бенчмарк, неправильно
но 64 разрядной системы нету сейчас, ставить лень
если интересно, попробуй сам скомпилируй и запусти

>да неправильно я замерил твой бенчмарк, неправильно но 64 разрядной системы нету сейчас, ставить лень

ты сам с собой разговариваешь? давай сюда выхлоп, поделим время на количество итераций у плюсов и у лиспа, 64 бита могут подождать

если интересно, попробуй сам скомпилируй и запусти

у меня инет щас дорогой тянуть лисп

> Почему? Мы тогда, получается, что-то другое мерить будем, не исключения.

Исключения часто реализуются так, что ускоряется путь без исключений за счет замедления пути с исключениями, в результате при допустим 10% исключений прога работает быстрее.

З.Ы. человек, не знающий такое, видимо вообще должен молчать про то, что исключения тормозные

> если интересно, попробуй сам скомпилируй и запусти

правда я могу еще на VDS-ке, но там х.з. что параллельно у кого крутится

>Исключения часто реализуются так, что ускоряется путь без исключений за счет замедления пути с исключениями, в результате при допустим 10% исключений прога работает быстрее.

Откуда дровишки?

Ну я и говорю, вырубить оптимизацию и посчитать мой бенчмарк - получим чистую скорость исключений :)

i=268435456 i0=268173312 i1=262144 i0+i1=268435456
1073741824 268173312 1048576 1073741824

обнаружил, кстати, что в плюсах f инлайнится, добавил в лиспе (declaim (inline f)), i0+i1 стало ровно в два раза больше

хотя, вообще, некорректную программу, с оверфлоу интежера, сравнивать с чем-то тоже некорректно

в лиспе ash ни в коем случае не гарантирует врап интежера, т.к. числа, по идее, неограниченной длины

придумай какой-нибудь другой тест

> хотя, вообще, некорректную программу, с оверфлоу интежера, сравнивать с чем-то тоже некорректно

гы-гы, некорректную

ну реализуй x:=a*x (mod 2^N) без оверфлова интеджера, посмотрим что будет быстрее

некорректно полагаться на количество бит 32 в интеджере, но если их не 32, то выхлоп это однозначно показывает

обнаружил, кстати, что в плюсах f инлайнится, добавил в лиспе (declaim (inline f)), i0+i1 стало ровно в два раза больше

да, лисп самобытен :-) но так или иначе спасибо за тест

а время по сравнению с плюсами? итераций лисп делает в 2 раза меньше (500М против 1000М), а времени затрачивает?

> в лиспе ash ни в коем случае не гарантирует врап интежера, т.к. числа, по идее, неограниченной длины

придумай какой-нибудь другой тест

я ничего другого не могу предложить, как в лиспе поставить явное взятие по модулю 2^N

там фактически стоит простейший, быстрый и понятный датчик случайных чисел, если ты можешь предложить что-то аналогичное без врапа интеджера, то welcome

> Ну я и говорю, вырубить оптимизацию и посчитать мой бенчмарк - получим чистую скорость исключений :)

«чистую скорость исключений» можешь смело засунуть в одно место :-)

интересна скорость при разном проценте исключений (что регулируется констаной BITS), при этом врем может не зависеть линейно от % исключений (особенно в случае jvm), так что вообще понятия «чистую скорость исключений» может не существовать

Каждый синтетический тест должен, в идеале, мерять какую-то одну конкретную фичу, особенно если он заявлен какую-то конкретную фичу мерить.
Например, время доступа к элементу массива.
Или, время, затрачиваемое на вызов и перехват исключения(это я и имел ввиду).
И если мы собираемся сравнивать скорости реализаций различных языков, тест должен быть максимально простым и переносимым, не использующим какие-то конкретные фичи какой-то конкретной реализации какого-либо конкретного языка, ассемблерные вставки например, или специфику битовых сдвигов, чтоб его легко можно было на других языках реализовать.

И из набора таких тестов можно уже какую-то более-менее объективную картину производительности какой-либо реализации какого-то языка нарисовать. А так - меряем непонятно что непонятно как.

Если использовать фичи, получается мы меряем не производительность каких-либо конкретных мест реализации языка, а непонятно что меряем, вплоть до производительности обвязки к GMP вместо производительности длинной арифметики, как на shootout.

сумбурно немного написал, да:)

> или специфику битовых сдвигов, чтоб его легко можно было на других языках реализовать

кхм.

если лисп не позволяет использовать специфику битовых сдвигов (ту, которую позволяет ява, си шарп, ... да почти все) я не понимаю, зачем он вообще нужен.

ну воткни там для сдвигов код на асме что-ли, я не против, т.к. меряем мы исключения.

> сумбурно немного написал, да:)

если там в лиспе нет незабоксенных целых (я так понял предыдущие посты), то любые операции с целыми должны тормозить на х86, и я вообще не знаю, как там что-то мерить

там хоть локальные переменные могут быть разбоксены оптимизатором? как-нить еще можно без боксинга?

Есть, например в sbcl в массивах могут вплоть до ([un]signed-byte *разрядность-системы*) включительно незабоксенными храниться. Но в к-либо операциях все, что выше '([un]signed-byte #.(- *разрадяность-системы* *размер-typetag*)) боксится и считается через обобщенную арифметику.

>если лисп не позволяет использовать специфику битовых сдвигов
Фишка просто в том, что CL под убогий 32-разрядный(или 16, или даже 64) x86 не затачивался, как бы. И никаких врапов интежера при переполнении разрядности в стандарте не предусмотрено, максимум в таких случаях предусмотрен type-error. То, что кое-где это можно, это баги(или фичи, как посмотреть) конкретных реализаций.

> То, что кое-где это можно, это баги(или фичи, как посмотреть) конкретных реализаций.

Значит расставь 1-2 явных взятия по модулю 2^28.

Или предложи свой простой и предсказуемый генератор случайных чисел, только я не представляю, как ты обойдешься без взятия по модулю 2^28.

* простой, быстрый и предсказуемый

Если 29 разрядов у нас есть (без расширения числа), то можно попробовать такой тормознутый вариант:

-        x+=x<<2; // x == 5 power i
+        x += (0x3FFFFFF & x) << 2 ; 
+        x &=  0xFFFFFFF; // x == 5 power i (mod 2 power 28)

Пипец, у меня нет слов. Куда вас унесло? Нет бы кто дельным советом помог, потестил... Вот флудеры ей богу....

ну так вроде libsigsegv спасает отца русской демократии... а дальше мы пошли обсуждать сравнительный дизайн языков программирования

Нет бы кто дельным советом помог, потестил

не огорчайся, обычно интерес у людей бывает не тогда, когда ты об этом рассказываешь, а тогда, когда вдруг приспичило стало интересно

> ну так вроде libsigsegv спасает отца русской демократии...

Не спасает, проверил. Исключение в обработчике кидаешь и апп завершается как это происходило при использовании sigaction... Так что, продолжаю работать над своей либой...

> Не спасает, проверил. Исключение в обработчике кидаешь и апп завершается как это происходило при использовании sigaction... Так что, продолжаю работать над своей либой...

а тогда это интересно.