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

_>>И в чём он более чистый? Замена "transform(data, d=>...)" на "from d in data group d by ..." выглядит наоборот, как синтаксическое замусоривание.
НС>А ты попробуй цепочку джойнов, перемежаемых проекциями и группировками так переписать, сразу поймешь в чем.

И какое отношение имеет "цепочка джойнов" к обсуждаемому нами примеру?

Здравствуйте, vdimas, Вы писали:
V>Но мы обсуждали либы/фреймворки.
Нет, это вы опять пытаетесь увести рассуждения в сторону. Я вам объясняю не про либы/фреймворки, а про то, как выглядит типичное ORM-решение с точки зрения СУБД.
Если мы включим трассировку, то увидим пачку insert into ... values() и update ... set ... where id = ...
И это всё — потому, что ORM берёт на себя генерацию SQL. Писать такой батч руками никакой программист не будет — в 2-tier решениях, если переставали устраивать "датасеты" с неявным сбросом изменений построчно, то переходили на хранимки, где 1 транзакция = вызов одной ХП. На форумах по СУБД начиная примерно с 2000 можно найти сотни вопросов про то, как запихать в вызов ХП "массив", или "таблицу", или ещё какой-то способ передать пачку значений.

V>Ясно, невозможно.
V>Всё ручками.
V>Как и все остальные в те года.
Ой, как интересно. Вы не могли бы поподробнее рассказать, что именно там было невозможно? Авторы решения всё ещё в пределах досягаемости, я хочу с ними поделиться вашими откровениями

V>О! Всё-таки батчи!
Отож.
V>Ну т.е. ты уже увидел, что если из твоего батча убрать несколько документов, оставив один, то запрос IDENTITY всё-равно нужен.
V>И даже если взять предположенный тобой раундтрип на клиента, разбивая вставку master/slave на много операций, то IDENTITY после вставки в master нужен даже в этом сценарии. )) Не прошло и пяти постов, как ты сие заметил. А как дышал, как дышал...
Простите, я никак не понимаю ваш набор слов. Что откуда нужно убрать, и кто там "всё равно нужен"? Я привёл практически полный батч. Расскажите, чем именно он вас не устраивает.
И что именно вы хотели сэкономить при помощи вашей кустарной схемы раздачи идентификаторов и возврата неиспользуемых?

V>>>Рисовать такой батч на клиенте и отправлять на сервак в те года — я еще ДО этого высмеял такой сценарий, как совершенно нереальный для тех лет.
V>Продолжаю настаивать, а не тупить.
V>Потому что не кластер с ценой транзакций 0.1$ за штуку, а обычный комп, с ценой транзакций примерно 0.00001$ за штуку.
)
Вы что, всеръёз утверждаете, что батч на пару тысяч insert into потребует прямо-таки космических мощностей?
Давайте, расскажите мне, в чём именно проблема исполнить такой батч. А то вы всё намекаете-намекаете, да никак высказать не можете.

V>И залипли на 3-10 секунд.
V>Я б уволил.
Ок, ваш вариант. Вот у нас пачка документов, которые, допустим, хранятся в локальном хранилище (потому что вас 100мс roundtrip для сохранения на сервер не устраивают).
Вы хотите перенести их на сервер. За счёт чего вы собираетесь экономить время? За счёт фоновой синхронизации что ли? Если да, то вы встреваете с целостностью — потому что к моменту синхронизации остатки на складе уже совсем не такие, как во время редактирования. А если вы хотите "на лету" править остатки с помощью "товар в резерве", то мы получаем ровно такое же быстродействие, что и при синхронном сохранении (потому что данные — ровно те же. Там же по 16 байт на строку заказа уезжает).

V>И не от хорошей жизни приходилось, заметь, а из-за проживания в реальном мире, а не в мире сферических коней в вакууме.
Больше похоже, что вы находили первое попавшееся решение "проблемы", и фигачили его, не разобравшись в особенностях. Ничего такого — все так делали. Но смешно то, что вы теперь, вместо того, чтобы сказать "о, можно было делать и по-другому", начинаете придумывать альтернативное прошлое. В котором "коаксиал" не позволял рассчитывать на успешную отправку пакета в два килобайта, сервера за пару тысяч долларов неспособны сделать коммит транзакции, а виртуализация изобретена только пять лет назад. И только у вас асинхронный UI и прозрачная репликация в 1995 году. На чём писали-то, откройте тайну? Сразу на C#?

