Здравствуйте, alex_public, Вы писали:
_>И наверное поэтому внутренности многих наших топовых банков (это так, для примера) чуть ли не полностью состоят из PL-SQL...
Это, в смысле, те 4% кода, которые не Java?

Здравствуйте, alex_public, Вы писали:

_>Для СУБД можно взглянуть например на sqlpp11 — готовая библиотека, построенная в точности по тем техникам, которые я тут описывал.
А с тех пор

Автор: gandjustas
Дата: 02.07.16

уже что-то поменялось? Или это по-прежнему низкокачественная игрушка для написания кода без шансов на повторное использование?
_>Это если говорить про решения типа Linq для РСУБД. А если говорить не только о реляционных, то тут много чего интересного можно посмотреть, недоступного текущей реализации Linq. Например по поводу исполнения произвольного кода внутри СУБД можно взглянуть на PySpark.

Здравствуйте, alex_public, Вы писали:

_>Для СУБД можно взглянуть например на sqlpp11 — готовая библиотека

Уже разбирали, слабое подобие.

_>Например по поводу исполнения произвольного кода внутри СУБД можно взглянуть на PySpark.

Глупо сравнивать с линком что то, не умеющее в строгую типизацию. Потому что линк, он как раз про строгую типизацию.

Здравствуйте, alex_public, Вы писали:

_>>>И какое отношение имеет "цепочка джойнов" к обсуждаемому нами примеру?
НС>>Т.е. пофик на реальные потребности, давайте обсуждать примитивный пример? Браво!
_>Речь здесь шла про вполне конкретный пример, а не про вообще.

Речь шла про свойства линка. А твои попытки спрятаться за примитивным примером выглядят забавно.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Речь шла про свойства линка. А твои попытки спрятаться за примитивным примером выглядят забавно.
Да нет, он для 2d данных более-менее прав.
В том смысле, что даже цепочка фильтров будет выглядеть не шибко лучше в query comprehension по сравнению с method call syntax:

var r = from d in image select (d[-1,0]+d[1,0]+d[0,0]+d[0,-1]+d[0,1])/5 into a
  select a[-1,1]+a[-1,0]+a[-1,-1]-a[1,1]-a[1,0]-a[1,-1]

против

var = image.Filter(d=>(d[-1,0]+d[1,0]+d[0,0]+d[0,-1]+d[0,1])/5)
  .Filter(a=>a[-1,1]+a[-1,0]+a[-1,-1]-a[1,1]-a[1,0]-a[1,-1])

Оба в любом случае проиграют по читаемости

var filter = Gauss(3) * EdgeDetect(3, Pi/2); 
var r = image * filter;

Тут ведь нет ни затейливых проекций, ни джойнов, которые требуют четырёх аргументов в method call syntax, ни цепочек order by.

Здравствуйте, Sinclair, Вы писали:

_>>Эээ что? Библиотека Eigen основана на статическом метапрограммирование, с помощью которого в нужных местах алгоритмов размещаются интринсики компилятора (считай ассемблерные SIMD команды),...
S>Я в семнадцатый раз поясняю, что такой подход несовместим с использованием кода вида
S>

S>for(int i=1; i<W-1;i++) for (int j=1; j<H-1;j++) dst[i,j]=(src[i-1,j]+src[i,j-1]+src[i+1,j]+src[i,j+1])/4;
S>

S>На всякий случай повторно разжую, помедленнее: если вы напишете такой код, то не будет никаких интринсиков, SIMD, многопоточности, и прочих "учётов целевой архитектуры". Только "автовекторизация gcc", способности которой ограничены.

Естественно. Т.к. изначально такой цели и не ставилось.

S>Чтобы всё это использовать, вам придётся отказаться от явного выписывания for и временных переменных. От вашего кода останется только лямбда, которую вы будете скармливать в библиотеку.

С чего бы это? Ты похоже путаешь написание библиотеки, предоставляющие подобные возможности для произвольного пользовательского алгоритма, и использование SIMD в нашем конкретном алгоритме. Для реализации последнего нужен тот же самый for (только итераций у его внутреннего цикла будет в 4 или 8 раз меньше) и запись нашей "формулы" не через операторы языка, а через интринсики (ну и плюс парочка дополнительных операций перед и после "формулы" — загрузка и выгрузка данных).

