Производительность C++

а твоя аргументация состояла лишь из мерзких оскорблений

Ну, поехали. Некий дебилоид, обильно расставляющий смайлики в своих текстах, заявил, что следовало бы возвращать из parse объект runtime_error. На просьбу показать код, этот дебилоид показывает вариант, в котором вообще нет runtime_error. Более того, показанный класс Error в принципе не предназначен для работы с динамическими строками (а ведь сообщения об ошибках являются таковыми). Тогда как использование std::string в picojson этой проблемы не имеет по определению.

Далее, в попытке ответить за свои слова дебилоид-со-смайликами показывает вариант с runtime_error, но что из себя этот вариант представляет?

А представляет этот вариант не что иное, как возврат все того же std::string-а все с теми же сценариями использования. Т.е. пустой std::string — нет ошибки, не пустой — есть ошибка.

Только вот сейчас этот std::string завернут в runtime_error (который наследуется от std::exception). Т.е. возврат все того же std::string из parse в варианте дебилоида-со-смайликами будет требовать не только конструирования std::string, но и вызова еще двух конструкторов (std::exception и std::runtime_error).

При этом стоит напомнить про то, что все это происходит в топике, где сравнивается производительность C++ относительно производительности C. А как раз из-за таких дополнительных накладных расходов в реальной жизни C++ный код немного, но проигрывает в скорости коду на C.

Итак, что мы видим в итоге: все тот же возврат строки из parse, но завернутый в никому ненужную обертку ради придури анонимного дебилоида.

И это пока только «по большому сверху» :)

Казалось бы, где Танненбаум, и где венда.

а твоя аргументация состояла лишь из мерзких оскорблений

Ну а теперь парочка частностей. Посмотрим на мегаговнофункцию ok():

std::runtime_error ok()
{
  return std::runtime_error("");
}

Если уж так хотелось возвратить runtime_error с пустой строкой, то можно было бы написать так: runtime_error(std::string()). Но это же C++ хоть чуть-чуть знать нужно.

Но все это херня по сравнению с тем, что в picojson вообще нет никаких накладных расходов на возврат пустого std::string. Ведь у авторов picojson нет смайликов в мозгах, поэтому им нет необходимости оборачивать std::string в никому не нужный здесь runtime_error.

Ну и совсем чуть-чуть про really_error. В случае с std::string-ом пользователю picojson-а не нужно ничего знать. Достаточно только интерфейса самого std::string. В случае с runtime_error от дурносмайлика пользователь parse должен помнить, что проверить содержимое возвращенного runtime_error нужно с помощью какой-то левой функции really_error, лежащей совсем в другом пространстве имен.

А вот про noexcept ничего вам объяснять не буду — вас учить, только портить :)

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

Ему и не надо в данном случае работать с динамическими строками :-) Цель была сделать конструктор noexcept, чтобы такой неидиоматичный API как в picojson оправдать под слабым козырем что «некоторые исключения ключами компилятора выключают» :-) Т.е. если этот неидиоматичный API для того, чтобы использовать его там, где исключения выключаются, то parse() должна быть с noexcept - нет исключений - это значит нет исключений, а это noexcept :-) Ну если тебе интеллекта не хватило const char* msg_ поменять на std::string в Error, раз тебе динамические строки нужны, то причём тут смайлик? :-)

При этом стоит напомнить про то, что все это происходит в топике, где сравнивается производительность C++ относительно производительности C. А как раз из-за таких дополнительных накладных расходов в реальной жизни C++ный код немного, но проигрывает в скорости коду на C.

Стоит напомнить что все такие оценки от чудо-оптимизаторов цепепе-кода гроша ломаного не стоят, пока не будет предъявлены результаты профилировщика :-)

Итак, что мы видим в итоге: все тот же возврат строки из parse, но завернутый в никому ненужную обертку ради придури анонимного дебилоида.

В итоге мы видим явные намерения программиста, который свой API посвящает любителям отключать исключения, а не ту несуразицу, где в качестве ошибки возвращается объекта класса, вообще для этого не предназначенный :-)

Цель была сделать конструктор noexcept

Вы тупой, поэтому повторю еще раз: вы не знаете, что такое noexcept и что с ним делать.

Что здесь будет происходить в STL-е, в котором для std::string нет small string optimization? А будет вызов new для создания строки, содержащей всего один ноль-символ.

Если уж до такой крайности доходить, что думать о таком «STL-е», то твой любимый цепепе лучше вообще не трогать палкой на расстоянии, а взять C :-)