V>Я не думаю, я знаю, (бо постоянно наблюдал) что это задержки на ровном месте по состоянию на 20+ лет назад.
V>Поэтому, в популярных промышленных системах никто так не делал, разумеется, т.е. никто не отправлял многокилобайтные батчи на сервак.
"Популярные промышленные системы" в большинстве своём — адский шлак. Я бы с удовольствием посмотрел на обратные примеры. Но то, что я видел в 90х из-за рубежа отставало от возможностей технологий примерно на пятилетку.
И чем серъёзнее контора — тем бредовее был её продукт. Вот, помнится, принесли нам на кафедру в 1996 году журнал по квантовой оптике. На компакт-диске, всё официальненько. Дебил, который писал приложение просмотра журнала, явно тестировал его только на HDD. Обработка WM_PAINT на под-окошке "оглавление" ставила машинку раком на 1-2 минуты, пока она шуршит CD-ROM, перечитывая данные. Не, ну понятно — там же ажно 400 метров содержимого было, а запускаться эта штука умела на 4х метрах RAM. Надо полагать, кэширование автор кода считал в такой ситуации лишним.

V>Документ отправлялся на сервак построчно или группами строк (в асинхронном UI, которое как раз стало мегапопулярно именно во второй половине 90-х, с развитием клиент-сервера и трехзвенки).
"Вторая половина девяностых" — это вы сейчас про что? Напомню, что она началась с выхода винды 95. В 1997 году ещё повсеместно стоит Win 3.11 с её убогим UI.
Microsoft Outlook вплоть до 2000 занимался отправкой/приёмом почты в потоке UI — диалог прогресса был модальным. А это, между тем, передовики производства. Интернет эксплорер с нетскейп навигатором притворялись, что их UI асинхронный, но неудачный DNS-запрос замораживал этот "асинхронный" UI только в путь. Покажите мне, в каких приложениях второй половины девяностых был "мегапопулярный" асинхронный UI?

V>Просто в Дельфи всего этого не было, разумеется.
V>Дельфи — это как обратная сторона Луны... там жили и работали инопланетяне.
V>Там, наверно, даже другие физические законы были. ))
Альтернативное прошлое, чо уж там.

V>Это если ты один подключённый к серваку, то 3 секунды.
V>А так-то и десяток секунд аж бегом.
Не угадал.
V>За этот же десяток секунд уже можно обслужить следующего клиента.
Это если у него одна строчка в заказе. Но тогда и ожидание будет не 10 секунд, а одну — характерное время раундтрипа с небольшими данными.
Чтобы набить пару сотен строк, надо потратить как минимум минуту. Я как бы сидел рядом с выпиской, в процессе отладки и сопровождения нашего продукта. Представляю себе, о чём идёт речь.

V>Кароч, от клиентского сценария ты малость далёк, я уже обращал на это твоё внимания.
Беспочвенные фантазии.
V>Достаточно того, что ты всю дорогу делаешь акценты на сложности/важности именно серверной части.
V>Клиент диктует вообще все сценарии работы с серваком, бо ради него (клиента) всё и затевалось.
Диктует, отож. Но чтобы обсуждать производительность этих сценариев, нужно хорошо себе представлять, что происходит на сервере. А точнее — между сервером и клиентом. Иначе так и будешь думать о нём в терминах "ну, я открываю двунаправленный курсор, привязываю его к датагриду, и данные оказываются в базе".
У многих знакомых мне программистов в голове сидят весьма мифологизированные представления о том, скажем, как выглядят и работают prepared statements в том же MS SQL. .

V>Зато знал, как обстояли дела с виртуализацией вообще, бо я в ней живу — в среднем несколько часов в день с 2001-го года, бо характер работ такой.
Как показало обсуждение — и про "вообще" тоже не владеете. Но я в эту тему не хочу лезть — плохо в ней разбираюсь. В отличие, скажем, от моих коллег из московского офиса parallels.com
V>А ларчик там просто открывался — на момент 2006-2008-хх лет вменяемой виртуализации в Linux не было.
V>Она появилась в сыром виде в 2011-м и в более менее нормальном виде вот недавно — в 2013-м.
Ну это ж круто! То есть EC2 работали святым духом многие годы.

S>>- что запись в shared memory вызывает какие-то дополнительные "прерывания" по сравнению с записью в обычную private память процесса

V>Разумеется. Каждая запись в shared memory в Windows вызывает прерывания ОС, чтобы пометить ссотв. страницы памяти как "грязные".
V>Потому что нет такого понятия "просто shared memory" в Windows, есть технология маппинга файлов в память.
V>И пометка страниц для последующей обязательной синхронизации с диском — это азы азов сей технологии.
V>Даже если ты не указал конкретный файл для маппинга, то cистема тебе выделит область в system paging file.
V>Но суть происходящего не изменится.
V>RTFM!
) Коллега, я вам открою страшную тайну: любая запись в память в винде помечает страницу как "грязную". Потому что нет такой памяти, которая не была бы отображена в файл.
"Обычная" память всегда отмаплена в system paging file. (Вопросами работы с невытесняемой памятью мы здесь заниматься не будем — простое гражданское приложение никогда с ней не сталкивается).
Вся разница shared памяти с private — в том, что для shared одни и те же физические страницы одновременно отображены в виртуальную память разных процессов.
Поэтому вы никаким измерением быстродействия не определите, отдали вам на запись ссылку на "private" массив или на "shared".
Удачного вам RTFM!

