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

V>>А в случае одномерного массива компилятор подставляет тупо опкоды со смещением по индексу.
S>Спешу вас обрадовать. Специальные методы устраняются джитом, точно так же, как и для одномерных массивов.

А как джит спасает от тел этих методов?
Для одномерного массива вот в этом случае: for(int k=0; k<array.Length; k++) sum+=array[k]; компилятор просто подставляет опкоды доступа к массиву безо всяких проверок.


S>Она устарела. Всё, чем плох [,] — это неустранимыми проверками диапазона.

Осталось понять, как это противоречит замеченной мною разнице в эффективности м/у одномерными и двумерными массивами и моему утверждению, что ты свёл доступ к двумерному массиву к доступу к одномерному, т.е. сыграл на этой разнице. ))

А, главное, почему это можно делать для linq-хелпера и нельзя делать для "обычных циклов"?
Со стороны если — сугубо для пущщего вау-эффекта, ы-ы-ы.


S>А если мы перелезаем через забор и пользуемся fixed в bulk-операциях, то разницы нет, т.к. сравнивать будем 0 проверок и 0 проверок.

А самим не надо в любом случае делать проверки выхода за диапазон в ценарии "относительной адресации"? ))


S>То же самое касается применению Span<T> — он примерно одинаково извлекатся из массива любой размерности, и из LockBitmap.

Span<T> — это замена unsafe для львиной доли популярных сценариев.
Одно "но" — все светошумовые эффекты на ём воспроизводятся точно так же, как и в случае unsafe:

    int[] safe_array = { 1, 2, 3 };
    var unsafe_array = MemoryMarshal.CreateReadOnlySpan(ref safe_array[0], safe_array.Length + 1);
    var x = unsafe_array[safe_array.Length]; // OK. WAT?
    var y = safe_array[safe_array.Length];  // throws IndexOutOfRangeException
    var z = unsafe_array[unsafe_array.Length];  // throws IndexOutOfRangeException

Cамая издевательская тут последняя строка z — внутри Span<> всё-равно происходят проверки выхода за диапазон, хотя на строке x мы вышли за диапазон массива без проблем.
Тоже налицо улыбающие попытки совместить ужа с ежом.

===================
Кароч.
Мне эта постоянная смена контекста от общего к частному поднадоела уже.

Когда тебе удобно, ты говоришь о "целом классе задач", объясняя этим цель своих упражнений с IL-генераторам.
Когда тебе неудобно говорить о классе задач, упорно твердишь о конкретной задаче, даже если твой собеседник ранее повёлся и тоже говорил уже о классе задач.
Это всё лишь бесполезные переливания из пустого в порожнее.

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

Когда весь алгоритм у нас перед глазами, т.е. мы заведомо "обслужили единички", которые ты предлагал "вручную не обслуживать" (С), то мы можем не делать проверок на каждой итерации, бо у нас прямо перед глазами находится причина, разрешающая нам избегать проверок. Это не только моё мнение, так работает вся индустрия в той области, в который ты тоже решил себя попробовать.
Попробовал.
Получил при попытке обобщения противоречивые инварианты для того самого базового решения.
Дальше что?
Дальше просто — по-классике такое обобщение делать нельзя.
Ведь в случае дизайна иерархии ООП-объектов, я уверен, ты этот принцип проектирования понимаешь хорошо.

А зачем вообще нужны всякие "принципы"?
Почему бы не посмотреть еще чуть глубже в суть вещей?
Там же не сложно.
"Совсем красиво" задачи такого класса решаются только в языках, где можно доказать корректность обращений к агрегату.
В остальных же языках необходимо придерживаться наработанных индустрией правил хорошего тона.
Решил отвергнуть за раз целую россыпь таких наработок? — не жалуйся, критика справедлива.

Тем более, что в итоге и обобщённого решения не получилось, и частного тоже.
Подай в свой алгоритм матрицу {{2, 2}, {2, 2}} и убедись, что с4 блур обсчитывается не правильно. ))

Здравствуйте, vdimas, Вы писали:
V>А как джит спасает от тел этих методов?
V>Для одномерного массива вот в этом случае: for(int k=0; k<array.Length; k++) sum+=array[k]; компилятор просто подставляет опкоды доступа к массиву безо всяких проверок.
Неважно, что подставляет компилятор.
Важно, какой код получается в целевой архитектуре.
В одномерном случае есть специальные опкоды ldelem/ldelema/stelem.
Проверка делается в нём, и джитом, а не компилятором. Достаточно посмотреть на дизассеблер запущенной программы.
Точно так же всё устроено и для многомерных массивов — вызов метода get_Item заменяется на серию проверок по количеству измерений.

