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

PD>>К чему я это ? А просто к тому, что когда от такого алгоритма требуется максимальная скорость — это предельно далеко от задачи "напишите мне красиво и изящно".
S>Так не может быть Хорошее инженерное решение — всегда красиво.

Это при наличии инструмента, заточенного на такое решение.
"Некрасивости" всегда из-за попыток выкрутиться "на чём есть".

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

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

Странные у тебя порой порывы из мира BDSM тщательно напрашиваться на быть посланным в самой грубой форме. ))
Ты эта, не перегибай-то, вернись на землю-то...

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

S>Вся "лапша" — в моём коде.
S>В коде прикладного программиста ничего этого нет.

Дудки. В реальной разработке и тот и другой код будет твоим.

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

V>Попробовал в студии, вот так в цикле
V> *с++ = value;
V>работает примерно на 25% медленней, чем вот так:
V> *с = value; c++;

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

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

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

S>>Можно всё же в студию полное тело метода FourNeighborAverage?
S>>Можете, если хотите, сделать его generic с where T: Struct, IArray2d<T>.

V>Разумеется генерик, ради ж этого всё.
V>Без студии:
V>

V>void FourNeighborAverage<T>(T array) where T : struct, IArray2d<int>
V>{
V>    for(int y = 1, dy = array.DY - 1; y < dy; y++)
V>    for(int x = 1, dx = array.DX - 1; x < dx; x++)
V>            array[x, y] = array[x-1, y] + array[x+1, y] + array[x, y-1] + array[x, y+1];
V>}
V>

V>Что здесь "так" в сравнении с твоим вариантом?
Ну, во-первых, в этом коде — две ошибки.
1. Забыл поделить на 4.
2. Забыл, что array[x, y] будет прочитан на следующей итерации, а он к этому моменту уже испорчен присваиванием. Надо усреднять в другой массив.
V>Учитывая новый ref-return, можно попробовать пойти еще дальше:
V>

V>[cs]
V>interface IArray2d<T> {
V>    ...
V>    ref T this[int x, int y] { get; } // только геттер
V>}
V>...
V>unsafe void FourNeighborAverage(T array) where T : struct, IArray2d<int>
V>{
V>    int dx = array.DX;

V>    for(int y = 1, dy = array.DY - 1; y < dy; y++) {
V>        fixed(int* current = array[1, y])
V>        fixed(int* end = array[dx, y])
V>        fixed(int* it1 = array[0, y])
V>        fixed(int* it2 = array[2, y])
V>        fixed(int* it3 = array[1, y - 1])
V>        fixed(int* it4 = array[1, y + 1]) {
V>            int* c = current, _1 = it1, _2 = it2, _3 = it3, _4 = it4;
V>            while(c < end)
V>                *c++ = *_1++ + *_2++ + *_3++ + *_4++;
V>        }
V>    }
V>}
V>

Здесь добавлена ещё одна ошибка.
S>>Меня интересует не "индексер" (предоставленный, потенциально, библиотекой), а полный код, который должен писать прикладной программист.
V>А другой программист должен будет еще этот код читать, верно?
Совершенно верно. К примеру, сколько времени уйдёт у другого программиста на то, чтобы разобраться вот в этой лапше с fixed и найти в ней ошибку?

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

S>Ну, во-первых, в этом коде — две ошибки.
S>1. Забыл поделить на 4.
S>2. Забыл, что array[x, y] будет прочитан на следующей итерации, а он к этому моменту уже испорчен присваиванием. Надо усреднять в другой массив.

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


V>>Учитывая новый ref-return, можно попробовать пойти еще дальше:
V>>[cs]
V>>[cs]
V>>interface IArray2d<T> {
V>> ...

S>Здесь добавлена ещё одна ошибка.

ага
еще апмерсенды не стоят

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

Я думаю, что ошибку ты нашел сразу же, просто читая код.
А ошибки синтаксиса подскажет студия или компилятор (забытые амперсенды).
Поэтому, правильный ответ — нисколько.

И да, протягивание курсоров по памяти — это не лапша, а стандартный подход к таким вещам.
Кто их программирует, тому читается нормально.

================
Хотя, как заметил рядом, это всё называется "использование инструмента не по назначению".
Бо на выходе и у тебя и у меня — полная хрень, положа руку на.
Особенно у тебя. )))
На плюсах это записывается всяко проще, а абстракции над произвольными структурами данных делаются еще на порядки проще.

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