V>Это ты указал, что используешь Skype for Business.
Нет. Я напомню ещё раз, как было дело: обсуждался webex, который вы критиковали за то, что он использует говнопротоколы SIP/RTP, которые приличные люди обходят стороной. В пику ему вы приводили Skype, рассказывая, как он круто внутри устроен.
А когда я вам возразил, что мне нужна для multi-partner meetings возможность делать полноценный recording, вы прислали скриншот от skype for business, чем изрядно меня повеселили.

S>>- что-то там про ресайз страниц в SQL Server
V>И что там? ))
Его не бывает
V>Тем не менее, обычный современный серверный бокс ценой до 2000 зелени справляется с сотней тыс транзакций в секунду (описанной "сложности" их по твоей ссылке).
Ухты! Вот это круто. Давайте мы с вами взорвём индустрию — выкатим на tpc-c тест, который выдаст 6M tpmC на серверном боксе за 2000 зелени? Цена — невелика, я наскребу ради такого случая по сусекам.
Премию Тьюринга не обещаю, но следующие два-три года мы проведём, переезжая с конференции на конференцию, перелёты — бизнес-классом, и шампанское на завтрак.
V>Вот и прикинь стоимость транзакции за ~5 лет работы этого сервака.
Вы опять путаете стоимость транзакции со стоимостью транзакции в минуту.
Если поделить те числа, которые вы предлагаете, то стоимость одной транзакции на "мега-кластере", которого вы так боитесь, будет примерно 0.00004 цента.

V>Опроверг, дав тебе для примера современные диски и их скорости.
Да, лучшие из них всё ещё в 40 раз медленнее shared memory.

V>Дык, я сходу скачал несколько программ для теста диска и погонял их.
V>Скриншоты прислать?
Давайте. Можно сразу ссылку на результат в http://ssd.userbenchmark.com/SpeedTest/200373/Samsung-SSD-960-EVO-250GB

V>Ага, уже mixed read/write?
V>А соломки не постелить? ))
V>А чего же не sequential read для очереди длиной свыше сотни?
V>Неудобно?
V>Зато SQL-серваку очень удобно на 99% сценариев.
Чегось? SQL-сервак — это не просмотр порно. Это, к сожалению, OLTP. Там добиться sequential read с очередью длиной свыше сотни не выйдет.
Потому что постоянно идут коммиты, перемежающиеся чтениями. Да, движок будет делать всё возможное, чтобы упорядочить чтение экстентов, но на практике такого щастя не получится. Будет реальный mixed read-write; да, очередь можно нагрузить — но не линейными блоками.

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

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

_>В случае использования рукописного (а не автовекторизации) SIMD кода у нас действительно может не быть C++ for'а — вместо него будет ассемблерный цикл (через который тот же самый for тоже выражается). Т.е. это просто уход на ещё более низкий (чем for) уровень, а не на более высокий, как хочешь ты.
Вас не удивляет, что библиотека, на которую вы сослались, не пошла по этому пути?

S>>В таком случае вам придётся забыть про for и прочие низкоуровневые конструкции для записи высокоуровневых выражений. Тут, как в бане — или трусы, или крестик.
_>С чего бы это?
Всё дело в том, что когда я попрошу вас немножечко изменить ядро фильтра, то вся ваша многочасовая работа по рукопашному вылизыванию SSE кода пойдёт псу под хвост. Когда мы с вами обнаружим, что в реализации — ошибка (а вы заметили тёмную кайму вокруг "отфильтрованного" изображения?), вся ваша многочасовая работа по рукопашному вылизыванию SSE кода пойдёт псу под хвост.
Когда мы поймём, что у заказчика есть NVidia, и CUDA работала бы куда быстрее, вся ваша многочасовая работа по рукопашному вылизыванию SSE кода пойдёт псу под хвост.
А вот если вы вложитесь в написание фреймворка, который берёт заданное пользователем ядро, и фильтрует при его помощи заданное пользователем изображение — вот тут ваши усилия начнут окупаться.

