Здравствуйте, Sinix, Вы писали:
EP>>Теперь же пытаются думать задним числом, постепенно улучшая аллокатор, и добавляя костыли типа ручного вызова компактификации. EP>>Но у C#-истов осадочек-то остался, и боятся они теперь больших объектов как огня S> S>Вы хоть чуть-чуть разберитесь, перед тем как писать. А то я вам тоже докажу, что c++ как огня боится перекрёстных ссылок, а haskell — мутабельных переменных
Аргументы? Хоть какие-нибудь?
Я сказал C#-исты, а не C#, и как минимум один такой(а то и несколько) тут есть — топик-то вообще начинался с векторо-фобии
Или например вот эти пользователи тоже не разобрались, наговаривают наверное?
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Abyx, Вы писали:
E>>>Суть проста. "правильное" форматирование кода нужно тока придуркам. A>>я сказал "однообразное", а не "правильное".
E>А на воре-то и шапочка того-с...
я обычно форматирую код так:
int f()
{
return (1 + 2) * 3;
}
но при этом я спокойно могу работать с кодом типа
int
f ( ) {
return ( 1+2 )*3;
}
а вот если бы разные стили были перемешаны, это уже вызывает раздражение.
и далее по ветке. Сдуру всё сломать можно, при начальном знании матчасти (обычно Рихтера хватает за глаза) — проблем не возникает.
EP>Я сказал C#-исты, а не C#, и как минимум один такой(а то и несколько) тут есть — топик-то вообще начинался с векторо-фобии
Второго ещё поискать придётся
EP>Или например вот эти пользователи тоже не разобрались, наговаривают наверное?
Почему наговаривают? Частично исправлено в 4.0, полностью — в 4.5. Другое дело, что грабли разбиралисьнеоднократно. Если человек игнорирует документацию и пускает в продакшн код, который загаживает 2 поколение тонной мусора, а затем падает с OOM — кто ему виноват?
Здравствуйте, Abyx, Вы писали:
A>а вот если бы разные стили были перемешаны, это уже вызывает раздражение.
Это просто вопрос привычки. А раздражение из-за всякой фигни -- это к доктору надо просто обратиться, а ещё лучше к психологу...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Abyx, Вы писали:
A>нет, переименование API происходит гораздо реже чем переименование реализации.
set_next не API, а private method, еще не хватало его в public показывать.
PD>>Почему же ты тогда отстаиваешь свое решение с лишним действием ? Да, для списка — мелочь, но вопрос же в принципе. И речь идет ведь о коде неопределенного назначения, это тебе на обработка нажатия кнопки мыши , за которой следует чтение 10Мб файла, а поэтому можно сказать, что плевать мне на эффективность самого обработчика WM_LBUTTONDOWN. А вдруг где-то именно это лишнее присваивание вызовет потерю производительности ? И что тогда ? Копаться в этом slice, понять, что там лишнее действие, переделать все (его же просто так не уберешь там) ? Сколько времени уйдет на то, чтобы это место обнаружить ? Сколько времени уйдет, чтобы это исправить (то есть переписать в том виде, который я сделал) ? За это время я тебе все next в m_next в этом классе вручную переименую
A>компилятор уберет это лишнее присваивание.
А это еще большой вопрос. Одни уберет, другой нет. И потом — мы же об общем принципе говорим, а не об отдельном присваивании.
A>да, я бы написал A>
A>struct Foo {
A> void bar() { m_b = -m_b; }
A>private:
A> int m_b;
A>};
A>
A>если у Foo есть такая операция bar.
Ну да. Еще заведи bar1 с операцией !, потом bar2 с операцией ~, потом всякие (+-*/)=, то-то код понятнее станет...
А если Foo никакого нет ? А есть просто
int x = 10;
//...
x = — x;
И здесь заведешь
void neg(int&x)
{
x = -x;
}
Замечательный стиль получится
PD>>1. Ты изучаешь класс, коду которого доверяешь. В этом случае тебе вообще незачем смотреть на реализацию. Сигнатуры Reverse достаточно (плюс док, если надо) PD>>2. Ты изучаешь класс, код которого хочешь понять (неважно для чего). В этом случае тебе придется смотреть весь код. PD>>Если встретится полиморфизм, то будет гибрид. Придется в отношении полиморфных функций использовать (1), поскольку и впрямь исследовать нельзя. Так сказать, констатируем факт — здесь у нас неизвестно что, но с указанной сигнатурой и описанием действий, остается надеяться, что оно работает правильно. Принудительно заставляем доверять, так сказать. В отношении остального — либо (1) либо (2) в зависимости от того, что имеет место. A>третье. я доверяю коду класса, и я хочу понять как работает код некоторого метода. A>например есть std::forward_list. я ему доверяю, он работает. но мне интересно как у него сделана reverse(), и я заглядываю внутрь ее реализации в VC++ A>и вижу что там используются empty, begin, before_begin, _Before_end — что они делают понятно из названия, реализацию смотреть не надо A>еще там есть _Splice_same_after, смотрим ее сигнатуру — void _Splice_same_after(const_iterator _Where, _Myt& _Right, const_iterator _First, const_iterator _Last) A>ок, значит она вставляет [first, last) после where, реализацию смотреть не надо
A>с этим знанием возвращаемся к reverse() и теперь понятно как она работает — берет элементы из начала списка и перемещает в конец.
A>...но тут возникает вопрос, а откуда _Before_end берет конец? смотрим ее реализацию, а там цикл. ...!@№? получается в VC++ reverse сделана со сложностью O(2N)
Хм... Ты же сам себе противоречишь, не замечаешь ? В _Before_end ты почему-то заглянул, а вот _Splice_same_after — реализацию, говоришь, смотреть не надо. А почему ты уверен, что там все хорошо ? Мало ли что она вставляет, ты же не знаешь, как она это делает ? Доверяешь ? Тогда почему ей да, а reverse нет ? reverse-то, оказывается , O(2N), то есть не очень хорошо сделали, ну а вдруг они и вставку не очень хорошо сделали, там ведь если не O(1), а O(2), так то же самое будет...
Да, может, для списка просто не найдется способа испортить эту вставку , ну а, представь себе, что здесь не список, а дерево ? Там вставить можно по-разному, и эффективно, и не очень, и пока не разберешься, что там за дерево внутри, ничего не поймешь.
Вот тебе другой пример
void process(AnyClass& p)
{
for(int i = 0; i < p.length; i++)
doSomething(p[i]);
}
Смотрим doSomething — O(1). Какова зависимость process в целом от p.length ? Можно ответить, не глядя в AnyClass::operator[] ?
И что? Как это показывает что я в чём-то не разобрался?
S>>>Вы хоть чуть-чуть разберитесь, перед тем как писать
Конкретные аргументы будут? "Вот в этом ты не прав, потому что ... и ..."
EP>>Я сказал C#-исты, а не C#, и как минимум один такой(а то и несколько) тут есть — топик-то вообще начинался с векторо-фобии S>Второго ещё поискать придётся
Вот, почему бы было сразу не сказать, что векторо-фобия это что-то личное Ikemefula, и все остальные с ним не согласны? Типа "мы сишарписты ребята плечисты, мы не боимся списков мясистых"
EP>>Или например вот эти пользователи тоже не разобрались, наговаривают наверное? S>Почему наговаривают? Частично исправлено в 4.0, полностью — в 4.5. Другое дело, что грабли разбиралисьнеоднократно.
Ну то есть они правы в том что боятся LOH?
S>Если человек игнорирует документацию и пускает в продакшн код, который загаживает 2 поколение тонной мусора, а затем падает с OOM — кто ему виноват?
Речь идёт про загаживание LOH большими объектами, с которым дела обстояли плохо вплоть до VS2008. Значит ты советуешь его не загаживать, и читать документацию, ну ок.
Но тогда объясни свой наезд:
EP>>Но у C#-истов осадочек-то остался, и боятся они теперь больших объектов как огня
S>
S>Вы хоть чуть-чуть разберитесь, перед тем как писать.
Здравствуйте, Pavel Dvorkin, Вы писали:
A>>нет, переименование API происходит гораздо реже чем переименование реализации. PD>set_next не API, а private method, еще не хватало его в public показывать.
set_successor вполне может быть публичным интерфейсом итератора, что позволяет делать обобщённые алгоритмы отвязанные от конкретной реализации списка.
Например Александр Степанов вводит LinkedIterator (раз, два), который позволяет реализовать разные алгоритмы на списках.
Здравствуйте, Pavel Dvorkin, Вы писали:
A>>нет, переименование API происходит гораздо реже чем переименование реализации. PD>set_next не API, а private method, еще не хватало его в public показывать.
нет, это API ListElement.
A>>компилятор уберет это лишнее присваивание. PD>А это еще большой вопрос. Одни уберет, другой нет. И потом — мы же об общем принципе говорим, а не об отдельном присваивании.
общий принцип такой что компилятор всегда инлайнит небольшие функции и выкидывает мертвый код.
PD>А если Foo никакого нет ? А есть просто PD>int x = 10; PD>//... PD>x = — x;
PD>И здесь заведешь PD>void neg(int&x) PD>{ PD> x = -x; PD>}
PD>Замечательный стиль получится
такое тоже возможно. только это будет выглядеть примерно так
typedef int velocity;
void reverse(velocity& v) { v = -v; }
velocity v;
...
if (somethingHappen) reverse(v);
суть в том, что код надо сводить к абстрактным сущностям и операциям над ними.
у операций должны быть внятные названия, и операции должны прятать реализацию сущностей
PD>>>1. Ты изучаешь класс, коду которого доверяешь. В этом случае тебе вообще незачем смотреть на реализацию. Сигнатуры Reverse достаточно (плюс док, если надо) PD>>>2. Ты изучаешь класс, код которого хочешь понять (неважно для чего). В этом случае тебе придется смотреть весь код. PD>>>Если встретится полиморфизм, то будет гибрид. Придется в отношении полиморфных функций использовать (1), поскольку и впрямь исследовать нельзя. Так сказать, констатируем факт — здесь у нас неизвестно что, но с указанной сигнатурой и описанием действий, остается надеяться, что оно работает правильно. Принудительно заставляем доверять, так сказать. В отношении остального — либо (1) либо (2) в зависимости от того, что имеет место. A>>третье. я доверяю коду класса, и я хочу понять как работает код некоторого метода. A>>например есть std::forward_list. я ему доверяю, он работает. но мне интересно как у него сделана reverse(), и я заглядываю внутрь ее реализации в VC++ A>>и вижу что там используются empty, begin, before_begin, _Before_end — что они делают понятно из названия, реализацию смотреть не надо A>>еще там есть _Splice_same_after, смотрим ее сигнатуру — void _Splice_same_after(const_iterator _Where, _Myt& _Right, const_iterator _First, const_iterator _Last) A>>ок, значит она вставляет [first, last) после where, реализацию смотреть не надо
A>>с этим знанием возвращаемся к reverse() и теперь понятно как она работает — берет элементы из начала списка и перемещает в конец.
A>>...но тут возникает вопрос, а откуда _Before_end берет конец? смотрим ее реализацию, а там цикл. ...!@№? получается в VC++ reverse сделана со сложностью O(2N)
PD>Хм... Ты же сам себе противоречишь, не замечаешь ? В _Before_end ты почему-то заглянул, а вот _Splice_same_after — реализацию, говоришь, смотреть не надо.
в _Before_end я заглянул потом, после того как разобрался с тем как работает reverse. если бы меня не заинтересовала сложность, я бы не стал в нее заглядывать.
PD>Вот тебе другой пример PD>
PD>void process(AnyClass& p)
PD>{
PD>for(int i = 0; i < p.length; i++)
PD> doSomething(p[i]);
PD>}
PD>
PD>Смотрим doSomething — O(1). Какова зависимость process в целом от p.length ? Можно ответить, не глядя в AnyClass::operator[] ?
нельзя. чтобы оценить сложность функции надо смотреть сложности всех ее зависимостей.
однако мы вроде говорим о понимании того как функция работает, а не об оценке ее сложности.
к слову, length может быть property, и у нее тоже может быть реализация с O(N)
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>И что? Как это показывает что я в чём-то не разобрался? EP>Конкретные аргументы будут? "Вот в этом ты не прав, потому что ... и ..."
Спекуляция на тему как всё это развивалось:
В .NET есть два типа кучи — для маленьких(Small Object Heap) и больших объектов(Large Object Heap).
Во время сборки мусора SOH компактифицируется, поэтому политика аллокации может быть простейшей, например просто добавление в конец, пока не упрёмся, а потом вызываем GC.
Большие объекты, передвигать накладно, поэтому эти ребята решили добавить LOH, в которой нет компактификации. Но, политику аллокации координатно не пересмотрели.
LOH существовала с самого начала, рекомендации не бить себе молотком по пальцу тоже озвучивались неоднократно. Перечитайте статью, там в картинках расписано почему и как мы получаем фрагментацию кучи. На пальцах (x = мелкие массивы, o — большие, . — свободно):
1. ooo................ // аллоцируем большой массив 1
2. ooox............... // аллоцируем мелкий массив
3. ...xoooo........... // аллоцируем большой массив 2, массив 1 сожран GC, но места под массив 2 только в конце списка ранее аллоцированных - закидываем туда
4. ...xoooox.......... // Проблема вот тут: слишком "умный" аллокатор решает не трогать большие свободные куски и аллоцирует мелкий массив в конец
5. ...x....xoooooo.... // повторяем
6. ...x....xoooooox... // и так до посинения
Решается, замечу, элементарно — использованием x64, аллокацией долгоживущих массивов заранее, или уменьшением количества лишних аллокаций. В большинстве реальных случаев оно работает само — аллокатор будет переиспользовать свободное пространство. По крайней мере, я за всё время работы с таким направленным отстрелом ноги не сталкивался.
Но да, поскольку политика дотнета во многом описывается как "документация? кто её читает?" — добавили костыли даже на этот случай. Как до них руки дошли.
EP>Вот, почему бы было сразу не сказать, что векторо-фобия это что-то личное Ikemefula, и все остальные с ним не согласны? Типа "мы сишарписты ребята плечисты, мы не боимся списков мясистых"
А нафига? Есть сомнения — вэлкам в профильный раздел. Отслеживать тонны трэша и личных наездов только чтобы доказать что в интернете снова кто-то неправ — дело малоприятное. Вы ещё политику и жизнь по соответствующим веткам попробуйте изучать
также, вместо "ListElement * newBegin = NULL; // new list" лучше сделать "List newList;"
и вместо "begin = newBegin; // replace list elements" лучше сделать "*this = newList;"
Здравствуйте, Sinix, Вы писали:
S>Перечитайте статью, там в картинках расписано почему и как мы получаем фрагментацию кучи. На пальцах (x = мелкие массивы, o — большие, . — свободно): S>[...] S>Как, очень актуальный сценарий?
Я читал статью, и понял что происходит — вроде же очевидно по моему сообщению
Я даже несколько тестов привёл, которые показывают что такой сценарий спокойно разгуливается нормальным аллокатором — например в C++ VS2005, и в C# VS2012 — эти примеры ты пропустил?
S>Решается, замечу, элементарно — использованием x64,
Да всем известно про x64. Во всём топике идёт обсуждение x32
S>аллокацией долгоживущих массивов заранее, или уменьшением количества лишних аллокаций. В большинстве реальных случаев оно работает само — аллокатор будет переиспользовать свободное пространство. По крайней мере, я за всё время работы с таким направленным отстрелом ноги не сталкивался.
Естественно есть варианты обхода такого косяка аллокатора, я даже в конце сообщения один из вариантов показал:
EP>Кстати, по поводу боязни растущих векторов — если заменить List<byte[]>, на List<byte>, и соответственно добавлять в него всё что раньше было в блоках — байт за байтом — то даже на VS2005 получается достичь "фантастических" 511MiB, потому что будут не тысячи LO, а всего два
Но ты также его проигнорировал.
EP>>Вот, почему бы было сразу не сказать, что векторо-фобия это что-то личное Ikemefula, и все остальные с ним не согласны? Типа "мы сишарписты ребята плечисты, мы не боимся списков мясистых" S>А нафига? Есть сомнения — вэлкам в профильный раздел. Отслеживать тонны трэша и личных наездов только чтобы доказать что в интернете снова кто-то неправ — дело малоприятное. Вы ещё политику и жизнь по соответствующим веткам попробуйте изучать
Да зачем отслеживать-то. Erop спрашивал в чём же дело, откуда у векторо-фобии ноги растут, причём в форме намного более корректной чем у оппонентов. Тут уже много C#-истов выступало и не один не сказал что векторо-фобии ни у кого кроме Ikemefula нет.
P.S. Я правильно понимаю, что вот это:
Вы хоть чуть-чуть разберитесь, перед тем как писать.
ты написал сгоряча, и никаких аргументов в поддержку своих слов привести не можешь?
In .NET 4.5, we made two improvements to the large object heap. First, we significantly improved the way the runtime manages the free list, thereby making more effective use of fragments. Now the memory allocator will revisit the memory fragments that earlier allocation couldn’t use. Second, when in server GC mode, the runtime balances LOH allocations between each heap. Prior to .NET 4.5, we only balanced the SOH. We’ve observed substantial improvements in some of our LOH allocation benchmarks as a result of both changes.
Т.е. в <4.5 даже если свободные блоки были — аллокатор их более не рассматривал, если он уже был однажды отвергнут. Конечно это сильно упрощенно. И по моему где-то был более подробный пост.
Здравствуйте, fddima, Вы писали:
F> Т.е. в <4.5 даже если свободные блоки были — аллокатор их более не рассматривал, если он уже был однажды отвергнут. Конечно это сильно упрощенно. И по моему где-то был более подробный пост.
Ну так на пальцах же Там тонна нюансов всплывёт если разбираться.
Здравствуйте, Erop, Вы писали:
E>Комментарии -- это лог намерений разработчика, а код -- то, что получилось из этих намерений.
Комментарии это непойми что, которое теоретически могло соответсвовать каким то намерениями.
А вот код это уже намерения в чистом виде.
E>А у тебя имена функций вместо комментариев используются, с той же степенью обязательности отсутствия вранья
Имена функций нужна для человека, в них и надо вкладывать смысл. Если ты пишешь c = (a + b)/2 и рядом камент "//вместо медианы берем среднее арифметическое", то тебя надо выпилить из конторы как можно раньше.
In .NET 4.5, we made two improvements to the large object heap. First, we significantly improved the way the runtime manages the free list, thereby making more effective use of fragments. Now the memory allocator will revisit the memory fragments that earlier allocation couldn’t use. Second, when in server GC mode, the runtime balances LOH allocations between each heap. Prior to .NET 4.5, we only balanced the SOH. We’ve observed substantial improvements in some of our LOH allocation benchmarks as a result of both changes.
F> Т.е. в <4.5 даже если свободные блоки были — аллокатор их более не рассматривал, если он уже был однажды отвергнут. Конечно это сильно упрощенно. И по моему где-то был более подробный пост.
A>также, вместо "ListElement * newBegin = NULL; // new list" лучше сделать "List newList;" A>и вместо "begin = newBegin; // replace list elements" лучше сделать "*this = newList;"
Ладно, давай заканчивать. Точки несоприкосновения ясны, тут мы не договоримся. Слишком разные в этом плане подходы.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Да зачем отслеживать-то. Erop спрашивал в чём же дело, откуда у векторо-фобии ноги растут, причём в форме намного более корректной чем у оппонентов. Тут уже много C#-истов выступало и не один не сказал что векторо-фобии ни у кого кроме Ikemefula нет.
А где ты фобию углядел ? Я привел конкретный сценарий и объяснил, что он повалит приложение в С++ еще быстрее, чем в дотнете. Где фобия ?
Здравствуйте, Ikemefula, Вы писали:
I>Имена функций нужна для человека, в них и надо вкладывать смысл. Если ты пишешь c = (a + b)/2 и рядом камент "//вместо медианы берем среднее арифметическое", то тебя надо выпилить из конторы как можно раньше.
А мне бы вот, например, могло бы быть интересно, что рассматривались именно эти два варианта...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Вот, почему бы было сразу не сказать, что векторо-фобия это что-то личное Ikemefula, и все остальные с ним не согласны? Типа "мы сишарписты ребята плечисты, мы не боимся списков мясистых"
EP>>>Или например вот эти пользователи тоже не разобрались, наговаривают наверное? S>>Почему наговаривают? Частично исправлено в 4.0, полностью — в 4.5. Другое дело, что грабли разбиралисьнеоднократно.
EP>Ну то есть они правы в том что боятся LOH?
С таким подходом смело можно сказать, что в С++ боятся
Эдак выходит что С++ просто рассадник фобий, ибо на каждый пример из списка можно найти вагоны воплей "... не работает ! Всё пропало !!! просрали полимеры !!!!111расрас"
И вот что характерно — на кривые руки жалуются только сиплюсники. К чему бы это ?