S>Это — ровно подход linq. Единственная разница, малосущественная для прикладного программиста — это статика против динамики.
S>То есть Eigen рассчитывает на то, что прикладной программист заранее знает, на какой архитектуре будет исполняться его программа. Что требует недюжинных прогностических способностей.
S>Подход дотнета — позднее связывание, в широком смысле слова.
S>У него есть свои преимущества — в частности, возможности оптимизации без перекомпиляции.

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

Т.е. это решение конкретной задачи и конкретная польза. А что даёт Linq в данном случае? Пока что судя по разговору вообще ничего.

Если же взять те случаи, про которые ты говоришь (с динамическим анализом заданного в коде AST), то почему-то ни одного примера кода собственно реализации (а не использования) чего-то подобного тут пока не было. Неужели народ стесняется продемонстрировать как удобно на Linq записывать различные алгоритмы через рантаймовый анализ AST? )))

_>>Хы, я здесь под убогостью конкретной реализации подразумевал не твой код для 2D фильтрации, а само устройство Linq. )))
S>"Само устройство" linq — великолепно. Его крайне трудно существенно улучшить, оставаясь в рамках платформы.

Да, да, просто великолепно. Особенно та часть, где используется рефлексия и где надо проводить весь разбор каждый раз. Просто гениально.

И не надо кивать на платформу. Если бы Linq был реализован в виде библиотеки, поверх существующего компилятора, то я бы согласился с подобными оправданиями. Но оно реализовано внутри компилятора! А при таком подходе можно было сделать что угодно и как угодно.

_>>Собственно вся эта СУБД создана для тех случаев, когда мы можем удобно уложить нашу задачу в атомарность документа (это на самом деле очень много случаев, т.к. документ может быть очень сложным и заменять собой грубо говоря все таблицы). И в этих случаях включается тот самый механизм ключ->что-то (в данном случае документ), который и позволяет nosql решением автоматическое масштабирование на произвольное число узлов.
S>Если вы замените одним документом все таблицы, то монга умрёт, не взлетев. На практике, найти задачу, в которой нет связей между "документами", крайне сложно.

Ты точно понял, про что я говорил? Документов естественно множество, но только один их тип (одна коллекция) на всю БД. И случаев таких полно. Скажем действуем по схеме Пользователь->Документ и это покрывается огромное число задач в вебе. В РСУБД для таких задач обычно будет множество таблиц, связанных между собой.

_>>>>Т.е. по сути ты хочешь усложнять жизнь квалифицированных специалистов, решающих сложные задачи, ради более безопасной (у них не будет возможности выстрелить себе в ногу) жизни слабых специалистов, решающих типовые задачи.
S>>>Нет, я хочу помочь квалифицированным специалистам избежать типичных ловушек. Вот вы уже написали свой "идеальный" код по фильтрации 2d-массива, и с гордостью смотрите на "отстающих".
S>>>И вдруг оказывается, что если бы вы писали этот код в "неестественном" виде, на C#, без "оптимальных" for(), то могли бы лёгким движением руки отправить на исполнение в CUDA, и получить 80х ускорение.
S>>>А ваш "идеальный" код придётся выбрасывать чуть менее, чем полностью.

_>> Предлагаю ознакомиться со стандартом OpenAcc (доступен например в gcc с 6-ой версии) и его отношением с "for". )))
S>Не вижу ничего интересного. Опять закаты солнца вручную — то есть вместо того, чтобы автоматически оптимизировать пользовательский код, среда требует от меня вручную выполнять разметку кода. И всё равно не факт, что результат после применения прагм выйдет не хуже, чем после банального pixel_wize(...).