_>Ну так "голый C#" относительно Linq — это по сути и есть низкий уровень ("ассемблер"). Т.е. идеологически тут как раз всё правильно. А вот убогость конкретной реализации данной абстракции — это уже другой вопрос.
Нет никакой "конкретной реализации". Вот вы задали вопрос — как будет linq работать с 2d-массивами. Ответ — вот как реализуете, так и будет. Я вам привёл тормозную реализацию, которая позволяет быстро прикинуть палец к носу и выбрать подходящий фильтр или цепочку фильтров. Ведь у нас не бывает самостоятельной задачи "умножить, сложить, и разделить". Вы взяли задачу 2d-фильтрации и попробовали её решить. Вовсе не факт, что именно такая функция, и именно такая стратегия обработки границ подойдёт для решения исходной задачи.
Процесс выбора подходящего фильтра и процесс оптимизации его исполнения — это две совершенно разные фазы проекта.
Более того, оптимальная стратегия исполнения для мало-мальски реалистичных фильтров, скорее всего потребует явного выписывания матрицы рациональных чисел, а не императивных команд "прибавь сюда, подели здесь". Потому что это всё же свёртка, то есть последовательность умножений и сложений векторов. И из соображений корректности нам будет удобнее, например, формировать фильтр как RotationalSymmetric(0, 1, 0).Normalize(), чтобы избежать перекосов из-за дурацкой опечатки в одном из элементов.

_>Совершенно верно. И дело не только в языке, а в том что загрузка соответствующего кода происходит не виде исполнения запроса.
В виде, в виде. В MS SQL вообще всё происходит в виде исполнения запроса. Я же вам приводил этот запрос.

_>А вот у Hadoop почему-то никаких проблем нет... Ну т.е. ограничения конечно же есть (типа модели MapReduce), но они не сильно ограничивают программиста.
Это вам кажется, что "не сильно". Вот те же "глобальные переменные", за которые вы там ратовали в монге, принципиально не могут жить в распределённой среде.

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

_>Так мне же (ну не реальному мне, а абстрактному — реальный то я и совсем другими задачами занимается и по найму не работает) надо решить некую прикладную задачу, а не усовершенствовать SQL Server (это только побочная задача ради главной цели).
Ну так и решайте её. А вы вместо того, чтобы заниматься её решением, хотите обыграть специалистов по SIMD на их поле.

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

_>И? Где обоснование этого бреда?
Это, как я уже сказал, тот сценарий, с которым рядовой разработчик сталкивается каждый первый раз. Если для вас это бред, то я за вас очень рад )

_>Ну раз ты хочешь сравнивать развитие PL/SQL с развитием C#, то тогда будет точно так же корректно сравнить и развитие SQL с C#. И сделать аналогичный вывод о неактуальности SQL...
Нет, сравнивать C# с SQL не корректно, по многим причинам. Во-первых, это языки разного назначения и разной парадигмы. Во-вторых, SQL, как мы выяснили, базируется на реляционной алгебре, что естественным образом ограничивает его развитие. В третьих, нельзя сказать, что SQL совсем не развивается. Ну и наконец, сравнивается не только развитие, но и частота использования. SQL используется в каждом первом приложении с СУБД, а хранимки и императивные расширения по большей части только для legacy приложений.
Так что хоть сравнивай, хоть не сравнивай, а SQL живой язык, а T/PL/SQL и попытки работать с данными в императивном стиле пока к серьезному успеху не привели.

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

_>Да, способы есть, но все они дико уродливые в сравнение с решением на PL/SQL из пары простейших строчек.
Ну вот не надо про уродливость. Последний вариант, простой, красивый и понятный. Вариант с промежуточной таблицей с идентификаторами, тоже две строчки и кристально прозрачный. Всяко понятнее императивного цикла и, скорее всего, эффективнее.

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

_>Хы. А многие (я правда к таким не отношусь) считают что использование var/auto при объявление переменных наоборот ухудшают понимание кода. )))
А это-то тут причем?

_>"Проблема" с тривиальным решением может считать проблемой разве что в академическом смысле.
Решение тривиальное, но грязное. Код становится сложнее для понимания, поэтому это проблема.

_>Ну как же с самого начала, если ещё в эту темки кидали ссылку на единственную реализацию решения этой проблемы и она при этом находилась ещё на стадии экспериментального тестирования. Сколько лет с момент выпуска Linq прошло до этого года? )))
Вы что-то не так поняли. Еще раз — есть ограничение языка, которое не позволяет записать рекурсивную лямбду. Есть обход этого ограничения но он грязный. Лямбды — это часть линка, следовательно, ограничения на лямбды, равно как и их обход, относятся в том числе и к линку. Никаких дополнительных ограничений у линка нет.
Следовательно и проблема та же самая, и решение то же, и это не эксперимент, и это ограничение языка, а не непосредственно линка. С чего собственно и начали.

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

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

