Как нужно зарабывать деньги на OpenSource

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

нет - они его генерируют под конкретное API сервера, потому я и спросил «что он будет дергать?»

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

Все то же самое, что и генерируемый C++, не?

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

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

для SP, триггеров, вьюшек и пр. - это вообще идеально будет

нет - они его генерируют под конкретное API сервера, потому я и спросил «что он будет дергать?»

Полагаю, он будет дергать функции из «конкретного API сервера». Какие-то проблемы с плюсовым ABI?

Какие-то проблемы с плюсовым ABI?

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

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

LLVM

LLVM

«very slowly...» - так характеризуют интерпретацию в llvm сами авторы, вы решили замедлить исполнение запросов? кроме того - повторю вопрос, озвученный выше, вы собираетесь писать свой компилятор под плюсовое ABI?

«very slowly...» - так характеризуют интерпретацию в llvm сами авторы, вы решили замедлить исполнение запросов?

До определенного порога она всё равно будет быстрее компиляции (и, стало быть, быстрее чем c++).

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

Не понимаю, в чем проблема. http://stackoverflow.com/questions/3104389/can-i-bind-an-existing-method-to-a...

До определенного порога она всё равно будет быстрее компиляции

под запрос создается своя VM, с набором команд заточенных под СУБД, наглядный пример реализации - sqlite, эту VM кешируешь, в случае частых повторных использований - транслируешь код VM на С++ и компилируешь, llvm быстрее не будет ни в случае однократного исполнения, ни в случае большой нагрузки

Не понимаю, в чем проблема

ты сам читал, что привел по ссылке? :)

под запрос создается своя VM, с набором команд заточенных под СУБД, наглядный пример реализации - sqlite, эту VM кешируешь, в случае частых повторных использований - транслируешь код VM на С++ и компилируешь, llvm быстрее не будет ни в случае однократного исполнения, ни в случае большой нагрузки

Таким образом, ты предложил сделать 2 независимых реализации одной и той же функциональности:
* самопальный интерпретатор байткода domain-specific VM (уверен, что получится быстрее, чем интерпретатор llvm?)
* транслятор байткода domain-specific VM в c++ код абстрактной машины

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

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

А как же лишняя работа по разбору компилятором c++ кода?

ты сам читал, что привел по ссылке? :)

Там описано, как звать c++ методы из jit-кода. Ты же с этой «проблемой» носился?

Таким образом, ты предложил сделать 2 независимых реализации одной и той же функциональности:
Это двойная работа по кодингу, это головная боль при поддержке, и, что хуже всего, удержание одинакового поведения двух абсолютно разных реализаций - это лютый, адский геморрой при модификациях VM.

любая сложная оптимизация должна быть опциональной, иначе - счастливо вам дебажить байткод llvm при разработке и поиске ошибок, ну и во-вторых - работы там немного, трансляция программы VM на С++ делается 1:1 и легко прикрывается интерфейсом, что не позволит пропустить реализацию

уверен, что получится быстрее, чем интерпретатор llvm?

а ты посмотри на код llvm для интерпретации - вопросы отпадут

А как же лишняя работа по разбору компилятором c++ кода?

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

Там описано, как звать c++ методы из jit-кода. Ты же с этой «проблемой» носился?

там не просто хак - там кривой хак, если ты этого не видишь - ты просто не знаешь куда лезешь

там не просто хак - там кривой хак, если ты этого не видишь

Ну а конкретнее, в чем проблема-то?

Если будет много одинаковых запросов - не проще ли просто кэшировать результаты? Если не одинаковые, но похожие, то как определять степень похожести?

LLVM не предназначен для интерпретации (хотя он умеет и это). Он рассчитан на компиляцию (и статическую, и JIT).

Если будет много одинаковых запросов - не проще ли просто кэшировать результаты?

вообще-то одинаковые запросы != одинаковые результаты, да и запросы бывают разные - на вставку, удаление, изменение etc.

LLVM не предназначен для интерпретации

знаю, но не я ж его выбрал для этого

У постгреса сто лет уже есть PREPARE ровно с той целью, чтобы не интерпретировать каждый раз одни и те же запросы, а тут, вишь, инновации.

У постгреса сто лет уже есть PREPARE ровно с той целью, чтобы не интерпретировать каждый раз одни и те же запросы

чтоб не парсить, а не интерпретировать

за 3 мегабакса

Вот здесь я споткнулся.

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

Как нужно зарабывать деньги на OpenSource (комментарий)

в конце

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

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

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

Поэтому, как я считаю, сия мера - ближайший аналог PREPARE.

вообще не то, PREPARE просто позволяет сохранить то, что уже и так было на руках