Это OpenAcc то закат солнца вручную? ))) Вообще то как раз наоборот, это скорее как раз самый простой на данный момент способ реализовать вычисления на GPU. Все остальные (ну для Python'а есть аналогичный инструмент под названием Numba) существующие подходы гораздо неудобнее, т.к. предполагают использование отдельных специальных языков для GPU кода.

Здравствуйте, Sinclair, Вы писали:

_>>Для СУБД можно взглянуть например на sqlpp11 — готовая библиотека, построенная в точности по тем техникам, которые я тут описывал.
S>А с тех пор

Автор: gandjustas
Дата: 02.07.16

уже что-то поменялось? Или это по-прежнему низкокачественная игрушка для написания кода без шансов на повторное использование?

Ничего не поменялось — текст по твоей ссылке как был враньём в то время, так и остался им сейчас.

И кстати в той дискуссии можно так же увидеть и мой ответ https://rsdn.org/forum/flame.comp/6495622.1

Автор: alex_public
Дата: 08.07.16

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

Здравствуйте, alex_public, Вы писали:



_>С чего бы это? Ты похоже путаешь написание библиотеки, предоставляющие подобные возможности для произвольного пользовательского алгоритма, и использование SIMD в нашем конкретном алгоритме. Для реализации последнего нужен тот же самый for (только итераций у его внутреннего цикла будет в 4 или 8 раз меньше) и запись нашей "формулы" не через операторы языка, а через интринсики (ну и плюс парочка дополнительных операций перед и после "формулы" — загрузка и выгрузка данных).
Мы ходим по кругу. После того, как вы переделаете ваш for на SIMD, учтёте возможную некратность размеров 8ми или 4м, добавите загрузку/выгрузку, вы получите плохо читаемый и мало поддерживаемый код.
Который ещё и работает не везде, т.к. вы прибили его гвоздями к конкретной архитектуре.

_>Т.е. это решение конкретной задачи и конкретная польза. А что даёт Linq в данном случае? Пока что судя по разговору вообще ничего.
Linq проектировался под конкретную задачу, и для конкретной задачи (работа с RDBMS) у нас есть linq2db. Который позволяет писать статически верифицируемый легко читаемый код.
И при этом побить его в производительности — крайне тяжело. В частности, на C++ ничего подобного пока не появилось.

Сделать аналог Eigen на основе linq можно — я показал как. Просто это — большой объём нудной работы, которую непонятно, как монетизировать.

_>Если же взять те случаи, про которые ты говоришь (с динамическим анализом заданного в коде AST), то почему-то ни одного примера кода собственно реализации (а не использования) чего-то подобного тут пока не было. Неужели народ стесняется продемонстрировать как удобно на Linq записывать различные алгоритмы через рантаймовый анализ AST? )))
Ну, для одномерных коллекций и, в частности, массивов, есть хардкор вроде RoslynLinqRewrite и LinqOptimizer. См. http://mattwarren.org/2016/09/29/Optimising-LINQ/
Там как раз рантаймовый анализ AST, и всё, чего вы хотели.

_>Да, да, просто великолепно. Особенно та часть, где используется рефлексия и где надо проводить весь разбор каждый раз. Просто гениально.
В Linq ничего про рефлексию нету. И "проводить анализ каждый раз" необязательно. Хотя по моим экспериментам, для 2d-фильтрации кэширование оптимизированного кода даёт выигрыш меньше стат. шума.

_>И не надо кивать на платформу. Если бы Linq был реализован в виде библиотеки, поверх существующего компилятора, то я бы согласился с подобными оправданиями. Но оно реализовано внутри компилятора! А при таком подходе можно было сделать что угодно и как угодно.
Linq и реализован в виде библиотеки.

_>Ты точно понял, про что я говорил? Документов естественно множество, но только один их тип (одна коллекция) на всю БД. И случаев таких полно. Скажем действуем по схеме Пользователь->Документ и это покрывается огромное число задач в вебе. В РСУБД для таких задач обычно будет множество таблиц, связанных между собой.
В таком случае никакой атомарности на уровне документа не выйдет. Вы, конечно, можете попробовать запихать все "товары" в "заказ", а все "заказы" в "покупателя", но первая же задача, где надо искать заказы по привязке к складу или по производителю, убъёт все ваши "оптимизации".

_>>> Предлагаю ознакомиться со стандартом OpenAcc (доступен например в gcc с 6-ой версии) и его отношением с "for". )))
S>>Не вижу ничего интересного. Опять закаты солнца вручную — то есть вместо того, чтобы автоматически оптимизировать пользовательский код, среда требует от меня вручную выполнять разметку кода. И всё равно не факт, что результат после применения прагм выйдет не хуже, чем после банального pixel_wize(...).

