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

E>>Это можно интерпретировать так, что обычно алгоритмы, где таки нужно, программируют на более иных языках?..

I>Где таки нужно — нужно рассматривать конкретные случаи под профайлером. Если профайлер покажет, что узкое место это обращение по случайному индексу, и средствами дотнете не удастся обеспечить должное быстродействие, то будет использован С а может и С++

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

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

НС>>>Разумеется, абсолютно универсального рецепта нет.
E>>Ну вот я про то же самое, как бы...

I>Это ты забираешь слова про VirtualAlloc ?
Это я понимаю, что рецепта нет в сишарпе...
В плюсах под win32 аллокаторы никогда такими убогими не были...

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

НС>Когда ты задаешь вопросы, кому то отвечая, по умолчанию эти вопросы относятся к тому кому ты отвечаешь.
Это твоё мнение, но оно не обязательно разделяется всеми участниками форума.
Во всяком случае ты, например, зачем-то стал отвечать на реплики Евгения и мои, опубликованные в ответах на сообщения I...

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

НС>Т.е. ты не знаешь для чего?
Я знаю, что ты не поймёшь меня, потому, что тебе хочется не понять...

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

НС>Нет, ты про то что "С#-разрабы в массе своей не смогли разобраться в причинах проблемы и просто перестали использовать большие вектороподобные коллекции".

Ну так так и есть. Я только не понимаю, поему ты достраиваешь это утверждение фразой "потому, что они дураки", а не фразой, "потому, что им это не надо"?

Здравствуйте, Ikemefula, Вы писали:
I>То есть, даже рассуждения о прекрасном не помогают ?
Рассуждения без понимания не понимают никогда.

I>Вот тогда можно подбирать конкретную оптимизацию. И вот именно random-access как правило редкий случай, почти что экзотический. Там где он становится узким местом, почти наверняка проблема не в коллеции, а в платформе, если алгоритм верный. Чем тебе здесь дека поможет — совершенно не ясно.

Угу. Понимаю. Ну да, сервер медленный, нужен апгрейд, кто ы сомневался...

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

I>>>Это может сказать только профайлер.
EP>>Давай ты не будешь разводить демагогию на тему node-based tree vs indexed chunks, необходимость профайлеров и всё-такие, ок?
I>Демагогия это у тебя, т.к. общие рассуждения о прекрасном при отрицании необходимости профайлера.

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

I>В реальном приложении обращения к коллекции не все одинаковые, а это разные операции у которых, внезапно, разная частота использования. И вот этот расклад, внезапно, показывает профайлер !

Однажды шеф дал мне кусок кода в ~250 строк из стороннего проекта, мол тормозит нужно оптимизировать.
В том коде использовалась библиотека и среда которая у меня не была установлена+настроена. Используя только документацию по этой библиотеке и текстовый редактор (omg, без компилятора! ) я улучшил производительность в 10x на конкретных данных (а в общем случае и того больше) — при этом код собрался и заработал с первого раза, без ошибок и предупреждений.
А ты говоришь profiler

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

НС>>Когда ты задаешь вопросы, кому то отвечая, по умолчанию эти вопросы относятся к тому кому ты отвечаешь.
E>Это твоё мнение, но оно не обязательно разделяется всеми участниками форума.

А, ну конечно — твоя версия что никто не знает на них ответов конечно же правдоподобнее А главное — как удобно то.

E>Во всяком случае ты, например, зачем-то стал отвечать на реплики Евгения и мои, опубликованные в ответах на сообщения I...

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

НС>>Перешел на личности — слил.
E>В смысле?

В прямом. Начал в очередной раз обсуждать мою личность — слил.

E> Это ты заметил, наконец, что вместо шарповского листа давно уже меня обсуждаешь?

Это ты что то лишнее заметил — я обсуждаю не тебя, а твои высказывания.

E>Или о каком переходе на личности речь? Я не обещал разъяснять всем свои тезисы до полного их понимания всеми, и не буду это делать.

Ну так и скажи — продемонстрировать логическую цепочку не можешь.

НС>>Т.е. ты не знаешь для чего?
E>Я знаю, что ты не поймёшь меня, потому, что тебе хочется не понять...



E>Если тебе нужна пример задачи с выборкой по индексу, то ради бога. У тебя есть два сигнала. Один используется во всех запросах, и он записан с шагом в t микросекунд в буфер, вернее не он, а его интеграл, а второй меняется от запроса к запросу и является перечислением интервалов, ну там с такого времени по такое + с такого по такое и -- единица, а остальное время -- ноль т. д.
E>Надо быстро считать свёртки...