И ещё есть такой момент, что один и тот же запрос может обрабатываться разными сценариями в зависимости от собранной по базе статистики.

И ещё есть такой момент, что один и тот же запрос может обрабатываться разными сценариями в зависимости от собранной по базе статистики.

не проблема же - всегда можно сделать по другому

надо делать цикл

хотя конечно не все СУБД сделают это в интерпретаторе, неудачный пример

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

Щито? Как это вообще относится? Приводи тогда уж пример конкретного запроса, ибо я вообще не понял, чё ты хотел сказать: фильтрация всегда проводилась откомпилированным кодом.

вообще не то, PREPARE просто позволяет сохранить то, что уже и так было на руках

Опять, щито? PREPARE парсит запрос, составляетплан и сохраняет, если так можно выразиться, его в байт коде, что в следущий раз можно просто взять и по нему вызвать те самые low-level API и ничего больше не парсить. Какое, блин, и так на руках, ты о чём вообще?

Можно то можно, но надо будет перекомпилировать. Хотя, не уверен, что план запросов меняется действительно часто.

Щито? Как это вообще относится?

читай доки по sqlite, там сделано именно так

Опять, щито? PREPARE парсит запрос, составляетплан и сохраняет, если так можно выразиться, его в байт коде, что в следущий раз можно просто взять и по нему вызвать те самые low-level API и ничего больше не парсить. Какое, блин, и так на руках, ты о чём вообще?

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

читай доки по sqlite, там сделано именно так

Так ты объясни по-человечески, что именно «так» то?

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

воот, это мы осилили, а теперь давай осилим, зачем это нужно?

и даже больше - некоторые СУБД сами кешируют промежуточные данные, так что руками PREPARE вызывать не надо

Так ты объясни по-человечески, что именно «так» то?

проход по записям и проверки

воот, это мы осилили, а теперь давай осилим, зачем это нужно?

даю намек - на это тоже тратится время

Проход по записям отрабатывается в цикле интерпретатора? Что, серьёзно? И что, на каждый ряд парсится заново запрос, или что?

На что «на это»? На то, чтобы раз в жизни сделать PREPARE? Даю намёк, на компиляцию потратится больше.

Проход по записям отрабатывается в цикле интерпретатора? Что, серьёзно?

да

И что, на каждый ряд парсится заново запрос, или что?

нет конечно, откуда у тебя такая мысль вообще взялась

На то, чтобы раз в жизни сделать PREPARE?

и на это тоже, только тебя куда-то не туда понесло

Даю намёк, на компиляцию потратится больше.

я скажу даже больше - компиляция работает только в паре с «PREPARE»

нет конечно, откуда у тебя такая мысль вообще взялась

потому что иначе не понятно, откуда взялся оверхед:

1) запрос распарсили; 2) поняли чё надо делать; 3) в функции прошли по всем записям (если нет индекса), накопили ответ и вернули.

Как здесь компиляция поможет, кроме того, что уберёт первые фазы и сразу вызовет третью?

и на это тоже, только тебя куда-то не туда понесло

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

я скажу даже больше - компиляция работает только в паре с «PREPARE»

вот именно что, так в чём профит компиляции то? в том, что вместо цикла, который парсит и исполняет байт-код будут последовательные вызовы функций? так то хреновый профит, большая часть времени будет именно в этих функциях, а цикл этот не более, чем из десятка итераций. а в чём ещё? можно, конечно, из этих функций захреначить либу, линковать её и вызывать эти методы напрямую, но это уж совсем упороться надо, имхо, да и не JIT это уже никакой.

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

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

Я сказал, что это «нововведение» - суть PREPARE из постгреса, ты сказал, что вообще не то, вот это и пытаюсь выяснить - где разница зарыта.

Я сказал, что это «нововведение» - суть PREPARE из постгреса, ты сказал, что вообще не то

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

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

но постгрес

да не только он, даже sqlite это умеет

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

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

хотя опять же - это про postgre, а sqlite - да, шмалит все в байт-код под свою VM

Не суть, кто умеет, с чем больше общаюсь, про то и пишу :)

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

Чем эти порождённые структуры принципиально отличаются от байт-кода

тем, что это данные, а не программа - т.е. разница именно принципиальная

И что там могут быть за данные? Не понятно, как и зачем они туда попали. Я не буду сильно спорить, ибо в код постгреса я не лазил, но ман говорит: «When an EXECUTE command is subsequently issued, the prepared statement need only be executed.» Что, как мне кажется, очень похоже на то, что я описывал.

И что там могут быть за данные?

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

Что, как мне кажется, очень похоже на то, что я описывал.

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

Ну на том и сойдёмся, профит в фиче сомнителен.