Работать с ними страшно неудобно как в сравнении с обычными типизированными генериками, так и в сравнении с полностью нетипизированными шаблонными параметрами в плюсах.
Даже взять твои рассуждения в первом же посте этой серии — ведь хорошо же видно, что надо еще и ПРИДУМАТЬ, как раскидать абстракции и каким идентификаторам какие ответственности назначить. ПРИДУМАТЬ тут капсом, бо простого/естественного назначения ответственностей не получается из-за мгновенно возникающих конфликтов или неподдерживаемых языком конструкций. ))

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

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

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

V>>Сорри, но на конкретный алгоритм пелевать...
_AB>Извини, но что ты тогда сравнивал по производительности?

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


_AB>Сознательно сравнивал решение Синклера с другим алгоритмом, да еще содержащим логические ошибки?

Это к Синклеру, а не ко мне.
Он до сих пор так и не дал полный код, пригодный для сравнения.
Он пока дал только несколько вариантов "оберток", я тоже дал несколько вариантов.

Я его, кстате, уже дважды попросил дать полный код для сравнения — реакции ноль.
Попахивает сливом.

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

V>Я сравнивал эффективность различных техник реализации абстрактных оберток над различными типами массивов.
ЕМНИП, задача несколько более конкретная, всё-таки, поставлена в топике.

V>Он до сих пор так и не дал полный код, пригодный для сравнения.
И это печально.

Но не менее печально, что ты подменяешь задачу на более удобную тебе, допускаешь ошибки в реализации и
считаешь, что это допустимо. По сути, ты с одной стороны пеняешь Синклеру на некоторые методы ведения
дискуссии (вполне справедливо, ИМХО), а с другой сам ведешь себя точно так же, если не хуже.

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

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

V>>Я сравнивал эффективность различных техник реализации абстрактных оберток над различными типами массивов.
_AB>ЕМНИП, задача несколько более конкретная, всё-таки, поставлена в топике.

Законченного решения я так и не увидел.


V>>Он до сих пор так и не дал полный код, пригодный для сравнения.
_AB>И это печально.

Ну и? Мне-то ты зачем всю эту ерунду пишешь?
Я себя уже обозначил:
http://www.rsdn.org/forum/dotnet/7188188.1


_AB>Но не менее печально, что ты подменяешь задачу на более удобную тебе

Не перегибай.
Я декомпозировал задачу и успешно решил часть её.
Это нормальный ход любой разработки.


_AB>допускаешь ошибки в реализации

В предоставленных вариантах индексеров ошибки не было.


_AB>считаешь, что это допустимо.

Считаю, что речь до законченного алгоритма еще не дошла, бо топикстартер тянет резину.

Поэтому, я набросал схематический код от руки без студии и без запуска за 10 сек прямо в сообщении, бо Синклер простачка включил "а как этим всем пользоваться?" ))
Да никак, выкинуть компьютер и идти в дворники, если подобная примитивщина вопросы вызывает.
В таких местах и начинается, собсно, неконструктив и остальная ненужная хрень.


_AB>Мне бы, как стороннему наблюдателю, было бы приятнее наблюдать содержательную дискуссию, как у Синклера с
_AB>Дворкиным (извини, Павел, если переврал фамилию или имя — память плохая, да лень хорошая), а не постоянные
_AB>нападки на личность оппонента и махинации с нечистоплотностью.

На содержательную дискуссию у Синклера должно появиться соответствующее настроение, т.е. это вопрос везения и флуктуации его эмоционального состояния.
Мне же приходится пробираться сквозь такое:
http://www.rsdn.org/forum/dotnet/7188062.1
"Я так и думал" (С)

Если бы он действительно думал, то написал бы чуток другое.

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

_AB>Но не менее печально, что ты подменяешь задачу на более удобную тебе

Минус за "подменяешь задачу".
Тут целых 3 топика от ТС не по исходной задаче, а сугубо по различным техникам её реализации.
Я тоже прошелся именно по разным техникам реализации.
Но ты спалился на ангажированности или невнимательности, на выбор. ))

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

V>>Он до сих пор так и не дал полный код, пригодный для сравнения.
_AB>И это печально.

Если уж совсем начистоту, то я прекрасно понимаю, почему Синклер не выкладывает решение целиком.
Он воробей уже стрелянный и прекрасно понимает, что за этим будет. ))
Там ведь дело не в том, что он пустился в эксперименты с IL-генератором — это всё так, забавно, познавательно, но не настолько принципиально.
Архитектурный просчёт я увидел еще в самом первом его сообщении и мне было любопытно — а как он теперь из этого всего выкрутится-то? ))
"Красиво" если — да никак.
Его LINQ-хелперы необходимо прибивать гвоздями к конкретным алгоритмам.
И вот именно за это ему не хочется огребать. ))

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

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