_>Это OpenAcc то закат солнца вручную? ))) Вообще то как раз наоборот, это скорее как раз самый простой на данный момент способ реализовать вычисления на GPU. Все остальные (ну для Python'а есть аналогичный инструмент под названием Numba) существующие подходы гораздо неудобнее, т.к. предполагают использование отдельных специальных языков для GPU кода.
На C# перевод операций на GPU в существующих на данный момент библиотеках ограничивается навешиванием атрибутов на методы.
И это я считаю неудобным и избыточным. Нормальный способ — это просто писать код нужной нам математики, и пусть среда исполнения решает, куда мне его положить.
А все способы, где я вручную должен выписывать количество физических потоков и перечислять входы-выходы — это каменный век.

Здравствуйте, alex_public, Вы писали:

_>Да, да, просто великолепно. Особенно та часть, где используется рефлексия и где надо проводить весь разбор каждый раз. Просто гениально.

В прошлый раз ты оглушительно слился и так и не смог показать, где же та самая рефлексия, из за которой всё тормозит. Ты не путаешь linq с его конкретной реализацией ?

Здравствуйте, Sinclair, Вы писали:

_>>С чего бы это? Ты похоже путаешь написание библиотеки, предоставляющие подобные возможности для произвольного пользовательского алгоритма, и использование SIMD в нашем конкретном алгоритме. Для реализации последнего нужен тот же самый for (только итераций у его внутреннего цикла будет в 4 или 8 раз меньше) и запись нашей "формулы" не через операторы языка, а через интринсики (ну и плюс парочка дополнительных операций перед и после "формулы" — загрузка и выгрузка данных).
S>Мы ходим по кругу. После того, как вы переделаете ваш for на SIMD, учтёте возможную некратность размеров 8ми или 4м, добавите загрузку/выгрузку, вы получите плохо читаемый и мало поддерживаемый код.
S>Который ещё и работает не везде, т.к. вы прибили его гвоздями к конкретной архитектуре.

Так а я не понял, что собственно ты предлагаешь в данной ситуации? Вот смотри, я при решение подобных задач следую достаточно простому плану:
1. смотрю есть ли готовая реализация в какой-то библиотек (ну например тот же Eigen) и если есть, то использую её.
2. если готовой реализации нет, то пишу сам. Но не обобщённую библиотеку, а решение конкретной задачи (и соответственно записываю просто через for).

А что предлагаешь ты сделать во втором случае со своим подходом? Ты предпочтёшь заняться написанием своей обобщённой реализации со сложным метапгораммированием как в Eigen (или же со сложным рантаймовым разбором AST на Link, что по сути почти тоже самое, только медленнее)? Ты понимаешь насколько порядков дольше будет решаться наша конкретная задача при таком подходе?

_>>Т.е. это решение конкретной задачи и конкретная польза. А что даёт Linq в данном случае? Пока что судя по разговору вообще ничего.
S>Linq проектировался под конкретную задачу, и для конкретной задачи (работа с RDBMS) у нас есть linq2db. Который позволяет писать статически верифицируемый легко читаемый код.
S>И при этом побить его в производительности — крайне тяжело. В частности, на C++ ничего подобного пока не появилось.

Вообще то быстродействие генератора SQL'я — это вопрос актуальный далеко не для всех задач (т.к. разницу в быстродействие можно понять только на очень быстрых запросах, на которых время генерации sql строки и обработки результата оказывается сравнимым со временем исполнения запроса в СУБД). Но если уж заниматься им, то очевидно что все варианты linq к СУБД имеют существенные накладные расходы в сравнение со статическими генераторами (типа sqlpp11). Причём виновата в этом как раз реализация Linq.

S>Сделать аналог Eigen на основе linq можно — я показал как. Просто это — большой объём нудной работы, которую непонятно, как монетизировать.

Если делать по настоящему (с анализом AST, а не с лямбдами, как ты показал), то да, возможно и получится что-то приличное. Правда из-за существенных накладных расходов в рантайме оно будет иметь смысл только при работе с очень тяжёлыми задачами (в то время как Eigen будет всегда быстрее обычного кода, т.к. не имеет накладных расходов). А в варианте с лямбдами во-первых не получится ничего похожего, а во вторых там Linq был вообще ни к чему.

_>>Если же взять те случаи, про которые ты говоришь (с динамическим анализом заданного в коде AST), то почему-то ни одного примера кода собственно реализации (а не использования) чего-то подобного тут пока не было. Неужели народ стесняется продемонстрировать как удобно на Linq записывать различные алгоритмы через рантаймовый анализ AST? )))
S>Ну, для одномерных коллекций и, в частности, массивов, есть хардкор вроде RoslynLinqRewrite и LinqOptimizer. См. http://mattwarren.org/2016/09/29/Optimising-LINQ/
S>Там как раз рантаймовый анализ AST, и всё, чего вы хотели.