_>Ну покажи пример, как оно будет более читаемо для обсуждаемой здесь задачи.
Вон выше Антон уже написал.

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

_>Вообще то прямо в сообщение, на которое ты сейчас отвечал, был прямой пример, отвечающий на твой вопрос.
Вообще-то прямо нет, не было.

_>Но ты его предпочёл вообще проигнорировать. А раньше в этой темке было ещё множество таких примеров, причём не только от меня. А ты всё пытаешься сделать вид, что не понимаешь о чём речь...
Это вы пытаетесь сделать вид, что не понимаете о чем речь )

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

S>Здравствуйте, vdimas, Вы писали:
V>>Но мы обсуждали либы/фреймворки.
S>Нет, это вы опять пытаетесь увести рассуждения в сторону. Я вам объясняю не про либы/фреймворки, а про то, как выглядит типичное ORM-решение с точки зрения СУБД.

Забегал. ))
Все ходы записаны.
Мы до этого обуждали либы ORM.

S>Если мы включим трассировку, то увидим пачку insert into ... values() и update ... set ... where id = ...

Если мы включим трассировку обсуждения, то обнаружим некий контекст.


S>И это всё — потому, что ORM берёт на себя генерацию SQL.

Чушь.
Это не признак ORM, это признак архитектурного слоя DAL.
ORM — лишь часть функциональности этого слоя.
То, что многие СОВРЕМЕННЫЕ библиотеки ORM покрывают функциональность слоя DAL целиком — оно остаётся на совести сокращения именования таких библиотек. ))


V>>Ясно, невозможно.
V>>Всё ручками.
V>>Как и все остальные в те года.
S>Ой, как интересно. Вы не могли бы поподробнее рассказать, что именно там было невозможно?

Невозможна функциональность навроде современных linq2db или даже предыдущей BLT.


S>Авторы решения всё ещё в пределах досягаемости, я хочу с ними поделиться вашими откровениями

Ты хочешь разве что извернуться.


V>>О! Всё-таки батчи!
S>Отож.

Значит, все твои предыдущие рассуждения о невладении ньюансами T-SQL в плане локальных переменных и ф-ий навроде IDENTITY фтопку.


V>>Ну т.е. ты уже увидел, что если из твоего батча убрать несколько документов, оставив один, то запрос IDENTITY всё-равно нужен.
V>>И даже если взять предположенный тобой раундтрип на клиента, разбивая вставку master/slave на много операций, то IDENTITY после вставки в master нужен даже в этом сценарии. )) Не прошло и пяти постов, как ты сие заметил. А как дышал, как дышал...
S>Простите, я никак не понимаю ваш набор слов. Что откуда нужно убрать, и кто там "всё равно нужен"? Я привёл практически полный батч. Расскажите, чем именно он вас не устраивает.

Меня не устраивает твоя голосновность обвинений.
От того факта, что ты привёл некий простой батч, пока не следует аж ничего, откуда можно было сделать вывод, что коллега не способен его написать.
Коллега тебе сказал "кошмар" и неоднократно пояснил — почему именно.
Такое объяснение тебе явно не понравилось, бо спорить с ним ты явно не в состоянии (это очевидно) и ты решил перевести стрелки — пройтись по профессиональным навыкам коллеги.
Т.е. нахамил и слил одновременно.


S>И что именно вы хотели сэкономить при помощи вашей кустарной схемы раздачи идентификаторов и возврата неиспользуемых?

Время, вестимо.
Я вызываю одну хранимку, передавая ей id док-та из "временной" таблицы.
И вся кухня выполняется через два вызова insert into select и примерно за 100-200ms.
А даже если за большее время, то в любом случае в очередь к потоку (логическому процессу т.е., к задаче), ожидающему выполнение этой операции, уже можно ставить следующие запросы по док-ту, бо ID уже известен.

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


S>Вы что, всеръёз утверждаете, что батч на пару тысяч insert into потребует прямо-таки космических мощностей?

Забегал. ))
Твой вопрос аналогичен примерно такому: "вы что, думаете для того, чтобы проехать 100 метров нужны космические скорости"?
Как вообще можно сравнивать величины с разной размерностью?


S>Давайте, расскажите мне, в чём именно проблема исполнить такой батч. А то вы всё намекаете-намекаете, да никак высказать не можете.

И опять врешь.
Было прямо сказано в чём вопрос — вопрос во времени.
Как с теми 100 метрами.


S>Ок, ваш вариант.

Подробнейшим образом расписан.