V>Осталось понять, как это противоречит замеченной мною разнице в эффективности м/у одномерными и двумерными массивами и моему утверждению, что ты свёл доступ к двумерному массиву к доступу к одномерному, т.е. сыграл на этой разнице. ))
Разнице в эффективности — не противоречит. Утверждению — противоречит. Доступ к одномерному массиву тоже подлежит проверке. Я избавился от проверок вообще. То есть в "честном" коде мы имеем 2 проверки на обращение, в "индексере" — одну, в unsafe коде — 0.

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

S>>А если мы перелезаем через забор и пользуемся fixed в bulk-операциях, то разницы нет, т.к. сравнивать будем 0 проверок и 0 проверок.
V>А самим не надо в любом случае делать проверки выхода за диапазон в ценарии "относительной адресации"? ))
Нет, не надо. Я же показал код — там нет никаких проверок, и при этом всё безопасно.

V>Cамая издевательская тут последняя строка z — внутри Span<> всё-равно происходят проверки выхода за диапазон, хотя на строке x мы вышли за диапазон массива без проблем.
V>Тоже налицо улыбающие попытки совместить ужа с ежом.
Налицо непонимание идеи, стоящей за Span<T>.
Она, вкратце, вот в чём:
1. Обеспечить возможность писать алгоритмы, которые универсально применимы к данным в хипе, на стеке, и в неуправляемой памяти.
2. Обеспечить высокую эффективность.
В частности, вот в таком цикле проверки на выход за границы делаются 0 раз:

public void PrintArray(int[] a)
{
  for(int i=0; i<a.Length; i++) Console.WriteLine(a[i]);
}

Вот в таком — ~Length раз:

public void PrintArray(int[] a)
{
  for(int i=0; i<a.Length -1; i++) Console.WriteLine(a[i]);
}

А в таком — 1 раз:

public void PrintArray(int[] a)
{
  var s = new Span<int>(a, a.Length-1); // вот здесь делается единственная проверка
  for(int i=0; i<s.Length; i++) Console.WriteLine(s[i]);
}

Для перехода между вторым и третьим случаями нам и полезен Span<T>.

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

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

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

Пока что в качестве черновика годится.

V>"Совсем красиво" задачи такого класса решаются только в языках, где можно доказать корректность обращений к агрегату.
V>В остальных же языках необходимо придерживаться наработанных индустрией правил хорошего тона.
V>Решил отвергнуть за раз целую россыпь таких наработок? — не жалуйся, критика справедлива.

V>Тем более, что в итоге и обобщённого решения не получилось, и частного тоже.
V>Подай в свой алгоритм матрицу {{2, 2}, {2, 2}} и убедись, что с4 блур обсчитывается не правильно. ))
Он обсчитывается ровно настолько же правильно, как и для матрицы 3x3. А что будет с матрицей в вашем алгоритме?

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

V>>Опять старательно уходишь от ЛЮБЫХ технических деталей, только разводишь ля-ля-ля общими словами.
IB>Не надо проецировать свои методы на других, в зеркало посмотрись)

Уфф, опять по делу — ноль.
Постоянство — признак мастерства?

Смотрю, на много фронтов умудряешься ругаться:
http://www.rsdn.org/forum/flame.comp/7194646.1
При том, что сам же по ссылке не понял, что тебе говорили.
Т.е. даже не в курсе, как MS SQL вызывает юзверские дотнетные ф-ии и о каком принципиальном отличии тебе говорят...
Специалист по MS SQL, ага. ))


IB>>>- ты намеренно скрываешь детали своих утверждений, чтобы потом оставалось пространство для маневра, а то как доходит до деталей, то сразу вылезают ошибки от которых сложно отмазаться.
V>>И конечно, тебе не трудно будет уточнить каждое из 3-х утверждений в этом предложении?
IB>Легко, начнем с цитат "Сорри, но на конкретный алгоритм пелевать..."(с)

Да, давай начнём.
Слово предоставляется Синклеру:

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

стратегия обхода будет более-менее одна для широкого класса фильтров.

Ключевая идея — в том, что код linq-провайдера можно использовать повторно.

Я привёл маленький, короткий proof of concept. Просто потому, что для форумных обсуждений я не могу потратитьcz на написание полноценного стека с поддержкой всех девяти конструкций query comprehension. В реальной промышленной библиотеке конечно же...

Linq используется для того, чтобы разделить стратегю исполнения и сам "запрос".

Собсно, всё обсуждение таково, можно накидать еще кучу.
Т.е. вполне однозначный контекст в этом обсуждении был задан.
Не мной.

Так шта, опять поздравляю тебя соврамши.
Вместе с Синклером, кстате.