Хыхы, ты бы лучше эту ссылку в контексте подобной дискуссии не светил бы. А то там столько всего рассказано о проблемах кода с Linq... Это я так, просто к слову.

А по поводу AST речь была о другом. Ты вот сам называешь это хардкором, но при этом похоже предлагаешь всем заниматься написанием подобного. Или ты считаешь, что есть готовые реализации под всех существующие алгоритмы? Но в данной дискуссии мы не смогли найти готовое решение даже для банального двоичного поиска...

_>>Да, да, просто великолепно. Особенно та часть, где используется рефлексия и где надо проводить весь разбор каждый раз. Просто гениально.
S>В Linq ничего про рефлексию нету. И "проводить анализ каждый раз" необязательно. Хотя по моим экспериментам, для 2d-фильтрации кэширование оптимизированного кода даёт выигрыш меньше стат. шума.

Ну давай глянем на пример работы какого-нибудь известного Linq к СУБД (на конкретный код генерации SQL по AST) и увидим есть там рефлексия или нет. И выполняется ли весь процесс нуля каждый раз или нет.

_>>И не надо кивать на платформу. Если бы Linq был реализован в виде библиотеки, поверх существующего компилятора, то я бы согласился с подобными оправданиями. Но оно реализовано внутри компилятора! А при таком подходе можно было сделать что угодно и как угодно.
S>Linq и реализован в виде библиотеки.

Ой, а кто же это у нас тогда генерирует AST для Linq?

_>>Ты точно понял, про что я говорил? Документов естественно множество, но только один их тип (одна коллекция) на всю БД. И случаев таких полно. Скажем действуем по схеме Пользователь->Документ и это покрывается огромное число задач в вебе. В РСУБД для таких задач обычно будет множество таблиц, связанных между собой.
S>В таком случае никакой атомарности на уровне документа не выйдет. Вы, конечно, можете попробовать запихать все "товары" в "заказ", а все "заказы" в "покупателя",

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

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

Глупости какие. Mongo умеет отлично искать во вложенных объектах. Более того, при существенных объёмах это будет ещё и намного быстрее, чем в РСУБД, т.к. мы сможем одним нажатием кнопки распараллелить такой поиск на тысячи ядер.

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

Однако такая функциональность нужна далеко не всегда и для очень большого класса задач подход Mongo (и других подобных nosql решений) предоставляет отличноe автоматически масштабирующееся решение.

_>>Это OpenAcc то закат солнца вручную? ))) Вообще то как раз наоборот, это скорее как раз самый простой на данный момент способ реализовать вычисления на GPU. Все остальные (ну для Python'а есть аналогичный инструмент под названием Numba) существующие подходы гораздо неудобнее, т.к. предполагают использование отдельных специальных языков для GPU кода.
S>На C# перевод операций на GPU в существующих на данный момент библиотеках ограничивается навешиванием атрибутов на методы.

Ну т.е. в точности подход OpenACC/Numba. ))) Кстати, кинь ссылочку глянуть на реализацию.

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

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

Здравствуйте, alex_public, Вы писали:

_>Так а я не понял, что собственно ты предлагаешь в данной ситуации? Вот смотри, я при решение подобных задач следую достаточно простому плану:
_>1. смотрю есть ли готовая реализация в какой-то библиотек (ну например тот же Eigen) и если есть, то использую её.
_>2. если готовой реализации нет, то пишу сам. Но не обобщённую библиотеку, а решение конкретной задачи (и соответственно записываю просто через for).
_>А что предлагаешь ты сделать во втором случае со своим подходом? Ты предпочтёшь заняться написанием своей обобщённой реализации со сложным метапгораммированием как в Eigen (или же со сложным рантаймовым разбором AST на Link, что по сути почти тоже самое, только медленнее)? Ты понимаешь насколько порядков дольше будет решаться наша конкретная задача при таком подходе?
Алгоритм решения более-менее любой задачи примерно одинаков:

1. пишем максимально понятный и короткий код. Особенно — если алгоритм, с которым мы работаем, достаточно сложен.
   
2. добиваемся корректности этого кода. Например, приведённый код для вычисления средних значений неверен — он теряет "крайние" элементы массива, и неверно обрабатывает переполнения. Достаточно напороться на четыре соседа по одному миллиону, чтобы на выходе получить отрицательное значение "среднего".
   