Но все это херня по сравнению с тем, что в picojson вообще нет никаких накладных расходов на возврат пустого std::string. Ведь у авторов picojson нет смайликов в мозгах, поэтому им нет необходимости оборачивать std::string в никому не нужный здесь runtime_error.

У авторов picojson если неидиоматичный API, из-за чего, их либу лучше не трогать палкой на расстоянии :-)

В случае с runtime_error от дурносмайлика пользователь parse должен помнить, что проверить содержимое возвращенного runtime_error нужно с помощью какой-то левой функции really_error, лежащей совсем в другом пространстве имен.

В случае с runtime_error компилятор страхует от таких недоразумений, как std::cout << parse(..) :-) [Конечно, нормальный человек здесь подумает, что программист хочет вывести результат парсинга в cout, но это не про picojson :-) Лол :-)] Ты про безопасность типов слыхал что-нибудь вообще? :-) Или ты только new нулевых строк озабочен? :-)

Короче говоря, мне больше не интересно тут дискуссировать с тобой :-) У нас слишком разные подходы и точки зрения :-) Тем более, что ты нормально общаться не можешь, а у меня есть дела и по-важнее :-) Всего хорошего :-)

Всего хорошего

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

а по-моему он тут всех тролит, а все ведутся. Понятно же, что настолько идиотом быть невозможно, зачем кормить?

:-)

сколько весит ядро линукса 1.0?

Понятия не имею, но всяко больше кеша.

Ладно, ты вроде мне стал херню писать и решил хоть более-менее( с натяжкой конечно) по-человечески слиться.

Человеку я готов объяснить. Если грубо - вменяемый код имеет ipc от одного(в тех участках, где инлайн даёт профит - там ipc намного больше). В среднем от 2-х. Эта метрика конечно не уровня фронтенда, но насрать. Ты это всё можешь прочитать в мануале.

В основном код состоит из простых инструкций - это в среднем 4байта+ в зависимости от наличия инлайн данных/леа. Ну будем считать за 4.

Фронтенд может в 4простые инструкции за такт, т.е. он должен читать откуда-то по 16байт за такт(я не помню сколько именно байт он физически может считать, но это не важно) минимум в пике.

16байт за такт - это трупут на пределе возможностей l2 в современном штеуде, при этом надо понимать - что он ещё общий с данными. В конечном итоге реально l2 не хватает.

Т.е. для того, чтобы штеуд мог нормально исполнять код - он должен полностью лежать в l1i, который в том же современном штеуде 32кб на 2гипетреда.

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

При этом так же надо понимать, что С++-лапша обладает высоким ipc априори, ибо содержит тонну проверок - это всё либо тормозит, либо загружает неиспользуемое. Это одни из причин, почему нулёвые крестовики понаписали своих ифов и орут «не замедлилось» - не замедлилось это лишь по той причине, что твой код нихрена не делает.

А так же надо понимать что такое переход вне l1i - это просто поставленной раком исполнение на десяток тактов.

Что здесь будет происходить в STL-е, в котором для std::string нет small string optimization? А будет вызов new для создания строки, содержащей всего один ноль-символ.

http://en.cppreference.com/w/cpp/error/runtime_error

explicit runtime_error( const std::string& what_arg );    (1)
explicit runtime_error( const char* what_arg );           (2)    (since C++11)

Я плох в крестах, но там вызовется второй конструктор, нет?

Если уж до такой крайности доходить, что думать

Идеально.

у меня есть дела и по-важнее Всего хорошего

Уходи и не возвращайся.

Я плох в крестах, но там вызовется второй конструктор, нет?

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

Стоит напомнить что все такие оценки от чудо-оптимизаторов цепепе-кода гроша ломаного не стоят, пока не будет предъявлены результаты профилировщика :-)

В профайлер заглянете сами, а вот микробенчмарки показывают, что чудес не бывает. Лучшие результаты показаны под ArchLinux в виртуалке:

[     DONE ] ParseImit.picojson_approach(...) (669.353500 ms)
[   RUNS   ]        Average time: 66935.350 us
                         Fastest: 63999.950 us (-2935.400 us / -4.385 %)
                         Slowest: 71109.950 us (+4174.600 us / +6.237 %)

             Average performance: 14.93979 runs/s
                Best performance: 15.62501 runs/s (+0.68522 runs/s / +4.58657 %)
               Worst performance: 14.06273 runs/s (-0.87706 runs/s / -5.87063 %)