Всё-таки, по состоянию даже на 97-й год, клиентское GUI само по себе уже можно было назвать сверхотзывчивым и весьма приятным.
Поэтому, основной задачей в те года было не испоганить это достижение кривыми решениями.
Напомню, что в те года, если не брать Дельфи, разработка адекватного GUI считалась вполне себе заслуживающей уважения задачей.
Это уже с выходом дотнета вопрос GUI переехал в область "ха-ха, хи-хи", ну и дотнетный макаронный код, когда вся логика содержится в обработчике нажатия кнопки — оно тоже придало задачам разработки GUI, не побоюсь этого слова, негативный оттенок.

А на те года разработка вменяемого отзывчивого GUI была почётным вызовом и все аспекты происходящего ТЩАТЕЛЬНО проектировались и предварительно моделировались.
И тут такой ты вбегаешь и давай шашкой направо и налево махать, мол, надо было "херак-херак и в продакшен".
А я сижу и только глазами хлопаю от такой дисциллированной незамутнённости.
Колега, ты с другой стороны Луны, просто помни об этом каждый раз, когда кому-то что-то пишешь.

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

_>Я в данной теме уже приводил примеры более удобных, функциональных и эффективных реализаций. Причём как Linq для коллекций, так и Linq для СУБД.

Для коллекций не особо интересно, а для СУБД и со строгой типизацией я что то не приметил.

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

_>>>И в чём он более чистый? Замена "transform(data, d=>...)" на "from d in data group d by ..." выглядит наоборот, как синтаксическое замусоривание.
НС>>А ты попробуй цепочку джойнов, перемежаемых проекциями и группировками так переписать, сразу поймешь в чем.
_>И какое отношение имеет "цепочка джойнов" к обсуждаемому нами примеру?

Т.е. пофик на реальные потребности, давайте обсуждать примитивный пример? Браво!

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

_>>В случае использования рукописного (а не автовекторизации) SIMD кода у нас действительно может не быть C++ for'а — вместо него будет ассемблерный цикл (через который тот же самый for тоже выражается). Т.е. это просто уход на ещё более низкий (чем for) уровень, а не на более высокий, как хочешь ты.
S> Вас не удивляет, что библиотека, на которую вы сослались, не пошла по этому пути?

Эээ что? Библиотека Eigen основана на статическом метапрограммирование, с помощью которого в нужных местах алгоритмов размещаются интринсики компилятора (считай ассемблерные SIMD команды), зависящие от текущей целевой архитектуры: https://github.com/eigenteam/eigen-git-mirror/tree/master/Eigen/src/Core/arch. Это как раз то, о чём я говорил — уход на более низкий уровень (от for с его возможностями автовекторизации, к ручному заданию ассемблерных simd инструкций) ради большей производительности.

S>>>В таком случае вам придётся забыть про for и прочие низкоуровневые конструкции для записи высокоуровневых выражений. Тут, как в бане — или трусы, или крестик.
_>>С чего бы это?
S>Всё дело в том, что когда я попрошу вас немножечко изменить ядро фильтра, то вся ваша многочасовая работа по рукопашному вылизыванию SSE кода пойдёт псу под хвост. Когда мы с вами обнаружим, что в реализации — ошибка (а вы заметили тёмную кайму вокруг "отфильтрованного" изображения?), вся ваша многочасовая работа по рукопашному вылизыванию SSE кода пойдёт псу под хвост.
S>Когда мы поймём, что у заказчика есть NVidia, и CUDA работала бы куда быстрее, вся ваша многочасовая работа по рукопашному вылизыванию SSE кода пойдёт псу под хвост.
S>А вот если вы вложитесь в написание фреймворка, который берёт заданное пользователем ядро, и фильтрует при его помощи заданное пользователем изображение — вот тут ваши усилия начнут окупаться.

Вот снова ты сбиваешься на споры с выдуманным оппонентом. Интересно, сколько раз ещё тебе надо повторить одну и ту же мысль, чтобы ты запомнил мою позицию по этому вопросу? Я совершенно не против таких фреймворков. При условие, что нам никто не закроет доступ (ну в случае C++ это невозможно, но предположим) к возможности написания кода без этого фреймворка (или же к его доработке).