3. только после того, как корректность задачи достигнута, и экспериментально обнаружена недостаточная производительность, начинаем оптимизацию. При этом у нас всегда есть baseline-реализация, с которой мы можем сравнивать наши результаты, чтобы случайно не потерять корректность в результате оптимизаций.
   
4. при прочих равных, оптимизации не должны затрагивать "основной" код, т.е. мы оптимизируем не "цикл", а функцию Select.
   Это позволяет нам сохранить maintainability кода — когда через год нам придётся вернуться к задаче, мы сможем оперативно изменить логику, не теряя корректности.

_>Вообще то быстродействие генератора SQL'я — это вопрос актуальный далеко не для всех задач (т.к. разницу в быстродействие можно понять только на очень быстрых запросах, на которых время генерации sql строки и обработки результата оказывается сравнимым со временем исполнения запроса в СУБД). Но если уж заниматься им, то очевидно что все варианты linq к СУБД имеют существенные накладные расходы в сравнение со статическими генераторами (типа sqlpp11). Причём виновата в этом как раз реализация Linq.
Вы опять не понимаете значение слова "быстродействие". Задача не в том, чтобы быстро генерировать SQL. А в том, чтобы получающийся SQL был быстрым. Пользователя интересует полное время исполнения запроса. Поэтому если мы можем потратить 100мс на оптимизацию SQL, но выиграть в стоимости его исполнения 500мс, то надо так и делать. А не говорить "ой, но 100мс — это жуткие накладные расходы, я лучше просто склею строки и пусть там СУБД разбирается".

_>Если делать по настоящему (с анализом AST, а не с лямбдами, как ты показал), то да, возможно и получится что-то приличное. Правда из-за существенных накладных расходов в рантайме оно будет иметь смысл только при работе с очень тяжёлыми задачами (в то время как Eigen будет всегда быстрее обычного кода, т.к. не имеет накладных расходов). А в варианте с лямбдами во-первых не получится ничего похожего, а во вторых там Linq был вообще ни к чему.
Анализ AST нужен не сам по себе, а для конкретной прикладной задачи. Например, в linq2db он позволяет выполнять трансформации запроса таким образом, чтобы СУБД не умерла. Любой идиот может скомбинировать две проекции вот так:

select Id from (select Id, LastName, OrderCount from (Customers left outer join (select CustomerID, Count(OrderID) from Orders group by CustomerID) on Customers.ID == CustomerID)

При этом ни одна известная мне СУБД не догадается скипнуть indexScan, group by и Join. По примерно тем же причинам, которые на дают дотнетовому JIT особенно развернуться в оптимизациях.
А вот взрослый движок в сервере приложений запросто может обнаружить семантическую эквивалентность, и на сервер уедет

select Id from Customers

При этом надо понимать, что такая "странная" проекция, сформулированная в исходной задаче, возникает вовсе не из-за того, что программист — тупой. А, например, из-за того, что внутрненний запрос порождается в одном модуле, написанном в 2014 году командой из Испании, а внешний запрос из него строится совсем в другом модуле, который пишет команда в Сингапуре. И заставлять сингапурскую команду забить на повторное использование кода и вручную писать SQL вплоть до конкретных таблиц — контрпродуктивно. Во-первых, у них и так есть чем заняться, а во вторых это стрельнет нам ещё через год, когда испанская команда выкатит своё обновление, сохраняя, естественно, все внешние контракты.
Тут-то и разъедется весь "высокооптимизированный" код, написанный поклонниками идеи "я просто пишу свой собственный цикл".

S>>Ну, для одномерных коллекций и, в частности, массивов, есть хардкор вроде RoslynLinqRewrite и LinqOptimizer. См. http://mattwarren.org/2016/09/29/Optimising-LINQ/
S>>Там как раз рантаймовый анализ AST, и всё, чего вы хотели.

_>Хыхы, ты бы лучше эту ссылку в контексте подобной дискуссии не светил бы. А то там столько всего рассказано о проблемах кода с Linq... Это я так, просто к слову.
Там, где вы видите "проблемы", я вижу решения.
_>А по поводу AST речь была о другом. Ты вот сам называешь это хардкором, но при этом похоже предлагаешь всем заниматься написанием подобного. Или ты считаешь, что есть готовые реализации под всех существующие алгоритмы? Но в данной дискуссии мы не смогли найти готовое решение даже для банального двоичного поиска...
Я не согласен с вашим подходом к решению задач. Вы пишете в стиле Форт: снизу вверх. "Где тут у вас двоичный поиск"?
Я предпочитаю писать решения "сверху вниз". Тогда, возможно, и двоичный поиск не понадобится.

_>Ну давай глянем на пример работы какого-нибудь известного Linq к СУБД (на конкретный код генерации SQL по AST) и увидим есть там рефлексия или нет. И выполняется ли весь процесс нуля каждый раз или нет.
Вы опять путаете интерфейс и реализацию. В самом Linq обязанности использовать рефлексию нету — я показал вам пример кода, который выполняет усреднение элементов вообще без рефлексии.
А вот здесь

Автор: Sinclair
Дата: 27.06.18

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

public static T[,] Select<T>(this T[,] source, Kernel<T> kernel) => GenerateFilter(kernel)(source);

кэширование, и мы будем получать готовый фильтр по его ядру за O(1):

public static T[,] Select<T>(this T[,] source, Kernel<T> kernel) => _cache.GetFilter(kernel, GenerateFilter)(source);

Потому что делегат, в отличие от ExpressionTree, один и тот же.
(Для того, чтобы покрыть все случаи, придётся незначительно усложнить эту схему — чтобы кэшировать фильтры не по всему делегату, а по указателю на метод. kernel.Target останется свободным параметром).

_>Ой, а кто же это у нас тогда генерирует AST для Linq?
В том примере, который привёл я — никто.

_>Да, это как раз основной сценарий использования документоориентированных СУБД.
Ага. Комментарии по поводу этого сценария обычно собирают много лайков на профильных сайтах.
_>Глупости какие. Mongo умеет отлично искать во вложенных объектах. Более того, при существенных объёмах это будет ещё и намного быстрее, чем в РСУБД, т.к. мы сможем одним нажатием кнопки распараллелить такой поиск на тысячи ядер.
Вы опять предлагаете залить проблему деньгами. Там, где SQL выдаст результат за 200мс на сервере за $2000, вы предлагаете поставить 1000 серверов по $1000.

_>Ну т.е. в точности подход OpenACC/Numba. ))) Кстати, кинь ссылочку глянуть на реализацию.
https://devblogs.nvidia.com/hybridizer-csharp/
https://archive.codeplex.com/?p=cudafy

_>Ну если ты сделаешь такое решение и при этом оно не будет отставать в производительности от "ручных" аналогов, то все будут только рады. Однако пока что ничего подобного не наблюдается...
Мы опять ходим по кругу. Вот пример решения в Video++:

// Compute the average of the c4 neighborhood.
pixel_wise(relative_access(A), B) | [] (auto a, int& b) {
  b = (a(-1, 0) + a(1, 0) + a(0, 1) + a(0, -1)) / 4;
};

Здесь нет никаких циклов for, никаких OpenCV прагм или SIMD-интринсиков. Тупо лямбда. Плюс визуальный мусор. Сравнивая с

// Compute the average of the c4 neighborhood.
B = from a in A select (a[-1, 0] + a[1, 0] + a[0, 1] + a[0, -1]) / 4

я вижу только ухудшение читаемости. При этом от "ручного аналога", написанного на том же C#, этот код не отстаёт.

Здравствуйте, alex_public, Вы писали:

_>С чем "рядовой разработчик сталкивается каждый первый раз"?
С тем, что требования меняются прямо в момент написания.

_>И наверное поэтому внутренности многих наших топовых банков (это так, для примера) чуть ли не полностью состоят из PL-SQL...
Полностью? На PLSQL там только legacy код, на который даже смотреть боятся, да и тот на яве.

Здравствуйте, alex_public, Вы писали:

_>Но в любом случае даже красиво записанная рекурсия (что уже не реально в текущем SQL) всё равно намного менее удобна чем простенький императивный цикл.
Если отвыкнуть мыслить циклами, то многое станет удобнее и интереснее )

Здравствуйте, alex_public, Вы писали:

_>Ну так если это очевидное "грязное" решение по написанию рекурсивных лямбд так же элементарно подходит и для linq, то тогда почему поддержка CTE появилось только на днях и только в одной (далекое не самой популярной) Linq библиотеке?
Потому что грязное и неудобное.

_>Так а если кто-то уже пострадал и написал, то уж тогда то пользователю разницы нет, правильно? )
То что написано для всех, называется linq. А так, каждому пользователю, приходится писать самому, свой собственный велосипед.