...
[     DONE ] ParseImit.smiley_approach(...) (846.955500 ms)
[   RUNS   ]        Average time: 84695.550 us
                         Fastest: 81682.950 us (-3012.600 us / -3.557 %)
                         Slowest: 94063.950 us (+9368.400 us / +11.061 %)

             Average performance: 11.80700 runs/s
                Best performance: 12.24246 runs/s (+0.43546 runs/s / +3.68816 %)
               Worst performance: 10.63107 runs/s (-1.17593 runs/s / -9.95961 %)

[     DONE ] ParseImit.picojson_approach(...) (1629.377980 ms)
[   RUNS   ]        Average time: 162937.798 us
                         Fastest: 160088.936 us (-2848.862 us / -1.748 %)
                         Slowest: 168252.857 us (+5315.059 us / +3.262 %)
                                  
             Average performance: 6.13731 runs/s
                Best performance: 6.24653 runs/s (+0.10922 runs/s / +1.77955 %)
               Worst performance: 5.94344 runs/s (-0.19388 runs/s / -3.15897 %)
...
[     DONE ] ParseImit.smiley_approach(...) (4794.915283 ms)
[   RUNS   ]        Average time: 479491.528 us
                         Fastest: 464195.658 us (-15295.870 us / -3.190 %)
                         Slowest: 498557.685 us (+19066.157 us / +3.976 %)
                                  
             Average performance: 2.08554 runs/s
                Best performance: 2.15426 runs/s (+0.06872 runs/s / +3.29513 %)
               Worst performance: 2.00579 runs/s (-0.07976 runs/s / -3.82426 %)

Так что в зависимости от платформы, компилятора и STL ваш вариант с возвратом runtime_error может или просто сосать, или сосать с проглотом.

ЗЫ. Код бенчмарков здесь.

ЗЗЫ. Для тех, кто переживает по поводу кормления тролля: просто воспользовался случаем попробовать один из фреймворков для микробенчмарков из вот этой статьи. Прикольной штукой оказался hayai, header-only, причем время компиляции сильно не увеличивает.

Понятия не имею

ЧТД. ну так вот, бинарники ядра 3-й даже версии весят 2МБ

http://superuser.com/questions/370586/how-can-a-linux-kernel-be-so-small

размер кеша моего старого core2duo — 11МБ. у современных процессоров он бывает ещё больше. как видите, в кеш легко вмещается ядро линукса, 1-й дум и эмулятор Dos, чтобы этот дум запустить)

По-твоему, у процессора только один кеш, единый и неделимый?

16байт за такт

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

нет, но вообще-то, у некоторых процессоров именно так

Так что куда влезет на core2duo в итоге?

начал искать про свой старый процессор — опа, клёво, что сказать, забавно у нас процессорами торгуют — когда покупал, на сайте магазина было написано, что кеш у него 11, на деле кеш у него — 4 всего лишь) хотя, тащем-то, мне без разницы

ну да всё равно, ядро линукса вместе думом поместятся в его L2 кеш целиком

Уходи и не возвращайся.

Зачем же так неуважительно-то? Мне, например, приведённые доводы всех собеседников помогли сделать для себя определённый вывод о языке Си++. Чем больше будет различных точек зрения на обсуждаемый вопрос, тем лучше, так как чем шире кругозор, тем больше вероятность принять верное решение в нужное время, а не мчаться с невероятной скоростью к собственному краху.
Например, пару недель назад сотрудники «Ростелекома» принесли мне домой свою телевизионную приставку для просмотра Инет-телевидения. Люди так увлеклись созданием этих приставок, что даже не видят, что многим людям они вообще не нужны! Мне, например, больше помогли бы плагин для «Коди» или программа для «умного» телевизора «Филипс» и для «яблочной» ТВ-приставки, которые уже установлены и прекрасно работают. «Ростелекомовцам» в самый раз помог бы независимый взгляд со стороны, например, людей, смотрящих «Нетфликс».
Я хочу сказать, что проявив немного уважения к собеседнику и приняв его мнение, можно хорошенько осмотреться вокруг и затем уже принимать взвешенное решение. Отказываться от Крестов прямо сейчас никто никого не призывает, это дело каждого из нас.

Ты точно не рекламный бот?

Если хочешь, то можно удалить название конторы. Я там не работаю.

Отказываться от Крестов прямо сейчас никто никого не призывает, это дело каждого из нас.