V>Если уж совсем начистоту, то я прекрасно понимаю, почему Синклер не выкладывает решение целиком.

Синклер прямо написал, что это эксперимент, попытка выяснить, что же можно упрятать за фасадом query comprehension для конкретной задачи и в конкретных условиях — ради оптимизации
ни чего не менять в вызывающем коде. Так что придирки неуместны.

>Его LINQ-хелперы необходимо прибивать гвоздями к конкретным алгоритмам.

В этом и состоит эксперимент.

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

I>Синклер прямо написал, что это эксперимент

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


I>попытка выяснить, что же можно упрятать за фасадом query comprehension

Спустя десяток лет после выхода LINQ?
Спросил бы меня лет 10 назад, я бы сразу объяснил — что на нём можно, а что лучше и не пытаться. ))


I>Так что придирки неуместны.

А чего ж тогда придирки в адрес кого-то другого уместны?
Совсем со своим дотнетом с ума сходите...
Раздражаете как обычно своей необъективностью на грани упоротости.


>>Его LINQ-хелперы необходимо прибивать гвоздями к конкретным алгоритмам.
I> В этом и состоит эксперимент.

Садись, два.
Эксперимент состоял не в этом, см. первое сообщение.

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

I>>попытка выяснить, что же можно упрятать за фасадом query comprehension

V>Спустя десяток лет после выхода LINQ?
V>Спросил бы меня лет 10 назад, я бы сразу объяснил — что на нём можно, а что лучше и не пытаться. ))

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

V>Садись, два.
V>Эксперимент состоял не в этом, см. первое сообщение.

Надо читать ширше. Тема растянута по четырём топикам.

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

I>В другом топике некий alex_public утверждает, что ничего подобного невозможно, на linq всё тупит и морозит из за рефлексии.

И еще делегатов.
Так и есть, это объективная реальность.

Достаточно было пару раз замерить еще по выходу этой технологии (что многие сделали фактически сразу) и там всё стало ясно.


I>Вот Синклер и взялся развенчать этот миф.

Никакого мифа нет.


I>Собтстсвенно, Синклер явно обозначил эту цель. Похоже, что ты нечитатель.

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


I>Надо читать ширше. Тема растянута по четырём топикам.

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

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

I>>В другом топике некий alex_public утверждает, что ничего подобного невозможно, на linq всё тупит и морозит из за рефлексии.

V>И еще делегатов.
V>Так и есть, это объективная реальность.

Вот такой вот миф Синклер и развенчивает.

I>>Вот Синклер и взялся развенчать этот миф.

V>Никакого мифа нет.

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

Почему у Синклера вышло вдвое быстрее ? Полагаю, это такие тормоза нынче, с отрицательным замедлением ?

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

V>>И еще делегатов.
V>>Так и есть, это объективная реальность.
I> Вот такой вот миф Синклер и развенчивает.

Давай дождёмся когда развенчает. ))


I>>>Вот Синклер и взялся развенчать этот миф.
V>>Никакого мифа нет.
I>Ты вот утверждаешь, что реальность такая, то есть, что линк тупит и морозит из за рефлексии.

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

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

Ты слышал мем "собачья еда" применительно к IT?
Если не знал, посмотри внимательно на происходящее унутре в Линке — это она и есть.
Теперь ты в курсе.


I>Почему у Синклера вышло вдвое быстрее ?

Потому что он вешает вам лапшу на уши, мухлюет — вместо сравнивания быстродействия линка начал со сравнения скорости работы одномерного дотнетного массива vs двумерного, но подал это так, что дело якобы в линке.
Тебе вилы для лапши прислать?


I>Полагаю, это такие тормоза нынче, с отрицательным замедлением ?

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

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

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

А можно узнать, у нутре линка не так? И как должно быть так?

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

S>А можно узнать, у нутре линка не так? И как должно быть так?

Linq сформулирован в терминах IEnumerable<T>/IEnumerator<T> вместо constrained TEnumerable/TEnumerator, в то время как приличные Enumerator'ы — значимые типы (вопреки стандартным рекомендациям про изменяемые структуры). Это приводит к боксингу, и в performance critical коде не рекомендуется:

Avoid LINQ.

https://github.com/dotnet/roslyn/wiki/Contributing-Code