Ему тоже, когда отвечать неудобно, он начинает играть контекстом: "а вот тут у нас общее решение" — "хорошо, давай поэкспериментируем с техниками общего решения", "а вот ты целиком конкретную задачу не показал!" — "так ты тоже целиком не показал, будем хи-хи разводить или по делу?" — "ОК, по делу"... — через несколько итераций опять срывается на повтор этого же "трюка".

Дурдом, блин ))


IB>

IB>Там было не только про рефлексию, но мне лень обсуждать с тобой разницу происходящего в случае IEnumerable vs IQueryable.
IB>Кто в курсе, тому те слова были понятны.
IB>А кто не в курсе, тот мается ерундой, гоняясь на форуме за словами, смысла которых не понимает.
IB>.....
IB>Я только что обозначил куда копать.

Не вижу пояснения, что не так в упоминании отличия IEnumerable vs IQueryable.
Доводы твои где?
Хоть бы обозначил своё мнение, чтобы понятно было что отвечать. ))


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

Т.е., в кач-ве третьего аргумента смог повторить лишь первый, который клевета?
Пфф...


IB>Жалкое зрелище, откровенно говоря.

Ага, за слова не отвечаешь.
Выглядит как ты написал.


V>>Слышал я уже эти отмазки и уже отправлял тебя к твоим же словам в том топике.
V>>Вы обсуждали целый класс алгоритмов, а alex_public привёл лишь пример такого алгоритма.
IB>Фууу, как занудно, даже отмазываться красиво не умеешь.

Отмазываться от чего?
Была дана ссылка на обсуждение.
Я его почитал, привёл твои же слова, кстате, с которых и понеслось.
Опять от своих слов решил отказаться? ))


IB>Задача была сформулирована четко и не двусмысленно.

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

Или IL-генератор нужен для целого класса таких задач, как утверждает Синклер, ы?
Ты эта, или крестик сними, или трусы одень.


IB>Ты решил что-то другое.

Я вполне чётко сказал, что именно я "решил" — провёл эксперименты с разными хелперами под пресловутый ваш "класс задач" (С).
И вполне однозначно об этом написал.
Я отвечаю за свои слова, в отличие от.

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

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


IB>Ты можешь придумывать что угодно, но ты налажал, успокойся уже =)

"халва, халва"...


V>>Я эту задачу вообще не решал и не собирался.
IB>Тогда зачем ты здесь вообще? Скройся уже

Да не твоё форумного хамла дело.


V>>Я демонстрировал "недоговорённости" в коде Синклера.
IB>Но едиственное что тебе удалось продемонстрировать это собственную ущербность и не способность адекватно вести дискуссию.

ЧТД.
Я пока твою наблюдаю неспособность вести осмысленный диалог, т.е. именно что ущербность.
(спасибо, что отныне разрешил мне применять это слово в отношении тебя)

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

Последнее вообще клиника для инженера — неумение трассировать ход обсуждения.


V>>А где я предоставил готовое к тестам решение исходной задачи?
IB>Ты предоставил достаточно, чтобы понять, что ты накосячил.

Вопрос-то в силе — где я предоставил готовое к тестам решение исходной задачи?

... ой, чего это я? Прошу за слова ответить?
Извините, не узнал в гриме.


V>>Чужой код нужен был для сравнения.
IB>Для начала, для сравнения нужно решать ту же задачу и сделать это корректно.

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


IB>Тебе это пока не удалось.

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


V>>Я сюда влез изначально с единственным замечанием — Синклер сравнивает не то и не с тем:
IB>Не то и ни с тем кроме тебя здесь никто не сравнивает.

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

А то в сухом остатке твои посылы читаются как "извините, но нам неприятно, когда нас критикуют".
Жесть...


V>>И тебя не смущает, что я именно это сразу же и предложил?
IB>Ты предложил решение другой задачи, причем умудрился ошибиться и там.

Смотрю, с тобой спорить — как бить ребенка.
Показываю на раз-два:

ОК, соглашаемся на то, что ты способен только резать некий приведённый мой код из контекста, согласен игнорить написаное там же "схематично без студии", всё принимаем!

Но как ты мог сейчас умудриться написать "решение другой задачи, причём умудрился ошибиться"?
Откуда ты знаешь, насчёт "ошибиться", если "другая задача"?
Может, она в том и состояла — пройтись алгоритмом навроде c4 по этому же массиву?

Так подставляться и самозабвенно врать, отвечая на конкретную ссылку:
http://www.rsdn.org/forum/dotnet/7188188.1

Как у тебя будет готов полный код — дай знать, сравним с моим вариантом на каком-нить изображении 4к.

IB>Выйди и зайди снова, как учили =)

Да, да.
По интернету вы все смелые и наглые.

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