Ой, да ладно. Только в этом треде как минимум трое категорически против C++ настроены. Да и я сам один из тех, кто призывает не трогать C++, если только нет четкой уверенности в том, что приемлемой альтернативы нет.

ребяяяят!

а объясните мне, пожалуйста, что такое

IRQL

DPC

SEH

только так, чтобы я понял, ибо Си знаю и работаю с ним (каждый день, гыгы), а вот плюсы - нет

Толсто. Гугл для кого придумали?

Неуважительно? Человек неадекват, и на лоре, к счастью, моралфагов мало.

Советую «хорошенько осмотреться вокруг» и понять, что есть люди, с которым лучше вообще не разговаривать. Тем более учитывать их мнение.

Не, зря я конечно поверил в твои способности - нудаладно.

ЧТД.

Ты мне напишешь размер бинаря ведра1.0, либо опять сольёшься?

размер кеша моего старого core2duo

В целом ясно почему ты слился кору2 - попытался мне выкатить «современный интел», но обделался с л2 - бывает.

Причём тут размер кеша? Это размер llc который не обладает нужными ТТХ, чтобы из него можно было исполнять код.

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

11МБ

Куллстори.

у современных процессоров он бывает ещё больше.

Не бывает. У современных процессоров 256кило л2 на 2гипетреда. л3 от силы метров 6-8 на все вёдра. Т.е. 8метров надо поделить на 4.

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

Ну в целом доказывать что-то идиоту глупо. Трупут л2 в коре2 в пике 8байт/такт. При этом он один на 2ведра. И опять же - куда девать данные?

это много

Что много? Меня мало интересует выхлоп всяких лсных балаболов. Есть что ответить по-существу - выкатывай.

ну и не забывайте, что ваш процесс

Зачем ты мне выкатываешь свои лсные потуги? Они разобьются как и все остальные.

поэтому

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

Для рр это:

# cat  /proc/sys/kernel/sched_rr_timeslice_ms 
10

Для справки - 10мс - это 10/1000 секунды, при средней ТТ для современного штеуда 2.5ггц - это 10(2.5 * 10^9)/1000 = 10(2.5 * 10^6) - ну ты понял.

Дефолтный планировщик там конечно динамический, но порядки величин тот же.

(и по другим причинам)

С другими причинами получиться так же, как и с предыдущей. Одно дело просто болтать, а другое болтать что-то вменяемое.

обычные функции тоже в L1 кеше не висят постоянно

Опять же попытки к сливу. Причём тут обычные функции? Тебе говорили про горячий код, который всегда там весит.

они туда перезаписываются, как и инлайновые

О боже. Они перезаписываются на каждый инлайн, а не инлайновая существует в одном экземпляре.

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

Ты же там кукарекал, что понимаешь для чего нужен инлайн? И опять демонстрируешь тотальную лсность.

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

#include <stdint.h>
#include <stdio.h>


volatile uint64_t a = 0, b = 0;

inline void inc() {
  ++a;
}
__attribute_noinline__ void incnoi() {
  ++b;
}

#include <time.h>

double get_time_s(void) {
  struct timespec t;
  clock_gettime(CLOCK_REALTIME, &t);
  return (t.tv_nsec / 1e9) + t.tv_sec;
}

#define bench(n, f, ...) ({\
    uint64_t i = (n);\
    double start = get_time_s();\
    do { (void)f(__VA_ARGS__); } while(--i);\
    double time = get_time_s() - start;\
    fprintf(stderr, "%s(%.3f): %.3fcps\n", # f, time, (n / time));\
  })

int main(void) {
  uint64_t n = 1000 * 1000 * 1000ul;
  bench(n, inc);
  bench(n, incnoi);
}
inc(1.939): 515803737.744cps
incnoi(1.724): 580125836.965cps

Вот, просвещайся и не ретранслируй мне больше всякие поверья со днища.

От бренчмисса же инлайн не поможет.

Какие такие милисекунды? Ты на четыре порядка ошибся. Надеюсь, что это была тупо опечатка.

Фигасе, высеры царя кто-то читает.

Царь, покажи вывод

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>

int main() {
    if((malloc(SIZE_MAX))) {
        fprintf(stderr, "malloc never fails!\n");
        return 0;
    }
    size_t lb = 1, rb = SIZE_MAX;
    while(rb - lb > 1) {
        size_t m = lb + (rb - lb)/2;
        fprintf(stderr, "mallocing %zu... ", m);
        void *p = malloc(m);
        fprintf(stderr, "%p\n", p);
        if(p) {
            lb = m;
        } else {
            rb = m;
        }
        free(p);
    }
    ++lb;
    fprintf(stderr, "malloc starts failing at %zu, which is %.2f Gb.\n", lb, lb / 1024. / 1024. / 1024.);
    return 0;
}