Здравствуйте, alex_public, Вы писали:

_>А это что по твоему?
Это предложение бесплатно поработать.

_>Тебе уже несколько человек приводили разные конкретные примеры, демонстрирующие случаи, в которых SQL подход будет бесполезен, а MapReduce спокойно работает.
Вот вы опять делаете вид, что не понимаете вопроса. MapReduce — это механизм, SQL — это язык запросов. SQL можно использовать, чтобы работать поверх MapReduce. Зачем в MR что-то еще помимо SQL?

_> Но ты продолжаешь говорить что ответ на вопрос нет.
Потому что его таки нет. Вы отвечаете не на то что спрашивают, а на то что удобно отвечать. Ну и зачем тогда вообще тратить на тебя время при таком твоём подходе к общению?

Здравствуйте, alex_public, Вы писали:

_>Вообще то быстродействие генератора SQL'я — это вопрос актуальный далеко не для всех задач (т.к. разницу в быстродействие можно понять только на очень быстрых запросах, на которых время генерации sql строки и обработки результата оказывается сравнимым со временем исполнения запроса в СУБД). Но если уж заниматься им, то очевидно что все варианты linq к СУБД имеют существенные накладные расходы в сравнение со статическими генераторами (типа sqlpp11). Причём виновата в этом как раз реализация Linq.

Что это за "быстрые" запросы такие ? Сеть между сервером и базой, дисковый ввод-вывод разве ктото отменял ? Или у тебя сеть и диск работают сравним со склейкой строк ?
Вот если сказать, что склейка строки будет сравнима со временем выборки из локального кеша — тогда это похоже на правду. Только при чем здесь БД ?

_>Ну давай глянем на пример работы какого-нибудь известного Linq к СУБД (на конкретный код генерации SQL по AST) и увидим есть там рефлексия или нет. И выполняется ли весь процесс нуля каждый раз или нет.

В прошлый раз смотрели linq2db. Что на этот раз с ним не так ?

S>>Linq и реализован в виде библиотеки.

_>Ой, а кто же это у нас тогда генерирует AST для Linq?

Ты путаешь 1 linq, 2 query comprehension и 3 Expression<T>. Это три разные вещи.

1 это только либа, которая заточена под фичи языка 2 и 3. Linq в язык никто не встраивал и не собирается этого делать.

Здравствуйте, IB, Вы писали:

_>>Но в любом случае даже красиво записанная рекурсия (что уже не реально в текущем SQL) всё равно намного менее удобна чем простенький императивный цикл.
IB>Если отвыкнуть мыслить циклами, то многое станет удобнее и интереснее )

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

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

Здравствуйте, Sinclair, Вы писали:

S>Но тут пришёл программист, и говорит "А напишу-ка я ассемблерную вставку", хреначит mov &i, eax, и вот компилятор уже вынужден резервировать место на стеке и складывать туда значение.

Ассемблерных вставок на x64 уже нет. ))


_>>И какое это всё имеет отношение, к обсуждаемой нами теме? )
S>Прямое: низкий уровень — это тупик.

Тупик чего? ))
Если не брать ассемблер, всё остальное — лишь абстракции.
Рассуждать тут можно лишь об уровне этих абстракций.
Каждый уровень хорош для своих задач, ес-но.
Более того, даже на самом низкоуровневом языке легко накрутить сколь угодно высокоуровневые абстракции.

Рассуждения ни о чем...


S>Никакой низкоуровневый интерфейс тут не нужен. Прикрутке поверх SQL мешает, в первую очередь, как раз отстутствие "высокого уровня" — вот для C#, скажем, есть roslyn, который позволяет не писать парсер языка для того, чтобы реализовать какой-нибудь простенький анализ кода.

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

Здравствуйте, vdimas, Вы писали:

V>Звучит как рассуждения новичка в ФП, который пытается научиться думать через иммутабельность. ))
Вот это, звучит как рассуждения человека, который не пытается думать, но очень хочется умных слов в неправильном порядке намешать ))

Здравствуйте, IB, Вы писали:

V>>Звучит как рассуждения новичка в ФП, который пытается научиться думать через иммутабельность. ))
IB>Вот это, звучит как рассуждения человека, который не пытается думать, но очень хочется умных слов в неправильном порядке намешать ))

Про неправильный порядок оригинально, однако.
Какой порядок правильный?