как такой ответ?

Не пойдёт.

Во сколько раз быстрее будут работать С-указатели на фунции вместо std::function? Во сколько раз будет быстрее работать прямой вызов (inline) вместо указателя на функцию?

Лучше тогда уж лямбды - они побыстрее std::function будут, т.к. их компилятор хорошо инлайнит (https://stackoverflow.com/questions/13722426/why-can-lambdas-be-better-optimized-by-the-compiler-than-plain-functions)

Друзья, добрый день! Я студент первого курса по программированию, опыта практического почти нет. Скажите пожалуйста, какие требования по знаниям для джуна? Спасибо.

Не пойдёт.

7.14 Functions Function calls may slow down a program for the following reasons:  The function call makes the microprocessor jump to a different code address and back again. This may take up to 4 clock cycles. In most cases the microprocessor is able to overlap the call and return operations with other calculations to save time.  The code cache works less efficiently if the code is fragmented and scattered around in memory.  Function parameters are stored on the stack in 32-bit mode. Storing the parameters on the stack and reading them again takes extra time. The delay is significant if a parameter is part of a critical dependency chain.  Extra time is needed for setting up a stack frame, saving and restoring registers, and possibly save exception handling information.  Each function call statement occupies a space in the branch target buffer (BTB). Contentions in the BTB can cause branch mispredictions if the critical part of a program has many calls and branches.

Друзья, добрый день! Я студент первого курса по программированию, опыта практического почти нет. Скажите пожалуйста, какие требования по знаниям для джуна? Спасибо.

Тебе в google сразу?)

Друзья, добрый день! Я студент первого курса по программированию, опыта практического почти нет. Скажите пожалуйста, какие требования по знаниям для джуна? Спасибо.

@supapro

Тебе в google сразу?)

Хехехех ну можно и Фейсбук, ладно уж))

Не пойдёт.

http://www.agner.org/optimize/optimizing_cpp.pdf