V>>Тем более, что ты делаешь оценочные суждения даже не от своего имени, а от имени другого коллеги.
V>>Это уже звоночек, однако... ))
IB>Хорошо что ты это понимаешь, теперь научись применять это к себе =)

Я не оцениваю твоими словами других.
Да мне и в голову это не пришло бы.
Че за бред, ваще.

Я оцениваю отсутствие от тебя аргументов по существу, неумение держать контекст (или сознательное им манипулирование, на выбор), резьбу по цитатам и откровенную манипуляцию на фоне неумения отвечать за собственные слова.

И самое неприятное знаешь что? Сайт RSDN печально известен тем, что самая громкая ругня на ём происходит с участием людей из RSDN-team.

Не со всеми, конечно, (и слава богу!), но участвующие в ругани лица одни и те же.
Да и тема ругни одна и та же: "караул! дотнет обижают!".
Вот что выглядит, действительно, жалким зрелищем.
Да еще столь глобальным.
Вредители, ей богу!

Хорошо хоть Влад с Вольфхаундом об Немерле самоубились, на два громких человека меньше стало...
Но ты решил скомпенсровать их отсутствие или как понимать?

Не понял еще произошедшее уже в нескольких историях?
(не только со мной)

Ты, у нас, смотрю, любитель давать другим советы, верно?

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

Бо ты в этом деликатном деле неуклюж аки слон в посудной лавке.
Особенно когда сам же недоразбрался, но уже бежишь вприпрыжку советы раздавать...
Ай некрасиво раз за разом выходит...
В итоге некрасивая ругня.
Оно тебе точно надо?

Ты ведь зря с Синклера пример берешь, до него ты всё-равно не дотянешь.
Он когда дерзит или просто под настроение нападает, он же умеет ходить по самому краю, сечёшь, не?
Ты же за этот край всегда бултых — и улетел с концами. ))
Бо неуклюж.
Далее.
Синклер при этом умудряется выдерживать технический ход беседы.
Хитёр жук, ох хитёр! ))
А тебя когда накрывает, ты ж посмотри — кроме бесполезного ля-ля-ля ноль толку.
Тупо потребляешь терпение оппонентов абсолютно даром.

Так шта, ты уж постарайся, поработай над собой, если ты решил опять на этом форуме активизироваться.
Попридержи свое советовательное недержание.
Глядишь, и конфликтов с твоим участием будет всяко меньше...

Не, если ты когда-нить достигнешь 80 lvl как Синклер, тоды дооо...
Хотя, всё-равно хрень еще та...

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

V>>Для одномерного массива вот в этом случае: for(int k=0; k<array.Length; k++) sum+=array[k]; компилятор просто подставляет опкоды доступа к массиву безо всяких проверок.
S>В одномерном случае есть специальный опкод ldelema.
S>Проверка делается в нём, и джитом, а не компилятором. Достаточно посмотреть на дизассеблер запущенной программы.
S>Точно так же всё устроено и для многомерных массивов — вызов метода get_Item заменяется на серию проверок по количеству измерений.

В указанном мною цикле после дизассемблера никаких проверок доступа к массиву нет, есть только проверка переменной цикла, именно об этом я и говорил.


S>Разнице в эффективности — не противоречит. Утверждению — противоречит.

Настаиваю.
Я более чем уверен, что ты в курсе про трюк оптимизации показанного мною цикла.
Об этом и шла речь, ес-но.

V>>А, главное, почему это можно делать для linq-хелпера и нельзя делать для "обычных циклов"?
S>Потому что для "обычных" циклов этот корявый код пиннинга и адресной арифметики придётся писать вручную, рискуя накосячить.

ОК, смотрим, где я показывал чтение и запись в unsafe-обертку:
http://www.rsdn.org/forum/dotnet/7187427.1

    fixed (int* intArray = indexer.array)
    {
        var array = new UnsafeIntArray2D(intArray, dx, dy);

На всяк случай напомню, что переменная intArray является константной, т.е. переменную под fixed нельзя изменять.
Это значение можно лишь:
— передать куда-то (поле для ошибок всё еще очень узко);
— записать по указателю или прочитать из него, что заведомо абслютно безопасно, бо такова суть выражения fixed.

Смотрим код далее:

array[x, y] = rnd.Next();
...
sum += array[x, y];

Доступ как к обычному массиву, бояться нечего.


S>А для linq код порождает тупая неумолимая железяка, которая не делает ошибок.

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

Там только для одного блура есть несколько стратегий:
— продление крайних пикселей (не самая лучшая стратегия для некоторых радиусов блура, бо может получиться "тельняшка" по краям);
— продление крайних пикселей с прозрачностью с градиентом на радиус блура (тут можно позвать Вольфхаунда, он за альфа-канал всех порвёт)) );
— указание цвета бесконечности;
— отражение рисунка по всем 4-м краям;
— оба предыдущих так же с градиентом прозрачности.

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

