Сообщение Re[49]: The door от 16.07.2018 8:52
Изменено 16.07.2018 8:55 vdimas
Re[49]: The door
Здравствуйте, IB, Вы писали:
V>>Опять брехня, никто манипуляции не разводил.
IB>Я их наглядно продемонстрировал. )
Ты показал умение написать слово "манипуляция" без грамматических ошибок, разве что.
Манипуляция — это когда сознательно недоговаривают, врут, играют одновременно на неполной информации и на эмоциях.
Ничего из этого Алекс не делал, разумеется, т.е. ты на него клевещешь.
Зато вы с Синклером только этим и заняты.
V>>Очевидно, Алекс имел ввиду имеющуюся функциональность линка и имеющиеся способы описания контракта к линку.
IB>Что такое "функциональность линка"
Это имеющиеся Enumerable и Queryable классы, плюс правила маппинга синтаксиса языка выражений на обычные методы или на методы расширений.
IB>и какие способы описания контракта у нас имеются?
Для рассматриваемого случая select всего 2 по 2:
— функциональная лямбда по элементу
— функциональная лямбда по элементу+индексу
— дерево выражений лямбды по элементу
— дерево выражений лямбды по элементу+индексу
Это всё.
Для случая Синклера и вовсе только первый вариант.
Т.е., прикладной контракт при вызове select протягивать банально некуда.
Этот контракт можно попытаться завернуть в саму "лямбду", т.е. манипулировать контрактом при каждом обращении к элементу.
Получается возврат на круги своя — ноль оптимизаций.
Берем другую технику — накручиваем контракт поверх самих "коллекций", мол, тогда функциональность "контракта" работает однократно.
Здесь спотыкаемся о необходимость стирания типов.
Т.е., если типы не стирать, то комбинаторный взрыв из более-менее полной библиотеки оперируемых контрактов быстро улетит в бесконечность.
А если типы стирать, то всегда будет лишний боксинг.
Собсно, подробно на всё это я уже отвечал, но ты мне почему-то отписывался совсем по другому поводу.
Ну и, технике Linq уже 13 лет, хорошо же видно, какие задачи на нём решают, а какие даже не пытаются.
Или пытались, что скорее всего, но по итогам на свет божий решили не выкатывать. ))
Т.е. Алекс, не обладая глубокими знаниями конкретно по дотнету, но обладая достаточным инженерным опытом, вполне мог сделать "реверс инжиниринг" такого положения дел, бо законы больших чисел — они ведь неумолимы.
Т.е. если ВООБЩЕ ВСЯ отрасль в течении аж 13-ти лет даже не пытается так делать, значит на это есть серьёзные причины, не?
V>>1. С неустранимыми ошибками:
IB>Пока что неустранимая ошибка только у тебя в голове.
Во-во, опять гавнецо в ответ на сугубо технический аргумент.
Слился.
V>>2. "В лоб циклами" (С) можно обращаться к двумерному массиву примерно вдвое быстрее:
V>>http://www.rsdn.org/forum/dotnet/7187427.1
V>>А если протягивать в цикле курсоры, то более чем втрое быстрее:
V>>http://www.rsdn.org/forum/dotnet/7188188.1
IB>Мало того, что это не так
Дык, развенчай!
IB>так это еще и не имеет отношения к продемонстрированному подходу.
Наоборот, я сначала посмотрел подход, потом попытался наваять что-то типа такого же, только без IL-генератора и без linq.
Там внутри просто unsafe-цикл.
4-й по счёту мой "индексер", даже который не протягивает курсоры, а просто является относительно безопасной обёрткой, показывает почти вдвое ускорение операции доступа к двумерному массиву.
IB>Даже если бы тебе удалось придумать способ, который в десять раз быстрее чем то, что предложил Антон, то это все равно бы доказало его позицию.
При условии, если бы ему удалось придумать способ безопасного обхода массива.
Ему это пока что не удалось:
Причём, здесь просто выжимка/суть, а в реальном коде такая ситуация может возникнуть через какое-нить прикладное сочетание вызовов.
Я несколько раз говорил это словами (тут же, по-идее, собрались люди, понимающие дотнете, не?)
Пришлось даже написать в чём проблема, и внятной реакции на это до сих пор не вижу.
IB>Потому что, (вот сейчас, еще раз, внимательно) линк не про реализацию, а про то, как отделить реализацию от ее использования.
Да без проблем, если бы такое разделение не нарушало бы прикладной контракт.
V>>Он попросил это выразить через линк понятно зачем — чтобы "спорщики" сами убедились в его тормознутости.
IB>Именно. Но почему-то получилось наоборот, утверждатели в тормознутости вынуждены были придумывать, почему это не линк.
Мои хелперы показали, почему это не линк. ))
V>>А затем спросил, зачем приписали то, что сделали (а написано было, помимо решения целевой задачи, примерно в 300 раз больше кода) св-вам именно линка?
IB>А теперь вернемся к началу. Что такое "свойства именно линка"?
Давай вернёмся.
Это способ маппинга выражений языка запросов на методы объектов или на методы-расширения.
Мой мнение тут простое — сам этот способ маппинга НЕ расширяемый, поэтому прикладной контракт "подавать" некуда.
V>>Опять брехня, никто манипуляции не разводил.
IB>Я их наглядно продемонстрировал. )
Ты показал умение написать слово "манипуляция" без грамматических ошибок, разве что.
Манипуляция — это когда сознательно недоговаривают, врут, играют одновременно на неполной информации и на эмоциях.
Ничего из этого Алекс не делал, разумеется, т.е. ты на него клевещешь.
Зато вы с Синклером только этим и заняты.
V>>Очевидно, Алекс имел ввиду имеющуюся функциональность линка и имеющиеся способы описания контракта к линку.
IB>Что такое "функциональность линка"
Это имеющиеся Enumerable и Queryable классы, плюс правила маппинга синтаксиса языка выражений на обычные методы или на методы расширений.
IB>и какие способы описания контракта у нас имеются?
Для рассматриваемого случая select всего 2 по 2:
— функциональная лямбда по элементу
— функциональная лямбда по элементу+индексу
— дерево выражений лямбды по элементу
— дерево выражений лямбды по элементу+индексу
Это всё.
Для случая Синклера и вовсе только первый вариант.
Т.е., прикладной контракт при вызове select протягивать банально некуда.
Этот контракт можно попытаться завернуть в саму "лямбду", т.е. манипулировать контрактом при каждом обращении к элементу.
Получается возврат на круги своя — ноль оптимизаций.
Берем другую технику — накручиваем контракт поверх самих "коллекций", мол, тогда функциональность "контракта" работает однократно.
Здесь спотыкаемся о необходимость стирания типов.
Т.е., если типы не стирать, то комбинаторный взрыв из более-менее полной библиотеки оперируемых контрактов быстро улетит в бесконечность.
А если типы стирать, то всегда будет лишний боксинг.
Собсно, подробно на всё это я уже отвечал, но ты мне почему-то отписывался совсем по другому поводу.
Ну и, технике Linq уже 13 лет, хорошо же видно, какие задачи на нём решают, а какие даже не пытаются.
Или пытались, что скорее всего, но по итогам на свет божий решили не выкатывать. ))
Т.е. Алекс, не обладая глубокими знаниями конкретно по дотнету, но обладая достаточным инженерным опытом, вполне мог сделать "реверс инжиниринг" такого положения дел, бо законы больших чисел — они ведь неумолимы.
Т.е. если ВООБЩЕ ВСЯ отрасль в течении аж 13-ти лет даже не пытается так делать, значит на это есть серьёзные причины, не?
V>>1. С неустранимыми ошибками:
IB>Пока что неустранимая ошибка только у тебя в голове.
Во-во, опять гавнецо в ответ на сугубо технический аргумент.
Слился.
V>>2. "В лоб циклами" (С) можно обращаться к двумерному массиву примерно вдвое быстрее:
V>>http://www.rsdn.org/forum/dotnet/7187427.1
V>>А если протягивать в цикле курсоры, то более чем втрое быстрее:
V>>http://www.rsdn.org/forum/dotnet/7188188.1
IB>Мало того, что это не так
Дык, развенчай!
IB>так это еще и не имеет отношения к продемонстрированному подходу.
Наоборот, я сначала посмотрел подход, потом попытался наваять что-то типа такого же, только без IL-генератора и без linq.
Там внутри просто unsafe-цикл.
4-й по счёту мой "индексер", даже который не протягивает курсоры, а просто является относительно безопасной обёрткой, показывает почти вдвое ускорение операции доступа к двумерному массиву.
IB>Даже если бы тебе удалось придумать способ, который в десять раз быстрее чем то, что предложил Антон, то это все равно бы доказало его позицию.
При условии, если бы ему удалось придумать способ безопасного обхода массива.
Ему это пока что не удалось:
int _x;
public int x => (_x++)/100;
...
from d in data select (d[-x, 0] + d[x, 0] + ...Причём, здесь просто выжимка/суть, а в реальном коде такая ситуация может возникнуть через какое-нить прикладное сочетание вызовов.
Я несколько раз говорил это словами (тут же, по-идее, собрались люди, понимающие дотнете, не?)
Пришлось даже написать в чём проблема, и внятной реакции на это до сих пор не вижу.
IB>Потому что, (вот сейчас, еще раз, внимательно) линк не про реализацию, а про то, как отделить реализацию от ее использования.
Да без проблем, если бы такое разделение не нарушало бы прикладной контракт.
V>>Он попросил это выразить через линк понятно зачем — чтобы "спорщики" сами убедились в его тормознутости.
IB>Именно. Но почему-то получилось наоборот, утверждатели в тормознутости вынуждены были придумывать, почему это не линк.
Мои хелперы показали, почему это не линк. ))
V>>А затем спросил, зачем приписали то, что сделали (а написано было, помимо решения целевой задачи, примерно в 300 раз больше кода) св-вам именно линка?
IB>А теперь вернемся к началу. Что такое "свойства именно линка"?
Давай вернёмся.
Это способ маппинга выражений языка запросов на методы объектов или на методы-расширения.
Мой мнение тут простое — сам этот способ маппинга НЕ расширяемый, поэтому прикладной контракт "подавать" некуда.
Re[49]: The door
Здравствуйте, IB, Вы писали:
V>>Опять брехня, никто манипуляции не разводил.
IB>Я их наглядно продемонстрировал. )
Ты показал умение написать слово "манипуляция" без грамматических ошибок, разве что.
Манипуляция — это когда сознательно недоговаривают, врут, играют одновременно на неполной информации и на эмоциях.
Ничего из этого Алекс не делал, разумеется, т.е. ты на него клевещешь.
Зато вы с Синклером только этим и заняты.
V>>Очевидно, Алекс имел ввиду имеющуюся функциональность линка и имеющиеся способы описания контракта к линку.
IB>Что такое "функциональность линка"
Это имеющиеся Enumerable и Queryable классы, плюс правила маппинга синтаксиса языка выражений на обычные методы или на методы расширений.
IB>и какие способы описания контракта у нас имеются?
Для рассматриваемого случая select всего 2 по 2:
— функциональная лямбда по элементу
— функциональная лямбда по элементу+индексу
— дерево выражений лямбды по элементу
— дерево выражений лямбды по элементу+индексу
Это всё.
Для случая Синклера и вовсе только первый вариант.
Т.е., прикладной контракт при вызове select протягивать банально некуда.
Этот контракт можно попытаться завернуть в саму "лямбду", т.е. манипулировать контрактом при каждом обращении к элементу.
Получается возврат на круги своя — ноль оптимизаций.
Берем другую технику — накручиваем контракт поверх самих "коллекций", мол, тогда функциональность "контракта" работает однократно.
Здесь спотыкаемся о необходимость стирания типов.
Т.е., если типы не стирать, то комбинаторный взрыв из более-менее полной библиотеки оперируемых контрактов быстро улетит в бесконечность.
А если типы стирать, то всегда будет лишний боксинг.
Собсно, подробно на всё это я уже отвечал, но ты мне почему-то отписывался совсем по другому поводу.
Ну и, технике Linq уже 13 лет, хорошо же видно, какие задачи на нём решают, а какие даже не пытаются.
Или пытались, что скорее всего, но по итогам на свет божий решили не выкатывать. ))
Т.е. Алекс, не обладая глубокими знаниями конкретно по дотнету, но обладая достаточным инженерным опытом, вполне мог сделать "реверс инжиниринг" такого положения дел, бо законы больших чисел — они ведь неумолимы.
Т.е. если ВООБЩЕ ВСЯ отрасль в течении аж 13-ти лет даже не пытается так делать, значит на это есть серьёзные причины, не?
V>>1. С неустранимыми ошибками:
IB>Пока что неустранимая ошибка только у тебя в голове.
Во-во, опять гавнецо в ответ на сугубо технический аргумент.
Слился.
V>>2. "В лоб циклами" (С) можно обращаться к двумерному массиву примерно вдвое быстрее:
V>>http://www.rsdn.org/forum/dotnet/7187427.1
V>>А если протягивать в цикле курсоры, то более чем втрое быстрее:
V>>http://www.rsdn.org/forum/dotnet/7188188.1
IB>Мало того, что это не так
Дык, развенчай!
IB>так это еще и не имеет отношения к продемонстрированному подходу.
Наоборот, я сначала посмотрел подход, потом попытался наваять что-то типа такого же, только без IL-генератора и без linq.
Там внутри просто unsafe-цикл.
4-й по счёту мой "индексер", даже который не протягивает курсоры, а просто является относительно безопасной обёрткой, показывает почти вдвое ускорение операции доступа к двумерному массиву.
IB>Даже если бы тебе удалось придумать способ, который в десять раз быстрее чем то, что предложил Антон, то это все равно бы доказало его позицию.
При условии, если бы ему удалось придумать способ безопасного обхода массива.
Ему это пока что не удалось:
Причём, здесь просто выжимка/суть, а в реальном коде такая ситуация может возникнуть через какое-нить прикладное сочетание вызовов.
Я несколько раз говорил это словами (тут же, по-идее, собрались люди, понимающие дотнете, не?)
Пришлось даже написать в чём проблема, и внятной реакции на это до сих пор не вижу.
IB>Потому что, (вот сейчас, еще раз, внимательно) линк не про реализацию, а про то, как отделить реализацию от ее использования.
Да без проблем, если бы такое разделение не нарушало бы прикладной контракт.
V>>Он попросил это выразить через линк понятно зачем — чтобы "спорщики" сами убедились в его тормознутости.
IB>Именно. Но почему-то получилось наоборот, утверждатели в тормознутости вынуждены были придумывать, почему это не линк.
Мои хелперы показали, почему это не линк. ))
V>>А затем спросил, зачем приписали то, что сделали (а написано было, помимо решения целевой задачи, примерно в 300 раз больше кода) св-вам именно линка?
IB>А теперь вернемся к началу. Что такое "свойства именно линка"?
Давай вернёмся.
Это способ маппинга выражений языка запросов на методы объектов или на методы-расширения.
Моё мнение тут простое — сам этот способ маппинга НЕ расширяемый, поэтому прикладной контракт "подавать" некуда.
V>>Опять брехня, никто манипуляции не разводил.
IB>Я их наглядно продемонстрировал. )
Ты показал умение написать слово "манипуляция" без грамматических ошибок, разве что.
Манипуляция — это когда сознательно недоговаривают, врут, играют одновременно на неполной информации и на эмоциях.
Ничего из этого Алекс не делал, разумеется, т.е. ты на него клевещешь.
Зато вы с Синклером только этим и заняты.
V>>Очевидно, Алекс имел ввиду имеющуюся функциональность линка и имеющиеся способы описания контракта к линку.
IB>Что такое "функциональность линка"
Это имеющиеся Enumerable и Queryable классы, плюс правила маппинга синтаксиса языка выражений на обычные методы или на методы расширений.
IB>и какие способы описания контракта у нас имеются?
Для рассматриваемого случая select всего 2 по 2:
— функциональная лямбда по элементу
— функциональная лямбда по элементу+индексу
— дерево выражений лямбды по элементу
— дерево выражений лямбды по элементу+индексу
Это всё.
Для случая Синклера и вовсе только первый вариант.
Т.е., прикладной контракт при вызове select протягивать банально некуда.
Этот контракт можно попытаться завернуть в саму "лямбду", т.е. манипулировать контрактом при каждом обращении к элементу.
Получается возврат на круги своя — ноль оптимизаций.
Берем другую технику — накручиваем контракт поверх самих "коллекций", мол, тогда функциональность "контракта" работает однократно.
Здесь спотыкаемся о необходимость стирания типов.
Т.е., если типы не стирать, то комбинаторный взрыв из более-менее полной библиотеки оперируемых контрактов быстро улетит в бесконечность.
А если типы стирать, то всегда будет лишний боксинг.
Собсно, подробно на всё это я уже отвечал, но ты мне почему-то отписывался совсем по другому поводу.
Ну и, технике Linq уже 13 лет, хорошо же видно, какие задачи на нём решают, а какие даже не пытаются.
Или пытались, что скорее всего, но по итогам на свет божий решили не выкатывать. ))
Т.е. Алекс, не обладая глубокими знаниями конкретно по дотнету, но обладая достаточным инженерным опытом, вполне мог сделать "реверс инжиниринг" такого положения дел, бо законы больших чисел — они ведь неумолимы.
Т.е. если ВООБЩЕ ВСЯ отрасль в течении аж 13-ти лет даже не пытается так делать, значит на это есть серьёзные причины, не?
V>>1. С неустранимыми ошибками:
IB>Пока что неустранимая ошибка только у тебя в голове.
Во-во, опять гавнецо в ответ на сугубо технический аргумент.
Слился.
V>>2. "В лоб циклами" (С) можно обращаться к двумерному массиву примерно вдвое быстрее:
V>>http://www.rsdn.org/forum/dotnet/7187427.1
V>>А если протягивать в цикле курсоры, то более чем втрое быстрее:
V>>http://www.rsdn.org/forum/dotnet/7188188.1
IB>Мало того, что это не так
Дык, развенчай!
IB>так это еще и не имеет отношения к продемонстрированному подходу.
Наоборот, я сначала посмотрел подход, потом попытался наваять что-то типа такого же, только без IL-генератора и без linq.
Там внутри просто unsafe-цикл.
4-й по счёту мой "индексер", даже который не протягивает курсоры, а просто является относительно безопасной обёрткой, показывает почти вдвое ускорение операции доступа к двумерному массиву.
IB>Даже если бы тебе удалось придумать способ, который в десять раз быстрее чем то, что предложил Антон, то это все равно бы доказало его позицию.
При условии, если бы ему удалось придумать способ безопасного обхода массива.
Ему это пока что не удалось:
int _x;
public int x => (_x++)/100;
...
from d in data select (d[-x, 0] + d[x, 0] + ...Причём, здесь просто выжимка/суть, а в реальном коде такая ситуация может возникнуть через какое-нить прикладное сочетание вызовов.
Я несколько раз говорил это словами (тут же, по-идее, собрались люди, понимающие дотнете, не?)
Пришлось даже написать в чём проблема, и внятной реакции на это до сих пор не вижу.
IB>Потому что, (вот сейчас, еще раз, внимательно) линк не про реализацию, а про то, как отделить реализацию от ее использования.
Да без проблем, если бы такое разделение не нарушало бы прикладной контракт.
V>>Он попросил это выразить через линк понятно зачем — чтобы "спорщики" сами убедились в его тормознутости.
IB>Именно. Но почему-то получилось наоборот, утверждатели в тормознутости вынуждены были придумывать, почему это не линк.
Мои хелперы показали, почему это не линк. ))
V>>А затем спросил, зачем приписали то, что сделали (а написано было, помимо решения целевой задачи, примерно в 300 раз больше кода) св-вам именно линка?
IB>А теперь вернемся к началу. Что такое "свойства именно линка"?
Давай вернёмся.
Это способ маппинга выражений языка запросов на методы объектов или на методы-расширения.
Моё мнение тут простое — сам этот способ маппинга НЕ расширяемый, поэтому прикладной контракт "подавать" некуда.