Лучше тогда уж лямбды - они побыстрее std::function будут, т.к. их компилятор хорошо инлайнит (https://stackoverflow.com/questions/13722426/why-can-lambdas-be-better-optimized-by-the-compiler-than-plain-functions)

К сожалению колбеки в интерфейс можно только Си-указателями на функции или std::function организовать (абстрактные функции не предлагать). Может что-то новое появилось?

https://www.boost.org/doc/libs/1_67_0/doc/html/function/misc.html#id1617757

К сожалению колбеки в интерфейс можно только Си-указателями на функции или std::function организовать (абстрактные функции не предлагать). Может что-то новое появилось?

лямбда без захвата идентична си-функции

и ещё кто-то про функтор забыл

7.14 Functions Function calls may slow down a program for the following reasons:  The function call makes the microprocessor jump to a different code address and back again. This may take up to 4 clock cycles. In most cases the microprocessor is able to overlap the call and return operations with other calculations to save time.  The code cache works less efficiently if the code is fragmented and scattered around in memory.  Function parameters are stored on the stack in 32-bit mode. Storing the parameters on the stack and reading them again takes extra time. The delay is significant if a parameter is part of a critical dependency chain.  Extra time is needed for setting up a stack frame, saving and restoring registers, and possibly save exception handling information.  Each function call statement occupies a space in the branch target buffer (BTB). Contentions in the BTB can cause branch mispredictions if the critical part of a program has many calls and branches.

Я не про hardware часть спрашивал. Inline тела функции он по определению будет быстрее вызова через указатель. Вопрос в том, насколько в среднем он будет быстрее, по Вашему опыту.

Я не про hardware часть спрашивал. Inline тела функции он по определению будет быстрее вызова через указатель. Вопрос в том, насколько в среднем он будет быстрее, по Вашему опыту.

так, стоп. по МОЕМУ опыту нехуй таким заниматься и отдать это на откуп компилятору почти всегда будет норм решением

http://www.agner.org/optimize/optimizing_cpp.pdf

О, Спасибо!!

используешь инлайн - раздуваешь код - проседает кеш инструкций и так далее

с другой стороны вызовов меньше

О, Спасибо!!

рекомендую к прочтению не эти книги, а все остальные. Книга по оптимизации С++ у Агнера наиболее слабая, имхо

Друзья, добрый день! Я студент первого курса по программированию, опыта практического почти нет. Скажите пожалуйста, какие требования по знаниям для джуна? Спасибо.

https://meduza.io/quiz/ruby-ili-perl-ugadayte-yazyk-programmirovaniya-po-kodu

https://meduza.io/quiz/ruby-ili-perl-ugadayte-yazyk-programmirovaniya-po-kodu

Тогда уж сразу https://tproger.ru/quiz/cpp-quiz/

Тогда уж сразу https://tproger.ru/quiz/cpp-quiz/

Мозгодробительный тест. Проходя его уже устал. 3/7.

А что используется в алгоритмах с++17 вместо get_temporary_buffer|? new, delete`?

Хорошая книга для начинающего в c++ ?

кто знает встроенный метод сортировки массива по убыванию? Типо sort(a, a + n), только по убыванию?

Хорошая книга для начинающего в c++ ?

Герберт Шилдт

кто знает встроенный метод сортировки массива по убыванию? Типо sort(a, a + n), только по убыванию?

Компаратор в std::sort.

Спс

Спс.

А что используется в алгоритмах с++17 вместо get_temporary_buffer|? new, delete`?

Не совсем понял вопрос

Не совсем понял вопрос

http://en.cppreference.com/w/cpp/memory/get_temporary_buffer написано, что deprecated, а что тогда использовать?

http://en.cppreference.com/w/cpp/memory/get_temporary_buffer написано, что deprecated, а что тогда использовать?

ну я думаю до 23 его не удалят

Есть вектор из объектов (с некими полями из строк и чисел) Нужно написать программу, для поиска объектов, подходящих по заданным условиям Т.е. может быть [Такое-то поле (переменная) больше/меньше/равно/... Какому-то числу] И/ИЛИ [Такая-то строка равна/не равна/... чему-то] Т.е. по сути simple sql parser Есть какие-нить идеи элегантной реализации?

Может-быть как-то помещать нужные функции (сравнения) в вектор? Т.е. создать функцию для '>', '==' А остальные сравнения - можно от этих двух вывести

Но как реализовывать оператор ИЛИ

Где-то в голове крутится элегантное решение, с уровнями вложенности и чем-то подобным Но, не могу достать Нет идей?

Есть вектор из объектов (с некими полями из строк и чисел) Нужно написать программу, для поиска объектов, подходящих по заданным условиям Т.е. может быть [Такое-то поле (переменная) больше/меньше/равно/... Какому-то числу] И/ИЛИ [Такая-то строка равна/не равна/... чему-то] Т.е. по сути simple sql parser Есть какие-нить идеи элегантной реализации?

boost::multiindex не поможет?

Для хранения данных

boost::multiindex не поможет?

Охота свой костыль, с целью, хмм, да просто ради интереса даже

http://en.cppreference.com/w/cpp/memory/get_temporary_buffer написано, что deprecated, а что тогда использовать?

использовать new/delete. Именно это предлагает Стандарт

Где-то в голове крутится элегантное решение, с уровнями вложенности и чем-то подобным Но, не могу достать Нет идей?

Создам класс Expression. В нём 4 переменные - Expression *left, *right; bool isTrue; enum Operator { '&&', '||'} Парсим входную строку, разрезаем на правую и левую часть - и так, пока не останется только одно вырадение (аля first>5), тогда устанавливаем isTrue Это не сильно, кхем, плохо?

Создам класс Expression. В нём 4 переменные - Expression *left, *right; bool isTrue; enum Operator { '&&', '||'} Парсим входную строку, разрезаем на правую и левую часть - и так, пока не останется только одно вырадение (аля first>5), тогда устанавливаем isTrue Это не сильно, кхем, плохо?

Если хочется навелосипедить свой парсер, можешь порыться в моем не очень сложном велосипеде на php: https://github.com/iassasin/phplate/blob/master/src/TemplateLexer.php Его основная идея в том, что есть prefix операторы, infix и postfix, у каждого есть свой уровень, который учитывается при поиске обработчика этого оператора (функция findOperator). Начинать погружение в парсер можно с функции parseExpression. Вот тут я его еще пытался перенести на плюсы, но тут только абстрактная реализация: https://github.com/iassasin/configen/blob/master/src/parser/synparser/lexer_expression.hpp По идее, если определить к нему таблицу операторов с уровнями и их обработчики, должно заработать, но я не проверял, время как то кончилось, некогда было велосипедить дальше. В общем, если будет полезно, прошу.

Создам класс Expression. В нём 4 переменные - Expression *left, *right; bool isTrue; enum Operator { '&&', '||'} Парсим входную строку, разрезаем на правую и левую часть - и так, пока не останется только одно вырадение (аля first>5), тогда устанавливаем isTrue Это не сильно, кхем, плохо?

почитай дракона

А вообще что бы лезть в такие вещи желательно для начала разобратья с теорией формальной грамматики, позыркать примеры

почитай дракона

Зачем? Генерируешь лексер и пишешь парсер через рекурсивный спуск (как парсят большинство реальных языков), никакой особой теории тут не надо.

А чо парсер?

Вы считаете что язык запроса из парсера состоит?

А планировать исполнение вы не собираетесь?

ну прежде чем что-то планировать, сначала нужно спарсить, что именно

планировать - это уже отдельная сложная задача, конечно

Ну lex/bison поможет

И можно планировать! :)

ну Alex хочет свой велосипед для парсера)

Пусть хочет велосипед для планировщика!

Это интереснее

есть кто не спит ?

есть кто не спит ?

Нет таких