Подробней. Минимум балабольства - максимум пруфвов.

Уважаемая ламерюга.

malloc(SIZE_MAX)

Я тебя уже обоссывал раньше десятки раз.

address sizes : 39 bits physical, 48 bits virtual

Когда твои пару извилин смогут выкласть мне что-то более-менее осмысленное - тогда приходи.

Для того, чтобы смешать тебя с мочёй мне достаточно спросить основание для этого высера: «malloc never fails!». В процессе потуги предоставления основания ты обделаешься 10раз, а в конце самовыпилишься как делал это десятки раз.

Я тебя уже обоссывал раньше десятки раз.

Ссылки?

address sizes : 39 bits physical, 48 bits virtual

Что это такое? Где вывод-то?

Для того, чтобы смешать тебя с мочёй мне достаточно спросить основание для этого высера: «malloc never fails!». В процессе потуги предоставления основания ты обделаешься 10раз, а в конце самовыпилишься как делал это десятки раз.

Обоснование чего? Это просто строчка. Я мог написать “malloc(SIZE_MAX) succeeded, which means your malloc() implementation is insane. Bye~”.

либ таких малая малость

$ find /usr/lib -name '*.so' -exec readelf -d {} \; | grep 'NEEDED.*libstdc++' -c
3852
$ find /usr/lib -name '*.so' | wc -l
9050

чо, правда что ли?

чо, правда что ли?

Как ты его уделал своим find.

тотальный игнор того факта, что это общий кеш. И в нём должен помещаться не только код, но и данные.

в 4-8МБ кеша может поместиться не только код но и данные при работе ядра

Т.е. 8метров надо поделить на 4.

а зачем? но даже если и поделить, ядро 3-ей версии, современное ядро, полностью влезает)

inline void inc() {
  a = ++a + 2;
}
__attribute_noinline__ void incnoi() {
  a = ++a + 2;
}


inc(2.269): 440791370.195cps
incnoi(2.341): 427088741.773cps

такие дела

Кеш не за «милисекунды» обновляется, как ты написал, а за сотни наносекунд. Четыре порядка разницы.

В отличие от некоторых, Царь хотя бы разбирается в том, о чем говорит. И когда косячит, как в этом случае, то это скорее всего не более чем опечатки.

В отличие от некоторых, Царь хотя бы разбирается в том, о чем говорит

Царь говорит либо мутный бред, либо унылые банальности. Правда, некоторым это нравится.

И когда косячит, как в этом случае, то это скорее всего не более чем опечатки.

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

Если папуасам вслух Ландавшица почитать, они это тоже за «мутный бред» сочтут.

Если папуасам вслух Ландавшица почитать

Царская писанина - Ландавшиц? Ну окей.

Он же написал русским языком - кеш за сотни тактов обновляется. А теперь ему приписывают какую-то ересь, какие миллисекунды, потому что не умеют читать тупо.

О понимании этой фразы иожешь поговорить с анонимусом выше.

Цытата:

Кеш обновлятся за сотни тактов - квант времени, который исполняется милисекунды.

Какие такие милисекунды?!?

Ой, да ладно. Только в этом треде как минимум трое категорически против C++ настроены. Да и я сам один из тех, кто призывает не трогать C++, если только нет четкой уверенности в том, что приемлемой альтернативы нет.

Когда ведущего игродела приставок «Сони» Майка Эктона спросили на выступлении на «Cppcon 2014» о том, почему он выбрал Си++ вместо Си, если при разработке игр он с товарищами не использует исключения, шаблоны, динамическое распознавание типов данных, потоки ввода-вывода Си++, стандартную библиотеку и перегрузку операторов, то он ответил, что лично он сам предпочёл бы использовать Си-99, а выбрать Си++ пришлось лишь из-за того, что в последние 20 лет был повышенный интерес к Си++ в обществе. Выходит, что количество числом побеждает качество.

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

Ты не мог бы процитировать, где он это сказал?

он ответил, что лично он сам предпочёл бы использовать Си-99

И это тоже.

Выходит, что количество числом побеждает качество.

Понять бы еще что вы подразумеваете под «качеством».