Помимо блура я давал еще кучу популярных эффектов.
И всё еще настаиваю, что все эти подробности являются неотъемлимой частью алгоритма и им самое место в самом же алгоритме.


S>Нет, не надо. Я же показал код — там нет никаких проверок, и при этом всё безопасно.

Минимум одна проверка есть — юзверская.


V>>Cамая издевательская тут последняя строка z — внутри Span<> всё-равно происходят проверки выхода за диапазон, хотя на строке x мы вышли за диапазон массива без проблем.
V>>Тоже налицо улыбающие попытки совместить ужа с ежом.
S>Налицо непонимание идеи, стоящей за Span<T>.

Ой, блин.
Сходил бы на гитхаб CoreFX, там были эпичное обсуждения насчёт этого Span, Memory, Sequence и т.д.


S>1. Обеспечить возможность писать алгоритмы, которые универсально применимы к данным в хипе, на стеке, и в неуправляемой памяти.

Да.


S>2. Обеспечить высокую эффективность.

Да.
Но за счёт игнора ошибок обращений к памяти.
Я же именно это только что продемонстрировал.


S>В частности, вот в таком цикле проверки на выход за границы делаются 0 раз:
S>

for(int i=0; i<a.Length; i++) Console.WriteLine(a[i]);

Я же говорил, что ты должен был быть вкурсе?
Ну и вот.


S>А в таком — 1 раз:
S> var s = new Span<int>(a, a.Length-1); // вот здесь делается единственная проверка

Во-первых, такой сигнатуры нет, есть чуть другая, с 2-мя проверками.
Во-вторых, еще раз, вот "это" живёт в той же сборке, что и Span<>:

MemoryMarshal.CreateReadOnlySpan(ref a[0], a.Length + 1);

Никакого тебе пина, никакого unsafe, т.е. в случае unsafe все хоть инстинктивно внимание включают, бо яички-то втягиваются... ))
А тут делай что хошь, гуляй по памяти.
Потому что проверка смешная.


S>Для перехода между вторым и третьим случаями нам и полезен Span<T>.

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

В общем, вышло на троечку.


V>>Когда весь алгоритм у нас перед глазами, т.е. мы заведомо "обслужили единички", которые ты предлагал "вручную не обслуживать" (С), то мы можем не делать проверок на каждой итерации, бо у нас прямо перед глазами находится причина, разрешающая нам избегать проверок.
S>Мы — можем. Джит — нет. Он недостаточно умён, чтобы заметить, что мы учли размер ядра в диапазонах обхода.

А как ты учёл?
Через KernelMeasure? ))

Мне уже поднадоело напоминать, что это означает чёрти-что в прикладном плане.

Но фик с ним уже с прикладным планом, а так:

    int _x;
    public int x => (_x++)/100;
    ...
    from d in data select (d[-x, 0] + d[x, 0] + d[0, -x] + d[0, x])

А мужики-то linq и не в курсе...


S>Отказаться от проверок в дотнете можно только одним способом — адресной арифметикой.

Если бы только в дотнете. ))
О чём и речь.


S>Лепить адресную арифметику в каждом конкретном цикле — боже упаси.

Спрячь за хелперами.


S>А если мы захотим туда припилить SIMD интринсики и/или многопоточность, то там вообще будет туши свет.

Тоже спрячь за хелперами.

Вплоть до того, что можно через foreach организовать на хелперах, типа так:

foreach(row in array.Slice(+1, -1))    // пусть отрицательное число означает отсчёт с конца
  foreach(cell in row.Slice(+1, -1))
      cell.Put((cell[-1, 0]+cell[1, 0]+cell[0, -1]+cell[0, 1])/4);

Итого, две проверки в начале плюс две проверки на каждую строку.
А на каждую точку гнать уже без проверки.
ИМХО, вполне себе компромисс.


S>Такие вещи перемешивать с прикладным кодом строго противопоказано.

Да куда ты денешься? ))
Аппелировать своим мини-примером, мол, "вот же делся" тут бесполезно более чем.


V>>Получил при попытке обобщения противоречивые инварианты для того самого базового решения.
S>Пока что никаких противоречий я не вижу.

А, ну да.
Если зрение специальным образом поднастроить.

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


S>Задача была не в том, чтобы сделать код MSIL-генератора идеальным, понятным, и расширяемым. Задача была вообще проверить, можно ли заинлайнить делегат принудительно;

Делегат?
Конечно можно.
А зачем это "проверять"?
Можно даже собственный метод сгенерить вместо его Invoke.
Не пробовал? — попробуй.