_>>Ну так "голый C#" относительно Linq — это по сути и есть низкий уровень ("ассемблер"). Т.е. идеологически тут как раз всё правильно. А вот убогость конкретной реализации данной абстракции — это уже другой вопрос.
S>Нет никакой "конкретной реализации". Вот вы задали вопрос — как будет linq работать с 2d-массивами. Ответ — вот как реализуете, так и будет. Я вам привёл тормозную реализацию, которая позволяет быстро прикинуть палец к носу и выбрать подходящий фильтр или цепочку фильтров. Ведь у нас не бывает самостоятельной задачи "умножить, сложить, и разделить". Вы взяли задачу 2d-фильтрации и попробовали её решить. Вовсе не факт, что именно такая функция, и именно такая стратегия обработки границ подойдёт для решения исходной задачи.
S>Процесс выбора подходящего фильтра и процесс оптимизации его исполнения — это две совершенно разные фазы проекта.
S>Более того, оптимальная стратегия исполнения для мало-мальски реалистичных фильтров, скорее всего потребует явного выписывания матрицы рациональных чисел, а не императивных команд "прибавь сюда, подели здесь". Потому что это всё же свёртка, то есть последовательность умножений и сложений векторов. И из соображений корректности нам будет удобнее, например, формировать фильтр как RotationalSymmetric(0, 1, 0).Normalize(), чтобы избежать перекосов из-за дурацкой опечатки в одном из элементов.

Хы, я здесь под убогостью конкретной реализации подразумевал не твой код для 2D фильтрации, а само устройство Linq. )))

_>>А вот у Hadoop почему-то никаких проблем нет... Ну т.е. ограничения конечно же есть (типа модели MapReduce), но они не сильно ограничивают программиста.
S>Это вам кажется, что "не сильно". Вот те же "глобальные переменные", за которые вы там ратовали в монге, принципиально не могут жить в распределённой среде.

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

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

Предлагаю ознакомиться со стандартом OpenAcc (доступен например в gcc с 6-ой версии) и его отношением с "for". )))

_>>Так мне же (ну не реальному мне, а абстрактному — реальный то я и совсем другими задачами занимается и по найму не работает) надо решить некую прикладную задачу, а не усовершенствовать SQL Server (это только побочная задача ради главной цели).
S>Ну так и решайте её. А вы вместо того, чтобы заниматься её решением, хотите обыграть специалистов по SIMD на их поле.

1. Я как раз могу легко поиграть на одном поле со специалистами по SIMD — навыки позволяют (правда не под все возможные архитектуры, а только под нужные мне).
2. Я не занимаюсь этим делом в 99% случаев, потому что:
— в 90% случаев есть уже готовое решение в виде бесплатной библиотеки (типа того же Eigen или например jpeg-turbo)
— в 9% случаев (когда "формула" в цикле не слишком сложная) оптимально работает автовекторизация gcc.

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

_>>И? Где обоснование этого бреда?
IB>Это, как я уже сказал, тот сценарий, с которым рядовой разработчик сталкивается каждый первый раз. Если для вас это бред, то я за вас очень рад )

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

_>>Ну раз ты хочешь сравнивать развитие PL/SQL с развитием C#, то тогда будет точно так же корректно сравнить и развитие SQL с C#. И сделать аналогичный вывод о неактуальности SQL...
IB>Нет, сравнивать C# с SQL не корректно, по многим причинам. Во-первых, это языки разного назначения и разной парадигмы. Во-вторых, SQL, как мы выяснили, базируется на реляционной алгебре, что естественным образом ограничивает его развитие. В третьих, нельзя сказать, что SQL совсем не развивается. Ну и наконец, сравнивается не только развитие, но и частота использования. SQL используется в каждом первом приложении с СУБД, а хранимки и императивные расширения по большей части только для legacy приложений.
IB>Так что хоть сравнивай, хоть не сравнивай, а SQL живой язык, а T/PL/SQL и попытки работать с данными в императивном стиле пока к серьезному успеху не привели.

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

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

_>>Да, способы есть, но все они дико уродливые в сравнение с решением на PL/SQL из пары простейших строчек.
IB>Ну вот не надо про уродливость. Последний вариант, простой, красивый и понятный. Вариант с промежуточной таблицей с идентификаторами, тоже две строчки и кристально прозрачный. Всяко понятнее императивного цикла и, скорее всего, эффективнее.

Вообще то я бы сказал что задание рекурсии в стандарте SQL (через CTE) вообще на редкость уродливое. Даже оригинальный синтаксис Oracle тут выглядит намного приятнее, хотя я и не люблю все эти привязывающие к конкретному производителю выходы за стандарт (это я даже не про SQL, а вообще). Но в любом случае даже красиво записанная рекурсия (что уже не реально в текущем SQL) всё равно намного менее удобна чем простенький императивный цикл.

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

_>>Ну как же с самого начала, если ещё в эту темки кидали ссылку на единственную реализацию решения этой проблемы и она при этом находилась ещё на стадии экспериментального тестирования. Сколько лет с момент выпуска Linq прошло до этого года? )))
IB>Вы что-то не так поняли. Еще раз — есть ограничение языка, которое не позволяет записать рекурсивную лямбду. Есть обход этого ограничения но он грязный. Лямбды — это часть линка, следовательно, ограничения на лямбды, равно как и их обход, относятся в том числе и к линку. Никаких дополнительных ограничений у линка нет.
IB>Следовательно и проблема та же самая, и решение то же, и это не эксперимент, и это ограничение языка, а не непосредственно линка. С чего собственно и начали.

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

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