Если надо быстро считать, то тут точно на С++ писать придется. Но не из-за памяти, а потому что CLR до сих пор не имеет интринсиков для векторных расширений.

НС>>Нет, ты про то что "С#-разрабы в массе своей не смогли разобраться в причинах проблемы и просто перестали использовать большие вектороподобные коллекции".

E>Ну так так и есть.

Нет, так не есть.

E> Я только не понимаю, поему ты достраиваешь это утверждение фразой "потому, что они дураки", а не фразой, "потому, что им это не надо"?

У тебя какие то помехи в канале, я твою фразу не достраивал, я ее привел as is, путем копирования через буфер обмена.

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

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

Сорри, я не смог распарсить что ты написал. О каких издержках речь?

E> Кстати, они таки есть?

Я не очень тебя понял, но в GC, покуда мы в LOH не попадаем, накладные расходы на аллокацию — единицы тактов процессора.

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

1) Не стоит путать меня с Икемефулой. Я нигде не утверждал что на задаче реверса списка без какого либо другого кода будут проблемы с фрагментацией спейса.
2) Что же касается фрагментации в целом, то я лично тебе писал, что проблемы с фрагментацией на практике наступают даже при размере непрерывных кусков в единицы десятков мегабайт. Но на примитивных тестах это не так то просто воспроизвести, потому что процесс отчасти случайный и вылазит обычно в сложных и многоплановых приложениях, работающих не в батч-режиме, а откликаясь на внешние возбуждения. И решаются они, кстати, чаще вовсе не хитрыми структурами данных или аллокаторами памяти, а переделкой алгоритмов на такие, которые способны работать без индексного доступа.
И вот в таком разрезе таки вылазит нагляднейшая разница между вариантом со списком и вариантом с IEnumerable. Потому что этот IEnumerable вполне может тянуть данные напрямую из сети или с диска (а если добавить его зеркало, IObservable, то еще и лить напрямую в сеть/на диск), и потребление памяти сократится до игрушечных величин.

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

EP>В том коде использовалась библиотека и среда которая у меня не была установлена+настроена. Используя только документацию по этой библиотеке и текстовый редактор (omg, без компилятора! ) я улучшил производительность в 10x на конкретных данных (а в общем случае и того больше) — при этом код собрался и заработал с первого раза, без ошибок и предупреждений.

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

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

EP>>В том коде использовалась библиотека и среда которая у меня не была установлена+настроена. Используя только документацию по этой библиотеке и текстовый редактор (omg, без компилятора! ) я улучшил производительность в 10x на конкретных данных (а в общем случае и того больше) — при этом код собрался и заработал с первого раза, без ошибок и предупреждений.
НС>Вопрос только в том, сколько бы времени заняло то же самое без профайлера,

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

НС>и насколько меньше пришлось бы уродовать кода в угоду оптимизации.

Там было ~20 простых правок, как раз на правильное обращение с памятью и структурами данных.

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

EP>Там не использовался профайлер.

Ну так в том и вопрос — что бы было если бы использовался.

НС>>и насколько меньше пришлось бы уродовать кода в угоду оптимизации.
EP>Там было ~20 простых правок, как раз на правильное обращение с памятью и структурами данных.

Ну, если ты смог найти в коде явный косят это здорово, вот только далеко не всегда это можно сделать глазами за приличное время.

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

EP>>Там не использовался профайлер.
НС>Ну так в том и вопрос — что бы было если бы использовался.

Я уверен что в этом конкретном случае было бы дольше — так как всё было на поверхности.

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

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

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

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

Очевидно — есть и я даже написал, какие именно.

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

Ты похоже отказываешься понять, что "память закончится" это вещь сильно относительная.

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

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

I>>Не всех операций, а только критичных, что покажет __профайлер__. Вообще оптимизируются исключительно __узкие__ места, а не все подряд.

E>а пессимизируются, зато все? Или как?

Или как разумеется.

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

Если тормоза размазать ровным слоем, то профайлер покажет, что тормоза размазаны ровным слоем.

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

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

А мой опыт оптимизации реального кода говорит, что 90% устраняемых при этом проблем вовсе не из-за неправильно выбранных структур данных.

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

E>А как ты думаешь, тормоза из-за неадекватного выбора коллекции, возникли 0 лет назад, и только в 2012 тебе их удалось заметить профайлером, или сначала их не было?

Я уже ответил на этот вопрос. 0 лет назад это сильно.