Одно но — если делегат хранит ссылку не на статический метод, а на метод некоего объекта, то при таком инлайне надо заводить переменную на стеке и копировать туда этот объект. Учёл?


S>можно ли извлечь информацию о размере ядра программно

Ну вот я показал как поломать.


S>и можно ли устранить проверки выхода за границы, оставив код безопасным.

Не зная подробностей алгоритма?
Одноначно нельзя, ес-но.


S>Пока что в качестве черновика годится.

И я про то же.


V>>Тем более, что в итоге и обобщённого решения не получилось, и частного тоже.
V>>Подай в свой алгоритм матрицу {{2, 2}, {2, 2}} и убедись, что с4 блур обсчитывается не правильно. ))
S>Он обсчитывается ровно настолько же правильно, как и для матрицы 3x3. А что будет с матрицей в вашем алгоритме?

Ну я там тебе перечислил россыпь их — ткни в любой, посчитаю. ))

"Мою" версию я уже обрисовывал — тело отдельно, краевые эффекты отдельно.
Вот здесь отделять мух от котлет можно и нужно.

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

V>>Лаконично если — не надо врать.
V>>Остальное вторично.
D>Надо начинать переставать повторять мантру «все врут».

Думаешь?
Инженер должен быть честен не то, что перед коллегами, но даже перед самим собой.

Мы же не интимные подробности обсуждаем, хосподя, а всего-навсего технические мелочи, здесь-то чего интриги разводить?
Все должно быть максимально прозрачно.
Оно же как:
Не договорил что-то важное? — соврал другим.
Закрыл глаза на что-то важное? — соврал себе.
Поленился провести комплексную оценку собственного решения? — соврал и себе и окружающим.
На голубом глазу проигнорил замечание насчёт последнего? — разновидность хамства, неумение работать в команде.

Тут даже общаясь на форуме можно с большой долей вероятности понять, кто работает в команде, а кому доверяют, считай, лишь в одиночку ковырять выделенные задачи. ))

Отдельной строкой проходили некоторые свежеиспечённые ПМ или лиды, примерно до ~5 лет этой деятельности, потом спесь постепенно улетчивается.
В общем, зоопарк еще тот.
Хотя, казалось бы — было бы с чего.

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

V>Синклер — один из самых токсичных собеседников на этом сайте.
V>К тому же, склонен к манипуляциям, выыворачиванием слов оппонентов и просто к глумлению, не связанному вообще ни с чем — ни с темой обсуждения, ни с аргументами оппонента.
V>В ответ время от времени получает по заслугам.

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

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

V>>В ответ время от времени получает по заслугам.
I>По моему, ты здесь не Синклера описал, а себя самого.

Чья бы корова мычала, как грится.
За тобой вообще грешок водится сдуру на людей бросаться.
Т.е. еще минуту назад ничего не предвещало беды, и вот уже ты сыпешь проклятиями на окружающих.
Другим хоть ритуал какой-то нужен.
Ну там постепенный разогрев, разошлись на 30 шагов и т.д...

Тебя спасает только нелепость таких закидонов, бо всерьёз не воспринимают.
Максимум реакция из разряда "что это было, Ватсон?" ))

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

<оффтопик (обсуждение личности)>

V>Синклер — один из самых токсичных собеседников на этом сайте.

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

Ну и кстати лично для меня Синклер особенно ценен именно тем, что при всей своей личной адекватности и уме имеет по очень многим пунктам (и linq и декларативность и управляемый код и много ещё чего) противоположную мне точку зрения. Это вообще супер редкость на данном форуме (разве что Sinix могу припомнить как ещё одно исключение), т.к. почему-то тут так сложилось, что многие приверженцы данной точки зрения или полные неадекваты (фанатики) или просто пустые болтуны (я немало таких из КСВ уже отправил в игнор, т.к. они не стоят моего времени). Ну а наличие на форуме множества адекватных людей с близкой мне позицией никакой пользы не приносит — спорить то с ними не о чем. )))

</оффтопик>

Что касается основной дискуссии, то я вижу тут у Синклера только одно абсолютно не верное утверждение:

Linq используется для того, чтобы разделить стратегю исполнения и сам "запрос".

Это полная чушь, т.к. для разделения используется банальный делегат, а linq тут не нужно в принципе. Причём он по сути сам в этом "признаётся" здесь http://rsdn.org/forum/flame.comp/7194415.1:

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

_>Собственно опять же отсутствие разбора AST и отсутствие необходимости в Linq (оно здесь опять же исполняет никчемную роль "запускателя лямбд").
Тут важен не столько сам linq, сколько идеология разделения алгоритма обхода и алгоритма обработки "окрестности".

P.S. Вообще то я данный раздел форума не читаю. А пришёл в данную темку как раз по наводке Синклера...

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

