Здравствуйте, gandjustas, Вы писали:
G>>>Стандартные аллокаторы в С++ требуют прохода по списку свободных блоков памяти при выделении\освобождении, эта операция имеет алгоритмическую сложность O(n). При интенсивных операциях выделения\освобождения работает очеень медленно. CC>>Ты пожалуйста ссылку дай на стандарт С++, где написано что именно так работает "стандартный аллокатор С++". G>Стандарт C++ не определяет реализацию выделения памяти. Во всех известных мне реализациях С++ работает именно так.
Ну так какого ты ляда утверждаешь что "Стандартные аллокаторы в С++ требуют прохода блаблабла"?
У С++ НЕТ стандартного алгоритма аллокации. Есть интерфейс, который аллокатор должен реализовывать. И есть дефолтный из поставки CRT к компилятору. Качество которого исключительно на совести разработчика CRT.
В некоторых CRT для С++ аллокатор вообще зачастую сводится к вызову системного аллокатора. Который к С++ вообще никакого отношения не имеет.
Все остальное — в руках программиста.
Я могу встроить тот же Hoard в CRT и он тогда будет являться стандартным аллокатором.
G>>>Не разводи демагогию, давай факты. CC>>Симметрично! G>Я уже приводил код, где GC работает быстрее алокатора С++.
Аллокатора операционной системы, ты хотел сказать?
CRT вижуалки тупо зовёт HeapAlloc.
Я уже приводил тебе ответный пример, где GC не был быстрее.
Напомню:
твой код:
VS 2003 + ICC 11, C++ : 188 — CRT реализует аллокацию через HeapAlloc
VS 2008, C# : 117
мой кастомный наколенный proof-of-concept аллокатор:
VS 2003 + ICC 11, C++ : 0 или 16 (разрешения GetTickCount очевидно не хватает)
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, gandjustas, Вы писали:
G>>>>Стандартные аллокаторы в С++ требуют прохода по списку свободных блоков памяти при выделении\освобождении, эта операция имеет алгоритмическую сложность O(n). При интенсивных операциях выделения\освобождения работает очеень медленно. CC>>>Ты пожалуйста ссылку дай на стандарт С++, где написано что именно так работает "стандартный аллокатор С++". G>>Стандарт C++ не определяет реализацию выделения памяти. Во всех известных мне реализациях С++ работает именно так. CC>Ну так какого ты ляда утверждаешь что "Стандартные аллокаторы в С++ требуют прохода блаблабла"?
Еще раз: все известные мне реализации так работают.
CC>Я могу встроить тот же Hoard в CRT и он тогда будет являться стандартным аллокатором.
Не можешь. Твой CRT ниекто не будет распространять.
G>>>>Не разводи демагогию, давай факты. CC>>>Симметрично! G>>Я уже приводил код, где GC работает быстрее алокатора С++. CC>Аллокатора операционной системы, ты хотел сказать? CC>CRT вижуалки тупо зовёт HeapAlloc.
И что? У него внутри такой же хип, на таком же С++.
CC>Я уже приводил тебе ответный пример, где GC не был быстрее. CC>Напомню: CC>
Здравствуйте, gandjustas, Вы писали:
CC>>Ну так какого ты ляда утверждаешь что "Стандартные аллокаторы в С++ требуют прохода блаблабла"? G>Еще раз: все известные мне реализации так работают.
Мы о С++ либо об известных тебе реализациях?
CC>>Я могу встроить тот же Hoard в CRT и он тогда будет являться стандартным аллокатором. G>Не можешь. Твой CRT ниекто не будет распространять.
CC>>CRT вижуалки тупо зовёт HeapAlloc. G>И что? У него внутри такой же хип, на таком же С++.
А в С++ на GCC под Linux будет такой же хип?
CC>>Я уже приводил тебе ответный пример, где GC не был быстрее. CC>>Напомню: CC>>[q] CC>>твой код: CC>>VS 2003 + ICC 11, C++ : 188 — CRT реализует аллокацию через HeapAlloc CC>>VS 2008, C# : 117
G>Твой наколенный непотокобезопасен.
Жжошь!
Можно узнать с какого перепугу ты так решил?
Там Per-thread pool с lock-free deferred алгоритмом на случай освобождения памяти из не-родного-потока.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, gandjustas, Вы писали:
CC>>>Ну так какого ты ляда утверждаешь что "Стандартные аллокаторы в С++ требуют прохода блаблабла"? G>>Еще раз: все известные мне реализации так работают. CC>Мы о С++ либо об известных тебе реализациях?
Думаешь я мало компиляторов видел?
Приведи парочку компиляторов С++ промышленного качества, в которых аллокация по кардинально другом алгоритму делается.
CC>>>CRT вижуалки тупо зовёт HeapAlloc. G>>И что? У него внутри такой же хип, на таком же С++. CC>А в С++ на GCC под Linux будет такой же хип?
Похожий.
CC>>>Я уже приводил тебе ответный пример, где GC не был быстрее. CC>>>Напомню: CC>>>[q] CC>>>твой код: CC>>>VS 2003 + ICC 11, C++ : 188 — CRT реализует аллокацию через HeapAlloc CC>>>VS 2008, C# : 117
G>>Твой наколенный непотокобезопасен. CC> CC>Жжошь! CC>Можно узнать с какого перепугу ты так решил? CC>Там Per-thread pool с lock-free deferred алгоритмом на случай освобождения памяти из не-родного-потока.
Значит уже забыл. Пулы интересуют еще меньше, так как они требуют подгонки размеров блоков и пулов.
Как аллокатор общего назначения использовать смысла нету.
Здравствуйте, CreatorCray, Вы писали:
G>>Твой наколенный непотокобезопасен. CC> CC>Жжошь! CC>Можно узнать с какого перепугу ты так решил?
ну как же, ведь всё что быстрее гц ето заведомо непотокобезопасно и вообще UB
кстати результат гц просто удручает, всего в полтора раза быстрее VC-шного CRT-аллокатора, и ето быстро??? абберация налицо
Здравствуйте, CreatorCray, Вы писали:
CC>Там Per-thread pool с lock-free deferred алгоритмом на случай освобождения памяти из не-родного-потока.
Кстати с явным Free тоже бльшая попа. Все это придется оборачивать в очередные умные указатели чтобы не было утечек.
Заметь что код на C#, такой как в тесте, не требует никаких усилий чтобы работать быстро. Чтобы работал быстро аналогичный код на С++ требуется немало усилий.
Здравствуйте, Хвост, Вы писали:
Х>Здравствуйте, CreatorCray, Вы писали:
G>>>Твой наколенный непотокобезопасен. CC>> CC>>Жжошь! CC>>Можно узнать с какого перепугу ты так решил? Х>ну как же, ведь всё что быстрее гц ето заведомо непотокобезопасно и вообще UB Х>кстати результат гц просто удручает, всего в полтора раза быстрее VC-шного CRT-аллокатора, и ето быстро??? абберация налицо
Мда.. 30% оверхеда на жоступ к массиву это ой какие тормоза (кстати где код?), а в полтора раза быстрее — это "всего".
Вам, батенька, в политику надо. Там двойные стандарты и подтасовки во всю используются.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, CreatorCray, Вы писали:
CC>>Там Per-thread pool с lock-free deferred алгоритмом на случай освобождения памяти из не-родного-потока.
G>Кстати с явным Free тоже бльшая попа. Все это придется оборачивать в очередные умные указатели чтобы не было утечек.
G>Заметь что код на C#, такой как в тесте, не требует никаких усилий чтобы работать быстро. Чтобы работал быстро аналогичный код на С++ требуется немало усилий.
в полтора раза быстрее чем С++ ный CRT аллокатор ето не быстро, вот сделать быстро на C# нет вообще вариантов, возможно только через ансейф но ето настолько уныло в пользовании что даже обсуждать не стоит.
Здравствуйте, Хвост, Вы писали:
Х>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, CreatorCray, Вы писали:
CC>>>Там Per-thread pool с lock-free deferred алгоритмом на случай освобождения памяти из не-родного-потока.
G>>Кстати с явным Free тоже бльшая попа. Все это придется оборачивать в очередные умные указатели чтобы не было утечек.
G>>Заметь что код на C#, такой как в тесте, не требует никаких усилий чтобы работать быстро. Чтобы работал быстро аналогичный код на С++ требуется немало усилий. Х>в полтора раза быстрее чем С++ ный CRT аллокатор ето не быстро, вот сделать быстро на C# нет вообще вариантов, возможно только через ансейф но ето настолько уныло в пользовании что даже обсуждать не стоит.
Здравствуйте, gandjustas, Вы писали:
G>>>Заметь что код на C#, такой как в тесте, не требует никаких усилий чтобы работать быстро. Чтобы работал быстро аналогичный код на С++ требуется немало усилий. Х>>в полтора раза быстрее чем С++ ный CRT аллокатор ето не быстро, вот сделать быстро на C# нет вообще вариантов, возможно только через ансейф но ето настолько уныло в пользовании что даже обсуждать не стоит.
G>Что именно сделать быстро надо?
аллокации, ты что собственно мерил своим тестом?
G>Ты писал на C#?
был период, когда жизнь заставляла использовать ету замазку для мозга, да.
Здравствуйте, samius, Вы писали:
S>>Для того, чтобы написать программу, в которой будет заметен эффект от того, что лямбда размещена не в стеке, нужно очень-очень постараться. А мы тем временем продолжаем надеяться на то, что за то время, которое тебе потребуется для написания этой программы, к CLR таки прикрутят escape analysis. А в отличие от нативного кода, MSIL всех приложений автоматически выиграет от этого будущего улучшения без явной перекомпиляции и передеплоймента приложений. S>Да не, можно найти тысячу ситуаций (искувственных и натуральных), где разница в способе размещения замыкания будет заметна. Взять хотя бы тот же расчет координат в GIS-ах. Да, точно! В таких нагруженных случаях пользоваться лямбдой вообще неуместно, потому говорить о разнице между размещением замыкания лямбды на стеке и хипе как-бы неуместно. Боюсь что больше будет заметна разница лямбд на делегатах (в C#) и лямбд на виртуальных функциях (Nemerle и F#).
кстати вот лично у меня для трансформации используется функтор, который создаётся на стеке, но компиляторы С++ сейчас настолько умные что инлайнят всё и вся и оверхедов ноль, поетому в С++ я думаю лямбды в моём случае никак не повлияют на производительность, а вот с C# вопрос не однозначен.
Здравствуйте, criosray, Вы писали:
G>>>Ты писал на C#? Х>>был период, когда жизнь заставляла использовать ету замазку для мозга, да. C>Замазка Вам явно не помешала бы — чтоб поменьше сквозняков было.
вы по своему богатому опыту судите?
Здравствуйте, Хвост, Вы писали:
Х>Здравствуйте, gandjustas, Вы писали:
G>>>>Заметь что код на C#, такой как в тесте, не требует никаких усилий чтобы работать быстро. Чтобы работал быстро аналогичный код на С++ требуется немало усилий. Х>>>в полтора раза быстрее чем С++ ный CRT аллокатор ето не быстро, вот сделать быстро на C# нет вообще вариантов, возможно только через ансейф но ето настолько уныло в пользовании что даже обсуждать не стоит.
G>>Что именно сделать быстро надо? Х>аллокации, ты что собственно мерил своим тестом?
И как их с помощью ансейфа сделать быстро?
И как сделать универсальный аллокатор на С++, сравнимый по скорости с .NETовским?
G>>Ты писал на C#? Х>был период, когда жизнь заставляла использовать ету замазку для мозга, да.
То есть не писал.
Здравствуйте, gandjustas, Вы писали:
G>>>Что именно сделать быстро надо? Х>>аллокации, ты что собственно мерил своим тестом? G>И как их с помощью ансейфа сделать быстро?
Ну как, "мы наш, мы новый мир построим", HeapAlloc + ручное управление памятью, указатели, MyMemMgr.alloc() етц, только пользовать ето будет сложнее, смартпоинтеров то нет
G>И как сделать универсальный аллокатор на С++, сравнимый по скорости с .NETовским?
скажи мне что такое универсальный аллокатор, вот аллокатор by CreatorCray для меня достаточно универсален. можно взять tcmalloc, тоже быстрая и потокобезопасная вещь, универсальней что называется некуда, т.к. замена CRTшным malloc/free/realloc..
G>>>Ты писал на C#? Х>>был период, когда жизнь заставляла использовать ету замазку для мозга, да. G>То есть не писал.
в С++ лямбд не существует, ага.
Здравствуйте, Хвост, Вы писали:
Х>Здравствуйте, gandjustas, Вы писали:
G>>>>Что именно сделать быстро надо? Х>>>аллокации, ты что собственно мерил своим тестом? G>>И как их с помощью ансейфа сделать быстро? Х>Ну как, "мы наш, мы новый мир построим", HeapAlloc + ручное управление памятью, указатели, MyMemMgr.alloc() етц, только пользовать ето будет сложнее, смартпоинтеров то нет
Ты прикалываешься или реально тупость говоришь?
1)HeapAlloc работает медленнее, чем GC
2)Даже если выделишь память с помощью unmanaged, то ты не сможешь создать .NET объект в ней.
3)Ты не сможешь хранить ссылки на managed объекты в таком блоке памяти.
В итого это не будет ни быстрее, ни надежнее. Если ты серьезно считаешь что таким вообще стоит заниматься в каком либо случае, то тебе надо срочно обратиться к доктору.
Здравствуйте, gandjustas, Вы писали:
Х>>Ну как, "мы наш, мы новый мир построим", HeapAlloc + ручное управление памятью, указатели, MyMemMgr.alloc() етц, только пользовать ето будет сложнее, смартпоинтеров то нет G>Ты прикалываешься или реально тупость говоришь? G>1)HeapAlloc работает медленнее, чем GC G>2)Даже если выделишь память с помощью unmanaged, то ты не сможешь создать .NET объект в ней. G>3)Ты не сможешь хранить ссылки на managed объекты в таком блоке памяти.
я разве где-то утверждал обратное? а то что будет нелегко (пункты 2, 3) так етож C#, он такой)
G>В итого это не будет ни быстрее, ни надежнее. Если ты серьезно считаешь что таким вообще стоит заниматься в каком либо случае, то тебе надо срочно обратиться к доктору.
менежмент руками будет быстрее, надёжнее или нет — ето больше радиус кривизны рук решает.
я считаю что таким действительно не стоит заниматься, C# для етого не предназначен, он высокоуровненвый и медленный, хочешь высокоуровневый и быстрый — бери С++.
Здравствуйте, Хвост, Вы писали:
Х>давай тезисами опишу проблемму Х>чтобы трансформировать на железе — нужно иметь псевдо-екранные координаты (ето ещё не проблемма) Х>для того чтобы работать со всей геометрией — нужно иметь её всю в псевдо-екранных координатах (тут проблемма — резко возросшее число геометрии для трансформации)
Что значит работать со всей геометрией? Счет или рендеринг? Для рендеринга не нужна вся геометрия. Пусть хранится как есть, в геодезии али еще чем-там. Х>если не всю — а только видимую, то необходимо постоянно пересчитывать в псевдо-екранные координаты геометрию, появляющуюся во вьюхе при скролле/зуме
Не пересчитывать, а досчитывать. Разве это проблема? А без промежуточных координат требуется именно пересчитвать экранные координаты всех объектов каждый раз. Либо кэшировать экранные координаты, которые придется обновлять при смене вида. Тут опять встает вопрос "набегания погрешности". X> (тут проблемма — какой тогда смысл в трансформациях на железе если нужно постоянно трансформировать в псевдо-екранные координаты новую видимую геометрию)
Смысл делать на железе тот, что железо это все равно делает, хочешь ты того или нет. Там преобразование в конвейере. Только в одном случае, когда ты софтом преобразуешь, железо делает единичное преобразование вхолостую (AFAIK).
Теперь рассмотрим два случая: первый — при прорисовке каждого примитива полностью рассчитывается преобразование из системы координат хранения (допустим геодезия) в экранные. Так?
Второй случай — когда расчитываются промежуточные координаты один раз, а дальше при каждой прорисовке из промежуточных в экранные с помощью железа. Таким образом софт подсчитывает только промежуточные координаты один раз когда объект попадает в вид и не считает координаты для этого объекта до тех пор, пока объект кэшируется.
Х>>>>да, можно, если учесть неточности железки и соответственно с этим написать алгоритм пролёта. S>>>Какие неточности железки? Пиксель туда-сюда? Х>ну вообще-то не пиксель, а поболе, заметно глазу.
Что-то сомневаюсь, что железо на столько дает погрешность.
Здравствуйте, samius, Вы писали:
S>Здравствуйте, Хвост, Вы писали:
Х>>давай тезисами опишу проблемму Х>>чтобы трансформировать на железе — нужно иметь псевдо-екранные координаты (ето ещё не проблемма) Х>>для того чтобы работать со всей геометрией — нужно иметь её всю в псевдо-екранных координатах (тут проблемма — резко возросшее число геометрии для трансформации) S>Что значит работать со всей геометрией? Счет или рендеринг? Для рендеринга не нужна вся геометрия. Пусть хранится как есть, в геодезии али еще чем-там. Х>>если не всю — а только видимую, то необходимо постоянно пересчитывать в псевдо-екранные координаты геометрию, появляющуюся во вьюхе при скролле/зуме S>Не пересчитывать, а досчитывать. Разве это проблема? А без промежуточных координат требуется именно пересчитвать экранные координаты всех объектов каждый раз. Либо кэшировать экранные координаты, которые придется обновлять при смене вида. Тут опять встает вопрос "набегания погрешности".
ну что значит досчитывать? вот я смотрю на екран, вижу объекты, нажал на другое место на обзорной вьюхе — у меня совсем другие объекты на екране, их прийдётся пересчитывать в псевдо-екранные, а ведь можно сразу в екранные. Если активно скроллить — зумить, то объекты на екране сменяют друг друга почти так же быстро как и при клике на обзорной вьюхе, тут "досчитывать" придётся по пол-екрана на скролл-зум.