Тормоза они не с потолка берутся. Если время работы устраивает, то совершенно без разницы, насклько медленнее работа с коллекцией относительно идеального во всех отношениях варианта.

E>А то может у вас там всё так же неадекватно было запрограммировано, и вы потом профайлером 10 лет выпрямляли изначально кривую архитектуру?..

А может у тебя в ДНК чтото особенное ?

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

НС>Сорри, я не смог распарсить что ты написал.
Бывает...

НС>О каких издержках речь?
У односвязного списка есть естественный оверхед -- это один указатель на элемент.
Если мы храним в списке данные размером байт в 100, то это фигня, а если мы таки имеем односвязный список букв, то в случае без выравнивания, получим, что на букву (один или два байта) нам надо 4 байта оверхеда, в 32-битном случае, а с выравниванием 6-7 байт...

Но, у аллокаторов иногда бывают ещё и доп издержки, их ещё внутренней фрагментацией иногда называют. Ну, там кто-то хранит размеры блоков, кто-то выравнивает границы блоков на 16 байт, кто-то ещё что-то такое делает.

E>> Кстати, они таки есть?
Ну я е знаю, в дотнете как аллокатор работает. Там есть оверхед на аллокцируемый блок по памяти какой-то? И если есть, то каков он?

НС>Я не очень тебя понял, но в GC, покуда мы в LOH не попадаем, накладные расходы на аллокацию — единицы тактов процессора.
Тебя не смутило, что я оверхед в мегабайтах исчисляю? Я про память, если ты не заметил...

НС>1) Не стоит путать меня с Икемефулой. Я нигде не утверждал что на задаче реверса списка без какого либо другого кода будут проблемы с фрагментацией спейса.
Если ты тоже считаешь стартовое сообщение этой темы излишне паникёрским и неадекватно преувеличивающим проблемы, то у нас с тобой тогда по этому вопросу разногласий нет...

НС>2) а переделкой алгоритмов на такие, которые способны работать без индексного доступа.
Да понял я это, не волнуйся. Я не только понял, но даже кратко сформулировал и повторил... почему это вызвало такой протест я не понимаю. Все шарписты, которые тут отметились, говорят ровно тоже самое, но не согласны при этом с моим утверждением.

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

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

Я конечно понимаю, что в каком-то приближении под WIN32, если у нас вообще есть своп-файл, то память и диск -- это примерно одно и то же. Но таки не совсем...

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

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

E>Понимаешь, некоторые люди тут, ещё на этапе проектирования и выбора алгоритмов и структур данных понимают временную сложность получающихся алгоритмов...
E>А некоторые по 10 лет с профайлером ловят эти элементарные в общем-то ошибки дизайна... Ну у всех свой хлеб и свой подход.
E>Самое же удивительное в этих "первых" и "вторых", что, судя по моему опыту, первым никогда не влом разбраться и поучится, зато вторые всегда всё знают, и всем объясняют, что попытки использовать голову вместо автоматических инструментов -- это колхоз...

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

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

E>В плюсах под win32 аллокаторы никогда такими убогими не были...

Были даже еще более убогими 10 лет назад С++ за С++ не считался, если с теперешним сравить.

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

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

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

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

НС>А, ну конечно — твоя версия что никто не знает на них ответов конечно же правдоподобнее А главное — как удобно то.

Не "никто", а люди, отметившиеся в теме. Например такие эксперты, как ты...

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

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

НС>Ну так и скажи — продемонстрировать логическую цепочку не можешь.
Тебе не возьмусь. Так как ты демонстрируешь желание не понимать.

НС>Если надо быстро считать, то тут точно на С++ писать придется. Но не из-за памяти, а потому что CLR до сих пор не имеет интринсиков для векторных расширений.

У-у-у, а зачем тут векторные расширения?..
Хотя можно, конечно, но не факт, что будет быстрее, кстати

НС>Нет, так не есть.
Доказательства?..

НС>У тебя какие то помехи в канале, я твою фразу не достраивал, я ее привел as is, путем копирования через буфер обмена.

Ну ты ещё раз подтвердил, что не поймёшь меня, потому, что хочешь не понять... И в чём профит?

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

I>Ты похоже отказываешься понять, что "память закончится" это вещь сильно относительная.

Ну это у кого как... У некоторых есть цели в ТЗ, что программа должна помещаться в столько-то рам даже без свопа и привет

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

НС>А мой опыт оптимизации реального кода говорит, что 90% устраняемых при этом проблем вовсе не из-за неправильно выбранных структур данных.

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