на стороне вызывающего нельзя гарантировать невозможность их модификации
Приведите мне код вызывающий функцию в Google C++ Style, и я вам только по этому вызову на 100% скажу, какие переменные могут быть изменены, а какие нет.
Если бы вы писали код в Google C++ Style, то функция выглядела бы так:
void func(int const& a, int *b) {}
А код вызова так:
int a, b; func(a, &b);
Откуда очевидно, что a — не меняется, b — меняется.
В C такое не получиться.
Код вызова вашей функции:
int a, b; func(&a, &b);
Это крайне важно, когда вы не хотите, чтобы ваша переменная менялась при использовании чужой функции, которую её автор может поменять, а падать будет у вас.
Спасибо за оригинальную статью. Для данной задачи это намного проще.
Действительно у меня в статье есть избыточность во внешней раскрутке наличия полей, переехавшей без изменений из первой статьи, и используется избыточное число комбинаций в перестановке отсутствующих полей. Это сделано для упрощения понимания статьи, о чем там и написано. И то пришлось разделить на две.
Подобные оптимизации используются в production, но конкретно эта задача не из production, а из каких-то тестовых задач на просторах интернета. Если постановка задачи отойдет от оригинальной, то:
Мой вариант не подойдет для большого количества полей. Съест всю память и загнется на компиляции.
Ваш вариант не подойдет для типов long long, double, и других пользовательских типов (статических строк и т.д.).
При использовании разных типов будет проблематично использовать и SSE, хотя в случае SoA можно.
Почему я не использую аппаратно-зависимые CPU SIMD-инструкции? Если есть условия для использования SIMD — нам не критична аппаратная независимость, и задача действительно хорошо ложиться на SIMD, как например в сравнениях при использовании SoA, то она реализуется на CUDA GPU.
Выбор между SOA-AOS (в терминах СУБД это DSM-NSM) многократно подробно описан. Если совсем упрощенно то:
— SOA(DSM) используется при доступе к большому проценту строк и малому проценту полей, например в аналитике на Bigdata
— AOS(NSM) используется при доступе ко всем полям (или большому проценту полей) и к малому проценту строк остающимся после Index Seek/Index Range Scan, например в Highload веб-сервисах
Т.е. выбор будет зависеть от селективности посылаемых поисковых запросов.
В моем примере показана лишь малая часть реализации поиска, только та, что касается аппаратно-независимой оптимизации на шаблонах. В реальности дополнительно используются индексы и много чего ещё.
Насколько я понял под промежуточным вы имели вариант PAX, который используется в Oracle ExadataV2. Там он используется в первую очередь для улучшения сжатия, и во-вторую для улучшения cache-friendly.
Вы действительно думаете, что я сейчас вам вышлю ТЗ реальной задачи, где все это решено и дам VPN в банки, где это практически применено, что у вас в голове вообще происходит?
Послушайте, есть реальные проекты с реальными данными, на которых это реально дает существенный профит.
Не упадет, вы не знаете что такое IOT и стратегия IOS, вы плохо в этом разбираетесь потому, что подобные оптимизации применяются для последовательного доступа после сужения поиска при Index Range Scan используя IOT/IOS. Мы уже убедились, у вас может упасть что угодно, хоть компилятор, хоть доступ к строкам, которые вы додумались аллоцировать отдельно. Надеюсь больше не надо объяснять, что аппаратно зависимые вещи не предмет статей о кросс-аппаратной оптимизации через шаблоны?
Google рекомендует при любой возможности использовать const, если нет необходимости в обратном. Если нет необходимости в адресной арифметике, то для изменяемых параметров он отдает предпочтение: T *const.
Скажу больше. Эта статья написана только для того, чтобы проще было понять вторую статью.
Вторая статья о кросс-аппаратной оптимизации через шаблоны, и очень странно ждать рассказы об аппаратно-зависимых кэшах.
К тому же строка занимает 8 байт и выровнена по границам кэшей.
Исходя из выше сказанного, все ваши голословные придирки не подтвержденные кодом, и воспринимаются как не уместные.
Конкретно в данной постановке задачи поиска полным проходом, с данным числом и типами полей, prefetching-cache ничего не даст, о чем написано в первой главе.
Стоимость разработки и сопровождения большая. Такая оптимизация применяется только в дорогих решениях и в критически важных местах.
Если в результате подобной оптимизации, мы снижая стоимость, экономим 1-10 млн, то оно того стоит.
Разница в цене 1 и 100 серверов в 100 раз, не считая скидок. Разницы в кросс-аппаратной оптимизации одного ПО для 1 и 100 серверов нет. Это ПО можно будет использовать и в будущем на новых серверах. А за железо каждый раз надо платить. Поэтому, это применимо только для фирм думающих наперёд.
Поверьте, аппетиты фирм и объем данных растут гораздо сильнее, чем дешевеет оборудование.
А насчет auto и lambda, конечно старый стандарт C++03 убогий и громоздкий по сравнению с новым C++11.
Куда уж мне до вас знающего C, C++ и ещё 5 языков программирования.
Вы действительно думаете, что я сейчас буду гадать, что за фантазии пришли в вашу голову, которые вы стесняетесь прямо сказать в виде кода?
Только вы могли придумать использовать для скоростного поиска строки аллоцируемые отдельно от элемента.
Ну-ну успокойтесь же) Представьте, что у вас два строковых поля, как бы вы их не стали хранить, без кеш-промаха тут не обойдется.
Конкретно эти примеры и статьи — чисто хобби. Подобные кросс-аппаратные оптимизации на шаблонах используются в реальных проектах для расчета аналитики в банковских хранилищах данных. Необходимы кросс-аппаратные оптимизации, т.к. исполнятся могут на Windows-HPC, AIX, HP-UX, Solaris, Linux. Или на CUDA GPU.
Научитесь пользоваться компилятором GCC 4.7.2 на ideone.com, тогда может кто-то захочет с вами дискутировать.
Справедливости ради замечу, что действительно в моем примере нет полноценного бенчмарка. Он будет в третье статье, в более реальном примере с Ordered Hash/IOT/IOS.
Подумайте, как инлайновые функции можно использовать в задаче кодогенерации (подсказка: устранение константных выражений при оптимизации).
Вы у меня видели не inline функции, кроме main() и тех, что должны быть виртуальными?
я использую и Си и C++ и еще штук пять других языков
Использовать языки и знать их — это разные вещи.
«Сами придумали — сами обиделись». Только вы могли придумать использовать для скоростного поиска строки аллоцируемые отдельно от элемента.
Я не считаю никого идиотом. Мне все равно. Меня интересуют только решение и результат.
Разница в том, что мой аргумент рабочий пример и результат тестов, а ваш аргумент, что вам скучно. И от скуки пишите что попало.
Т.е. вы обсуждаете то, что даже не смогли скомпилировать? Попросите кого-нибудь скомпилировать за вас. Могу только доказать, что это возможно: GCC 4.7.2 на ideone.com
Когда осилите скомпилировать и предложите свой вариант — продолжим.
В С есть макросы и инлайновые функции, так что не все так плохо, как вы пытаетесь показать.
Что значит есть инлайновые функции, как будто я их здесь не использовал при сравнении?
Ну, а использовать макросы вместо шаблонов, что зря теоретизировать, приведите решение на них и вы увидите почему так делать нельзя никогда.
Также я бы хотел увидеть красивое решение для инициализации массива с 32 специализированными функциями поиска, для выбора оптимальной реализации в рантайме.
Если вам не лень писать 32 специализированных функций на C, выкладывайте пример. А потом вам вдруг приходит задача добавить 2 поля, и вы пишите уже 128 функций :)
На C++ шаблоны пишутся быстрее и гораздо гибче при изменении числа полей и их названий.
Также, интересны какой эффект будет при отказе от битфилдов.
Приведите мне код вызывающий функцию в Google C++ Style, и я вам только по этому вызову на 100% скажу, какие переменные могут быть изменены, а какие нет.
Если бы вы писали код в Google C++ Style, то функция выглядела бы так:
А код вызова так:
Откуда очевидно, что a — не меняется, b — меняется.
В C такое не получиться.
Код вызова вашей функции:
Это крайне важно, когда вы не хотите, чтобы ваша переменная менялась при использовании чужой функции, которую её автор может поменять, а падать будет у вас.
Из всех предлагаемых вариантов осталась только не раскрыта тема LLVM в рантайме :)
Действительно у меня в статье есть избыточность во внешней раскрутке наличия полей, переехавшей без изменений из первой статьи, и используется избыточное число комбинаций в перестановке отсутствующих полей. Это сделано для упрощения понимания статьи, о чем там и написано. И то пришлось разделить на две.
Подобные оптимизации используются в production, но конкретно эта задача не из production, а из каких-то тестовых задач на просторах интернета. Если постановка задачи отойдет от оригинальной, то:
Мой вариант не подойдет для большого количества полей. Съест всю память и загнется на компиляции.
Ваш вариант не подойдет для типов long long, double, и других пользовательских типов (статических строк и т.д.).
При использовании разных типов будет проблематично использовать и SSE, хотя в случае SoA можно.
Почему я не использую аппаратно-зависимые CPU SIMD-инструкции? Если есть условия для использования SIMD — нам не критична аппаратная независимость, и задача действительно хорошо ложиться на SIMD, как например в сравнениях при использовании SoA, то она реализуется на CUDA GPU.
Выбор между SOA-AOS (в терминах СУБД это DSM-NSM) многократно подробно описан. Если совсем упрощенно то:
— SOA(DSM) используется при доступе к большому проценту строк и малому проценту полей, например в аналитике на Bigdata
— AOS(NSM) используется при доступе ко всем полям (или большому проценту полей) и к малому проценту строк остающимся после Index Seek/Index Range Scan, например в Highload веб-сервисах
Т.е. выбор будет зависеть от селективности посылаемых поисковых запросов.
В моем примере показана лишь малая часть реализации поиска, только та, что касается аппаратно-независимой оптимизации на шаблонах. В реальности дополнительно используются индексы и много чего ещё.
Насколько я понял под промежуточным вы имели вариант PAX, который используется в Oracle ExadataV2. Там он используется в первую очередь для улучшения сжатия, и во-вторую для улучшения cache-friendly.
Через T const& нельзя менять значение.
Не упадет, вы не знаете что такое IOT и стратегия IOS, вы плохо в этом разбираетесь потому, что подобные оптимизации применяются для последовательного доступа после сужения поиска при Index Range Scan используя IOT/IOS. Мы уже убедились, у вас может упасть что угодно, хоть компилятор, хоть доступ к строкам, которые вы додумались аллоцировать отдельно. Надеюсь больше не надо объяснять, что аппаратно зависимые вещи не предмет статей о кросс-аппаратной оптимизации через шаблоны?
Вторая статья о кросс-аппаратной оптимизации через шаблоны, и очень странно ждать рассказы об аппаратно-зависимых кэшах.
К тому же строка занимает 8 байт и выровнена по границам кэшей.
Исходя из выше сказанного, все ваши голословные придирки не подтвержденные кодом, и воспринимаются как не уместные.
Конкретно в данной постановке задачи поиска полным проходом, с данным числом и типами полей, prefetching-cache ничего не даст, о чем написано в первой главе.
Если в результате подобной оптимизации, мы снижая стоимость, экономим 1-10 млн, то оно того стоит.
Разница в цене 1 и 100 серверов в 100 раз, не считая скидок. Разницы в кросс-аппаратной оптимизации одного ПО для 1 и 100 серверов нет. Это ПО можно будет использовать и в будущем на новых серверах. А за железо каждый раз надо платить. Поэтому, это применимо только для фирм думающих наперёд.
Поверьте, аппетиты фирм и объем данных растут гораздо сильнее, чем дешевеет оборудование.
А насчет auto и lambda, конечно старый стандарт C++03 убогий и громоздкий по сравнению с новым C++11.
Вы действительно думаете, что я сейчас буду гадать, что за фантазии пришли в вашу голову, которые вы стесняетесь прямо сказать в виде кода?
Спасибо Кэп.
Справедливости ради замечу, что действительно в моем примере нет полноценного бенчмарка. Он будет в третье статье, в более реальном примере с Ordered Hash/IOT/IOS.
Вы у меня видели не inline функции, кроме main() и тех, что должны быть виртуальными?
Использовать языки и знать их — это разные вещи.
«Сами придумали — сами обиделись». Только вы могли придумать использовать для скоростного поиска строки аллоцируемые отдельно от элемента.
Я не считаю никого идиотом. Мне все равно. Меня интересуют только решение и результат.
Разница в том, что мой аргумент рабочий пример и результат тестов, а ваш аргумент, что вам скучно. И от скуки пишите что попало.
Т.е. вы обсуждаете то, что даже не смогли скомпилировать? Попросите кого-нибудь скомпилировать за вас. Могу только доказать, что это возможно: GCC 4.7.2 на ideone.com
Когда осилите скомпилировать и предложите свой вариант — продолжим.
Прочитайте последнюю главу второй статьи, там упоминается кое-что об упорядоченным хэш-индексе.
Что значит есть инлайновые функции, как будто я их здесь не использовал при сравнении?
Ну, а использовать макросы вместо шаблонов, что зря теоретизировать, приведите решение на них и вы увидите почему так делать нельзя никогда.
Если вам не лень писать 32 специализированных функций на C, выкладывайте пример. А потом вам вдруг приходит задача добавить 2 поля, и вы пишите уже 128 функций :)
На C++ шаблоны пишутся быстрее и гораздо гибче при изменении числа полей и их названий.
Это оффтопик. Но что вам мешает попробовать?