LINUX.ORG.RU

[бенчмарк] С++ медленне С в 5 раз при уже при 0.1% кидаемых исключений [ЧЯДНТ ?]


0

2

Вот исходники

#include <stdio.h>

#define BITS 10    // 0<=BITS<=16

unsigned int i0=0, i1=0;

int f(unsigned int arg)
{
    if( ( (arg>>16) & ((1<<BITS)-1) ) == 0 )
        return 1; // exception
    else
        ++i0; // do some good work here, i.e. increment i0
    return 0; // ok
}
int main()
{
    unsigned int i=0, x=1;

    do {
        ++i;
        x+=x<<2; // x == 5 power i
        if( f(x) )
            ++i1; // exception
    }
    while(x!=1);

    printf("i=%u i0=%u i1=%u i0+i1=%u\n", i,i0,i1,i0+i1 );
    printf("  %u    %u    %u       %u\n", 0x40000000u, i-i1, (1<<(16-BITS))<<14, 0x40000000u );
    return 0;
}

#include <stdio.h>

#define BITS 10    // 0<=BITS<=16

unsigned int i0=0, i1=0;
class E1 {};
E1 e1;

void f(unsigned int arg)
{
    if( ( (arg>>16) & ((1<<BITS)-1) ) == 0 )
        throw &e1;
    else
        ++i0; // do some good work here, i.e. increment i0
}
int main()
{
    unsigned int i=0, x=1;

    do {
        ++i;
        x+=x<<2; // x == 5 power i
        try{ f(x); }
        catch( E1* e ){ ++i1; }
    }
    while(x!=1);

    printf("i=%u i0=%u i1=%u i0+i1=%u\n", i,i0,i1,i0+i1 );
    printf("  %u    %u    %u       %u\n", 0x40000000u, i-i1, (1<<(16-BITS))<<14, 0x40000000u );
    return 0;
}

Вот выхлопы [ gcc (GCC) 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) ]:

$ gcc -O3 1.c && time ./a.out 
i=1073741824 i0=1072693248 i1=1048576 i0+i1=1073741824
  1073741824    1072693248    1048576       1073741824

real    0m2.368s
user    0m2.256s
sys     0m0.004s

$ g++ -O3 1.cxx && time ./a.out 
i=1073741824 i0=1072693248 i1=1048576 i0+i1=1073741824
  1073741824    1072693248    1048576       1073741824

real    0m11.741s
user    0m10.921s
sys     0m0.008s

Кто сможет протестить на icc, других версиях gcc и других железках? Возможно, я не указал полезные опции? А дальше флейм :-)

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

> <Ъ> Всегда, когда это возможно, следует придерживаться точки зрения "обработка исключений является обработкой ошибок" </Ъ>

У меня это правило соблюдено:

http://www.linux.org.ru/jump-message.jsp?msgid=3856841&cid=3857670

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

> <Ъ> Всегда, когда это возможно, следует придерживаться точки зрения "обработка исключений является обработкой ошибок" </Ъ>

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

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

> речь конкретно о модели conditional'ов из CL.

Сдается мне, что ее можно реализовать через передачу в функции middle & low замыканий.

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

>Сдается мне, что ее можно реализовать через передачу в функции middle & low замыканий.

не понял. поясни. что есть middle & low замыкания?

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

> теперь-то я точно знаю, за что не люблю Страуструпа!

Всегда рад помочь %)

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

> не понял. поясни. что есть middle & low замыкания?

middle & low это названия функций из главы, на которую ты дал ссылку

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

>middle & low это названия функций из главы, на которую ты дал ссылку

ох ты ж, циклическая ссылка на самого себя. сча посмотрим, что там так называют...

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

>В каком стиле писать -- в стиле проверки кодов возврата или стиле
>кидания исключений? Все согласны, что стиль кидания исключений яснее,

>и кроме того (в яве при поддержке компилятора) позволяет проверить,

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

>"ошибка") не забыт быть проверенным.


+1, но начальник группы не принимает этот стиль ни под каким соусом - с отмашкой - если ты ловишь ошибки эксепшенами то у тебя не верный алгоритм... Переубедить пока не получается...

PS: Понятно, что злоупотреблять поимкой ошибок эксепшенами не всегда хорошо.

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

> Да? Вспомним хотя бы то, что sort не инлайнит compare.

Все просто. Пишется кастомный вариант sort под заданный тип. Получаем наивысшую возможную (после ассемблера) скорость обработки. Без темплейтов.

Чистый С - это низкоуровневый язык. Область его применения ограничена. Это - главная его проблема.

Я думаю, что ООП прикручен к C++ несколько "в-лоб". Иногда это дает эффективные решение. Иногда - неэффективные. Но не бывает универсальных методов. Почти везде можно найти изъяны. У всех :)

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

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

Полный бред. Термин "ошибка" вообще неправильно использован. Невозможно обрабатывать в программах _ошибки_, пока не появились программы, которые пишут сами себя.

Ошибка == баг. В рантайме не обрабатываеся априори.

Невозможность разобрать строку из файла (например) - исключительная ситуация, а не ошибка.

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

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

> Полный бред.

Ну да, кто такой Страуструп по сравнению с 4-м анонимусом ЛОРа...

> Ошибка == баг. В рантайме не обрабатываеся априори.

> Невозможно обрабатывать в программах _ошибки_, пока не появились программы, которые пишут сами себя.

Не пытайся умничать - у тебя слишком смешно получается.

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

>Не пытайся умничать - у тебя слишком смешно получается.

Я кому-то продлил жизнь? Я рад :)

Суть моей мысли была в том, что я согласен с jtootf.

Ты, короче, не прочитал, или не понял. Ладно, исходить слюной не буду - лень.

anonymous4
()

Проблемы не существует

Непонятно из-за чего сыр-бор. Если стряслась беда, если не распарсился файл, не открылся девайс, не ответил сервер, нет в кране воды - то придёт человек-грызлов и молча поправит всё^W^W^W^W^W^W^W то ты обязан пожаловаться пользователю (в лог, на консоль или в гуй). Накладные расходы при этом будут многократно превышать таковые от любых обработок исключений.

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

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