V>>Синклер — один из самых токсичных собеседников на этом сайте.
_>Вот тут я с тобой полностью не соглашусь.

Это потому что ему еще есть чего с тобой терять. ))
Да, я вижу, как он лишний сдерживается в ответах тебе.
Прям паинька, любо-дорого посмотреть.

Скорее всего, после жутких баталий 2004-2005 г.г. перед участниками тех баталий ему терять уже нечего, вот он и не парится, а заходит сразу с козырей. ))
С одних и тех же.

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

_>Linq используется для того, чтобы разделить стратегю исполнения и сам "запрос".

_>Это полная чушь, т.к. для разделения используется банальный делегат, а linq тут не нужно в принципе. Причём он по сути сам в этом "признаётся" здесь http://rsdn.org/forum/flame.comp/7194415.1:

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

_>[q]


Ну вот здесь Optimising LINQ https://github.com/antiufo/roslyn-linq-rewrite
используются не банальные делегаты. Тот же Linq to SQL. Там вообще о делегатах нет речи. Там только деревья выражений.

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

V>Скорее всего, после жутких баталий 2004-2005 г.г. перед участниками тех баталий ему терять уже нечего, вот он и не парится, а заходит сразу с козырей. ))
V>С одних и тех же.

Может ты покажешь, где же Синклер тебе нахамил ? А то по всему топику только твоё хамство.

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

V>Смотрю, на много фронтов умудряешься ругаться:
Ты за других не впрягайся, там свой комплекс не полноценной мании величия =)

V>Специалист по MS SQL, ага. ))
Я не претендую ))

V>Слово предоставляется Синклеру:
Что из процитированного тобой, тебе не понятно? Ты спрашивай конкретно, я расскажу

V>Не мной.
Конечно не тобой, ты просто слился, когда тебя попросили решить нужную задачу или привести конкретный пример.
Ты на других не кивай. Тебя попросили, ты срулил, собственно все. Что там сделали остальные — это отдельный разговор, тебя это не оправдывает.

V>Так шта, опять поздравляю тебя соврамши.
В чем?

V>Доводы твои где?
Доводы в том, что как доходит до дела тебе резко становится лень обсуждать. Зато как другим по хамить — ты первый )

V>Отмазываться от чего?
От своих косяков )

V>И тебя не смущает, что для этой уникальной задачи IL-генератор является наихудшим решением?
Так предложи свое... )

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

V>Или кто-то у нас отчаянно юлит, бегает, играет в прятки? ))
Ага, и это ты )

V>Я вполне чётко сказал, что именно я "решил"
Да, и это какая-то совершенно левая задача. =)

V>Я отвечаю за свои слова, в отличие от.
Нет, не отвечаешь. Ты стремительно сливаешься как только дело доходит до конкретики.

V>Пока что более выглядит как последнее, т.е. много на себя берёте, молодой человек.
Ай как красиво рвануло =))

V>Да не твоё форумного хамла дело.
Ну почему же, ты же сам разрешил мне по докапываться? Вот, пользуюсь =)
Или ты опять от своих слов отказываешься?)

V>>>Я демонстрировал "недоговорённости" в коде Синклера.
IB>>Но едиственное что тебе удалось продемонстрировать это собственную ущербность и не способность адекватно вести дискуссию.
V>ЧТД.
Собственно да. Хорошо что ты это понимаешь ))

V>Так-то, о чём с тобой вообще говорить?
Не хочешь — не говори, никто не заставляет ))


V>>>А где я предоставил готовое к тестам решение исходной задачи?
IB>>Ты предоставил достаточно, чтобы понять, что ты накосячил.
V>Вопрос-то в силе — где я предоставил готовое к тестам решение исходной задачи?
Ответ тоже в силе, ты предоставил достаточно, что бы все было понятно про тебя и твое решение. )
Повторим еще раз? )

V>Ну и где я могу взять целиком решение задачи от ТС?
Могу еще раз повторить, если с первого раза не дошло. Для того, чтобы предоставить собственное решение, тебе не нужно чужое. Тебе достаточно условия задачи, и условие было дано.
Ты просто не справился. ))

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

V>Пардон, я что-то пообещал и не предоставил?
Да. Ты утверждаешь, что решил задачу, но нет. =)

V>Не приписываете ли вы мне свои замашки, сударь?
Нет. Я приписываю тебе твои же замашки )) А свои замашки окружающим приписываешь ты =)

V>Ой, блин, опять эта хрень в стиле "отстаньте от меня, а то обижусь".
Не, тут у нас ты специалист. Тягаться с тобой на этом поле я не возьмусь ))