Так а если кто-то уже пострадал и написал, то уж тогда то пользователю разницы нет, правильно? )

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

_>>Ну покажи пример, как оно будет более читаемо для обсуждаемой здесь задачи.
IB>Вон выше Антон уже написал.

Не вижу подобного сообщения. Кинь ссылку где тут был соответствующий пример кода — может я пропустил.

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

_>>Вообще то прямо в сообщение, на которое ты сейчас отвечал, был прямой пример, отвечающий на твой вопрос.
IB>Вообще-то прямо нет, не было.

Кстати, я вот в прошлый раз кидал тут ссылочку на статью, где одновременно применяется на одном и том же hadoop кластере (и одних и тех же данных, но на разных стадиях их обработки) и MapReduce запросы и Spark запросы и SQL (Hive/SparkSQL) запросы. Не хочешь попробовать провести всю описанную работу только на SQL? )))

А это что по твоему?

_>>Но ты его предпочёл вообще проигнорировать. А раньше в этой темке было ещё множество таких примеров, причём не только от меня. А ты всё пытаешься сделать вид, что не понимаешь о чём речь...
IB>Это вы пытаетесь сделать вид, что не понимаете о чем речь )

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

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

_>>Я в данной теме уже приводил примеры более удобных, функциональных и эффективных реализаций. Причём как Linq для коллекций, так и Linq для СУБД.
НС>Для коллекций не особо интересно, а для СУБД и со строгой типизацией я что то не приметил.

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

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

_>>>>И в чём он более чистый? Замена "transform(data, d=>...)" на "from d in data group d by ..." выглядит наоборот, как синтаксическое замусоривание.
НС>>>А ты попробуй цепочку джойнов, перемежаемых проекциями и группировками так переписать, сразу поймешь в чем.
_>>И какое отношение имеет "цепочка джойнов" к обсуждаемому нами примеру?
НС>Т.е. пофик на реальные потребности, давайте обсуждать примитивный пример? Браво!

Речь здесь шла про вполне конкретный пример, а не про вообще. Если ты влезая в дискуссию этого не заметил, то следовало просто извиниться, а не пытаться сделать вид, что ты ещё и прав.

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

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

_>>>В случае использования рукописного (а не автовекторизации) SIMD кода у нас действительно может не быть C++ for'а — вместо него будет ассемблерный цикл (через который тот же самый for тоже выражается). Т.е. это просто уход на ещё более низкий (чем for) уровень, а не на более высокий, как хочешь ты.
S>> Вас не удивляет, что библиотека, на которую вы сослались, не пошла по этому пути?

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

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;

На всякий случай повторно разжую, помедленнее: если вы напишете такой код, то не будет никаких интринсиков, SIMD, многопоточности, и прочих "учётов целевой архитектуры". Только "автовекторизация gcc", способности которой ограничены.
Чтобы всё это использовать, вам придётся отказаться от явного выписывания for и временных переменных. От вашего кода останется только лямбда, которую вы будете скармливать в библиотеку.
Это — ровно подход linq. Единственная разница, малосущественная для прикладного программиста — это статика против динамики.
То есть Eigen рассчитывает на то, что прикладной программист заранее знает, на какой архитектуре будет исполняться его программа. Что требует недюжинных прогностических способностей.
Подход дотнета — позднее связывание, в широком смысле слова.
У него есть свои преимущества — в частности, возможности оптимизации без перекомпиляции.
_>Хы, я здесь под убогостью конкретной реализации подразумевал не твой код для 2D фильтрации, а само устройство Linq. )))
"Само устройство" linq — великолепно. Его крайне трудно существенно улучшить, оставаясь в рамках платформы.

_>В Монге они отлично живут внутри одного документа.
"Внутри одного документа" никаких "глобальных" переменных быть не может.

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

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

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

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

_>1. Я как раз могу легко поиграть на одном поле со специалистами по SIMD — навыки позволяют (правда не под все возможные архитектуры, а только под нужные мне).
_>2. Я не занимаюсь этим делом в 99% случаев, потому что:
_> — в 90% случаев есть уже готовое решение в виде бесплатной библиотеки (типа того же Eigen или например jpeg-turbo)
_> — в 9% случаев (когда "формула" в цикле не слишком сложная) оптимально работает автовекторизация gcc.
Так и в linq вы можете, если очень хочется, полезть в кишочки и сделать свою версию .Select(), .Where(), и .GroupBy().