LINUX.ORG.RU

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


0

0

Я нарыл способ преобразовывать сигналы типа SIGSEGV в исключения языка C++, которые можно ловить по try/catch, так как это происходит, например, в виндовых компиляторах.

http://www.visualdata.ru/blog/109-segv-signal.html

Сразу прошу не разводить флуд, мол не надо ловить - правильно падать. Прошу потестить подход на различных платформах, версиях компилятора gcc.

Еще хочу сделать на базе этого кроссплатформенную либу под LGPL, облегчающую эту обработку. Не могу придумать название - libsigsegv, libseh уже есть, пока в голову приходит только libsegv или libsegvcatch :)

PS. Уже проверил на opensuse 11.1, на gentoo компилятор gcc-4.3, на MCBC, компилятор gcc-3.3, платформа i386.

Ответ на: комментарий от www_linux_org_ru

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

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

mv ★★★★★
()
Ответ на: комментарий от mv

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

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от mannaz

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

true_admin ★★★★★
()
Ответ на: комментарий от navrocky

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

true_admin ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

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

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

Love5an
()
Ответ на: комментарий от jerry_ru

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

Love5an
()
Ответ на: комментарий от Love5an

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

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

navrocky ★★
() автор топика
Ответ на: комментарий от www_linux_org_ru

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

Love5an
()
Ответ на: комментарий от Love5an

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

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

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от navrocky

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

Love5an
()
Ответ на: комментарий от www_linux_org_ru

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

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

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

Love5an
()
Ответ на: комментарий от Love5an

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

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

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

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от Love5an

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

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

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от Love5an

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

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

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

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

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

Love5an
()
Ответ на: комментарий от Love5an

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

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

Love5an
()
Ответ на: комментарий от www_linux_org_ru

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

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

Love5an
()
Ответ на: комментарий от Love5an

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

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

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

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

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

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

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от Love5an

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

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

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

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от Love5an

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

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

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

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

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

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

Love5an
()
Ответ на: комментарий от Love5an

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

кхм.

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

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от Love5an

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

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

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

Love5an
()
Ответ на: комментарий от www_linux_org_ru

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

Love5an
()
Ответ на: комментарий от Love5an

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

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

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от Love5an

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

-        x+=x<<2; // x == 5 power i
+        x += (0x3FFFFFF & x) << 2 ; 
+        x &=  0xFFFFFFF; // x == 5 power i (mod 2 power 28)
www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

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

navrocky ★★
() автор топика
Ответ на: комментарий от navrocky

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от navrocky

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

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

www_linux_org_ru ★★★★★
()
Ответ на: комментарий от www_linux_org_ru

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

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

navrocky ★★
() автор топика
Ответ на: комментарий от navrocky

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

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

www_linux_org_ru ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.