V>Смотрю, с тобой спорить — как бить ребенка.
V>Показываю на раз-два:
V>Но как ты мог сейчас умудриться написать "решение другой задачи, причём умудрился ошибиться"?
V>Откуда ты знаешь, насчёт "ошибиться", если "другая задача"?
Ой, да у нас с логикой проблемы! А еще ты детей бъешь )))
Ты сам, наглядно продемонстрировал, как можно ошибиться при решении даже собственной задачи, а не той которая нужна была))

V>Может, она в том и состояла — пройтись алгоритмом навроде c4 по этому же массиву?
Может. А может и нет... Но тебе это не помогло =)

V>Че за бред, ваще.
Ох как красиво рвануло! =) Я обещал, что будет весело? И вот ))
Как видишь, я за свои слова отвечаю и обещания держу. =)
Кто молодец? Я молодец!

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

_>

_>Linq используется для того, чтобы разделить стратегю исполнения и сам "запрос".

_>Это полная чушь, т.к. для разделения используется банальный делегат, а linq тут не нужно в принципе.

Чегой-то? Один интерфейс к данным (select from), а стратегия исполнения разная -- объекты в памяти, бд, xml и т.д.

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

I>Может ты покажешь, где же Синклер тебе нахамил ? А то по всему топику только твоё хамство.

Ты имеешь ввиду моё выражение "трюкач" в его адрес?
Это было настолько страшно, что теперь IB безвозвратно сломал себе моск? ))

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

V>>Смотрю, на много фронтов умудряешься ругаться:
IB>Ты за других не впрягайся, там свой комплекс не полноценной мании величия =)

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

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

S>Чегой-то? Один интерфейс к данным (select from), а стратегия исполнения разная -- объекты в памяти, бд, xml и т.д.

БД, XML — это уже IQueryable, другие перегруженные сигнатуры.

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

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

S>>Чегой-то? Один интерфейс к данным (select from), а стратегия исполнения разная -- объекты в памяти, бд, xml и т.д.

V>БД, XML — это уже IQueryable, другие перегруженные сигнатуры.


A IQueryable это не Linq

public interface IQueryable<out T> : IEnumerable<T>, IEnumerable, 
    IQueryable?

https://metanit.com/sharp/tutorial/15.1.php

LINQ (Language-Integrated Query) представляет простой и удобный язык запросов к источнику данных. В качестве источника данных может выступать объект, реализующий интерфейс IEnumerable (например, стандартные коллекции, массивы), набор данных DataSet, документ XML. Но вне зависимости от типа источника LINQ позволяет применить ко всем один и тот же подход для выборки данных.

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

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

S>>Чегой-то? Один интерфейс к данным (select from), а стратегия исполнения разная -- объекты в памяти, бд, xml и т.д.

V>БД, XML — это уже IQueryable, другие перегруженные сигнатуры.

Что значит другие? Такие же.

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

S>>>Чегой-то? Один интерфейс к данным (select from), а стратегия исполнения разная -- объекты в памяти, бд, xml и т.д.
V>>БД, XML — это уже IQueryable, другие перегруженные сигнатуры.
S>A IQueryable это не Linq
S>

S>public interface IQueryable<out T> : IEnumerable<T>, IEnumerable, 
S>    IQueryable?
S>

Дык, дело-то в реализации интерфейсов.
Например из LinqToDb:

        IEnumerator<T> IEnumerable<T>.GetEnumerator()
        {
            var expression = Expression;
            var query      = GetQuery(ref expression, true);
            Expression     = expression;

            return query.GetIEnumerable(DataContext, Expression, Parameters).GetEnumerator();
        }

Тут выполняется куча нетривиальных действий по генерированию тела генератора запроса, затем генерирования самого запроса или доставанию его из кеша, выполнения запроса к БД, генерирования OR-маппера или доставания того из кеша, затем маппинга строк на объекты, затем возврата результата в виде IEnumerator<T>.


S>LINQ (Language-Integrated Query) представляет простой и удобный язык запросов к источнику данных. В качестве источника данных может выступать объект, реализующий интерфейс IEnumerable (например, стандартные коллекции, массивы), набор данных DataSet, документ XML. Но вне зависимости от типа источника LINQ позволяет применить ко всем один и тот же подход для выборки данных.

ИМХО, тут имелось ввиду, что внешне подход один и тот же.

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

V>>БД, XML — это уже IQueryable, другие перегруженные сигнатуры.
S>Что значит другие? Такие же.

Сравни методы-расширения:

public static class Queryable {
...
    public static IQueryable<TResult> Select<TSource, TResult>(this IQueryable<TSource> source, Expression<Func<TSource, TResult>> selector);

vs

public static class Enumerable {
...
    public static IEnumerable<TResult> Select<TSource, TResult>(this IEnumerable<TSource> source, Func<TSource, TResult> selector);