Во сколько раз быстрее будут работать С-указатели на фунции вместо std::function? Во сколько раз будет быстрее работать прямой вызов (inline) вместо указателя на функцию?

В 200. В 20000.

В 200. В 20000.

Серезно? ?

Вопрос на самом деле очень странный. Std function хранится в куче, и на создание идет оверхед, но он минимален. Во время вызова тот же самый косвенный вызов получается. Все пользуются виртуальными функциями и не говорят что прям оверхед ппц. А вторая часть вопроса. Инлайн дает 0 оверхед, это даже не вызов, по этому вопрос ВО СКОЛЬКО БОЛЬШЕ дает ответ в бесконечность. Любой даже минимальный оверхед будет в бесконечность раз дольше. Правило следующее, не париться перформансом пока не припрет, читаемость и масштабируемость на начальных этапах важнее чем мнимый перформанс

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

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

только когда инлайн множественный

Серезно? ?

Ага

Вопрос на самом деле очень странный. Std function хранится в куче, и на создание идет оверхед, но он минимален. Во время вызова тот же самый косвенный вызов получается. Все пользуются виртуальными функциями и не говорят что прям оверхед ппц. А вторая часть вопроса. Инлайн дает 0 оверхед, это даже не вызов, по этому вопрос ВО СКОЛЬКО БОЛЬШЕ дает ответ в бесконечность. Любой даже минимальный оверхед будет в бесконечность раз дольше. Правило следующее, не париться перформансом пока не припрет, читаемость и масштабируемость на начальных этапах важнее чем мнимый перформанс

Вот так вот непринужденно Кирилл сформулировал заново известное правило "premature optimization is the root of evil": "Не парься пока не припрёт".

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

Наоборот. Ему надо что-то в кэш положить, а оно уже там есть

Вот так вот непринужденно Кирилл сформулировал заново известное правило "premature optimization is the root of evil": "Не парься пока не припрёт".

ну вдруг он архитектор, и хочет выжать из сервера максимум)

Профи т

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

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

ага, это единственное с чем они помогают

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

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

уж лучше написать гору непортабельного кода на асме

банальщина, это даже ЧСВ не потешит и пацанов не удивишь

Наоборот. Ему надо что-то в кэш положить, а оно уже там есть

не совсем понял. С такой логикой сама функция тоже в кэш попасть может.

Что ж непонятно?

Inlinening ускоряет, я объясняю почему

но обьяснение про попадание в кэш подходит и не к заинлайненой функции

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

Ваша правда, но это уже черная магия кешмисы считать)

Ваша правда, но это уже черная магия кешмисы считать)

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

Что ж непонятно?

Тут имелся ввиду например инлайн вызов при луп анролинге, там простыня вызовов будет

Ваша правда, но это уже черная магия кешмисы считать)

Хехе. Значит я в чёрные маги записался. Даже хуже

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

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

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

все так, особенно если и несколько компилеров надо поддерживать. Это ж сказка

все так, особенно если и несколько компилеров надо поддерживать. Это ж сказка

и несколько поколений процессоров

ЗАТО БЫСТРЕЕ!!!1!

написал кучу кода на асме, и тебя не уволят

Ух ё, кто пришел!

но обьяснение про попадание в кэш подходит и не к заинлайненой функции

Как же? У тебя у НЕЗАинлайненной функии одно тело. У ЗАинлайненой -- много, но одинаковые.

Как же? У тебя у НЕЗАинлайненной функии одно тело. У ЗАинлайненой -- много, но одинаковые.

И тела разные могут быть, после того как по ним оптимизатор проедет

Не понято как кэш должен догадваться об том что это одно и то же.

Как же? У тебя у НЕЗАинлайненной функии одно тело. У ЗАинлайненой -- много, но одинаковые.

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

НЕЗАинлайненная фукция будет просто в одном экземпляре. Её не нужно 20 раз подгуржать. ЗАинлайненная будет в 20-30 экземлярах а код один и тот же, подгружать в кэш не надо...

Как же? У тебя у НЕЗАинлайненной функии одно тело. У ЗАинлайненой -- много, но одинаковые.

совсем не факт, что одинаковые, оптимизатор же каждый раз честно свою работу делает

Да даже если код один и тот же, я пока не понял до конца. Разве кеш инструкций не просто на адрес ориентируется при работе? Там есть дедубликация?

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

Вообще, это с моей стороны был гон чистой воды, но и вы,братья, хороши. Как же можно нести такую чушь, что inline раздувает код и даёт оверхед, что он в кэш хуже попадает, и (подразумевается) что изза этого становится медленнее ? Кэш -- вообще штука непредсказуемая, поэтому его влияние на скорость работы кода обсуждать практически бессмысленно. У программиста нет средств влият на то, будет загружен код или данные в кэш. По факту inlining -- один из самых эффективных методов оптимизации, потому что он УБИРАЕТ ПРОЛОГ И ЭПИЛОГ маленьких функций и работает в более благоприятном как раз для кэшей режиме.