Здравствуйте, dr.Chaos, Вы писали:
DC>>>Если мы перекладываем управление на железку вполне логично что это требует ресурсов, оверхед от счётчиков небольшой, время освобождения ресурса детерминировано. G>>Счетчики ссылок требуют синхронизации, что сказывается на производительности в многопоточных системах. Кроме того они слабо умеют разаруливать циклические ссылки. DC>Ну многопоточный GC тоже требует накладных расходов на синхронизацию, кроме того если у меня будет затык именно в синхронизации счётчиков, то я вполне могу убрать его нафиг и управлять вручную.
Не требует.
DC>Да и, честно говоря, разделять объект между двумя нитями не самая хорошая идея, я бы даже при наличии GC так делать по-возможности не стал.
Тут речь идет не об объектах, а о выделении памяти.
G>>В том то и дело что GC, по крайней мере в .NET, рассчитан на огромное число сценариев работы. Главное ему не мешать, и уж тем более не пытться помогать. DC>Ну точно помню, что Cyberaxe говорил что он со свапом не дружит. Вот тут про картинки речь шла. Вобщем, я не настолько хорошо знаю его особенности чтоб предметно обсуждать его узкие места, но ручное управление памятью он не обойдёт, правда управлять памятью вручную дороже.
Ну если брать сферического программиста в вакууме, который никогда не ошибается, то да.
В реальности программы пишут живые люди средней квалификации, большинство из котороых и не особо знает как можно ускорить работу с памятью в C++.
G>>На словах просто, а на деле большое количество велосипедов делаю очень тяжелой поддержку. При этом далеко не факт что кучи велосипедов будут работать быстрее GC. DC>Велосипед может не претендовать на универсальность, и за счёт этого быть простым и быстрым или распадаться на несколько простых вариантов, которые могут быть довольно просты в поддержке. Только использование всего этого зоопарка, вероятнее, будет требовать большей аккуратности, чем просто дать всё на откуп GC, правда в умелых руках и GC может просесть.
Аналогично предыдущему.
DC>Я, вообще, о чём говорил: отсутствие GC не самая большая проблема C++.
Решение проблем С++ требует наличия GC.
Здравствуйте, gandjustas, Вы писали:
G>Не требует.
Он что работает в несколько потоков и при этом у этих потоков совсем нет разделяемых данных?
G>Тут речь идет не об объектах, а о выделении памяти.
Погоди, каким боком синхронизация счётчиков и выделение памяти? Если у нас объект между нитями не разделяется то и синхронизировать ничего не надо.
G>Ну если брать сферического программиста в вакууме, который никогда не ошибается, то да.
Ну так я и сказал — дороже.
G>В реальности программы пишут живые люди средней квалификации, большинство из котороых и не особо знает как можно ускорить работу с памятью в C++.
Ну взяли они shared_ptr и довольны как слоны .
DC>>Я, вообще, о чём говорил: отсутствие GC не самая большая проблема C++. G>Решение проблем С++ требует наличия GC.
Для некоторых проблем автоматическое управление памятью упростит их решение. GC — лишь один из способов автоматического управления памятью, причём он не всегда приемлем.
Вообще, ИМХО, эта проблема сильно преувеличена. Сделали из GC священную корову. Мне, например, в C++ намного бы полезнее были гигиенические макросы или другой простой способ построения eDSL-ей, удобный в использовании или отладке.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, dr.Chaos, Вы писали:
G>>Не требует.
DC> Он что работает в несколько потоков и при этом у этих потоков совсем нет разделяемых данных?
Да, работает в несколько потоков — поток на ядро, если в server mode`е.
В .NET 4 будет background GC, которых можно будет запускать больше, чем один на ядро.
Здравствуйте, dr.Chaos, Вы писали:
DC>Для некоторых проблем автоматическое управление памятью упростит их решение. GC — лишь один из способов автоматического управления памятью, причём он не всегда приемлем.
DC>Вообще, ИМХО, эта проблема сильно преувеличена. Сделали из GC священную корову. Мне, например, в C++ намного бы полезнее были гигиенические макросы или другой простой способ построения eDSL-ей, удобный в использовании или отладке.
Ну конечно строить DSL`и без GC это вверх гениальности ;]
Здравствуйте, kuj, Вы писали:
DC>> Он что работает в несколько потоков и при этом у этих потоков совсем нет разделяемых данных?
kuj>Да, работает в несколько потоков — поток на ядро, если в server mode`е. kuj>В .NET 4 будет background GC, которых можно будет запускать больше, чем один на ядро.
Меня не удивляет, то что он может работать в нескольких нитях. У меня вызывает сомнения выделенное.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, dr.Chaos, Вы писали:
DC>Здравствуйте, gandjustas, Вы писали:
G>>Не требует. DC> Он что работает в несколько потоков и при этом у этих потоков совсем нет разделяемых данных?
Ты не понял. Алгоритм выделения памяти в GC не требует блокировок, даже при выделении из нескольких потоков.
G>>Тут речь идет не об объектах, а о выделении памяти. DC>Погоди, каким боком синхронизация счётчиков и выделение памяти? Если у нас объект между нитями не разделяется то и синхронизировать ничего не надо.
Ага, а кто-то тут еще предлагал не пользоваться динамическим выделением памяти
Кстати, как у вас многопоточные программы работают когда нету разделяемых данных?
G>>В реальности программы пишут живые люди средней квалификации, большинство из котороых и не особо знает как можно ускорить работу с памятью в C++. DC>Ну взяли они shared_ptr и довольны как слоны .
Который работает еще медленее.
Тогда бы уже сразу взяли .NET
DC>>>Я, вообще, о чём говорил: отсутствие GC не самая большая проблема C++. G>>Решение проблем С++ требует наличия GC. DC>Для некоторых проблем автоматическое управление памятью упростит их решение. GC — лишь один из способов автоматического управления памятью, причём он не всегда приемлем.
А другой способ — считать ссылки, только он полон недостатков.
Здравствуйте, dr.Chaos, Вы писали:
DC>Здравствуйте, kuj, Вы писали:
kuj>>Ну конечно строить DSL`и без GC это вверх гениальности ;] DC>А какие проблемы?
Перечислить по пунктам?
Здравствуйте, gandjustas, Вы писали:
DC>> Он что работает в несколько потоков и при этом у этих потоков совсем нет разделяемых данных? G>Ты не понял. Алгоритм выделения памяти в GC не требует блокировок, даже при выделении из нескольких потоков.
Ну а синхронизация счётчиков ссылок тут при чём? Да и если не устраивает стандартный аллокатор, берёшь и делаешь свой .
G>Кстати, как у вас многопоточные программы работают когда нету разделяемых данных?
Отлично и с линейной масштабируемостью
DC>>Ну взяли они shared_ptr и довольны как слоны . G>Который работает еще медленее. G>Тогда бы уже сразу взяли .NET
Докажи.
G>А другой способ — считать ссылки, только он полон недостатков.
А GC недостатков не имееет?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, dr.Chaos, Вы писали:
DC>>> Он что работает в несколько потоков и при этом у этих потоков совсем нет разделяемых данных?
kuj>>Да, работает в несколько потоков — поток на ядро, если в server mode`е. kuj>>В .NET 4 будет background GC, которых можно будет запускать больше, чем один на ядро.
DC>Меня не удивляет, то что он может работать в нескольких нитях. У меня вызывает сомнения выделенное.
В server-mode создается несколько GC`ов — по одному на ядро. У каждого GC своя собственная managed куча. Каждый пользовательский поток получает место в одной из куч то ли рандомно то ли по очередно — точно не знаю — надо гуглить этот момент. Ну и еще там мутки с достижением gen0 лимита (примерно: если достигли лимита нулевой генерации в одной из куч, то последующие allocations будут производиться на второй/третьей/т.д. пока не будет выбран лимит и там или пока GC не наведет шмон в первой).
Здравствуйте, dr.Chaos, Вы писали:
G>>А другой способ — считать ссылки, только он полон недостатков. DC>А GC недостатков не имееет?
В контексте многих (не побоюсь этого слова — большинства) задач достоинства GC с лихвой перевешивают все недостатки.
Здравствуйте, dr.Chaos, Вы писали:
DC>Здравствуйте, gandjustas, Вы писали:
DC>>> Он что работает в несколько потоков и при этом у этих потоков совсем нет разделяемых данных? G>>Ты не понял. Алгоритм выделения памяти в GC не требует блокировок, даже при выделении из нескольких потоков. DC>Ну а синхронизация счётчиков ссылок тут при чём? Да и если не устраивает стандартный аллокатор, берёшь и делаешь свой .
Ну да, всего-то
DC>>>Ну взяли они shared_ptr и довольны как слоны . G>>Который работает еще медленее. G>>Тогда бы уже сразу взяли .NET DC>Докажи.
Чего доказать? Что shared_prt медленее? Так счетчик ссылок небесплатный.
G>>А другой способ — считать ссылки, только он полон недостатков. DC>А GC недостатков не имееет?
Зависит от реализации GC.
В .NETовской реализации недостатков немного, по сравнению с подсчетом ссылок.
Здравствуйте, kuj, Вы писали:
kuj>В server-mode создается несколько GC`ов — по одному на ядро. У каждого GC своя собственная managed куча. Каждый пользовательский поток получает место в одной из куч то ли рандомно то ли по очередно — точно не знаю — надо гуглить этот момент. Ну и еще там мутки с достижением gen0 лимита (примерно: если достигли лимита нулевой генерации в одной из куч, то последующие allocations будут производиться на второй/третьей/т.д. пока не будет выбран лимит и там или пока GC не наведет шмон в первой).
А если один поток передал объект другому чего происходит? Вобщем приведённое тобой не доказывает отсутствия издержек у GC.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, gandjustas, Вы писали:
G>Ну да, всего-то
Ну если именно аллокация тормозит в многопоточном окружении, то её надо ускорять, да и не так уж сложно это — написать аллокатор. Мне вот интересно чего будете делать вы когда уткнётесь в GC? Пусть это и маловероятно.
Ты, кстати, так и не объяснил мне про синхронизацию счётчиков ссылок, а всё съезжаешь на выделение памяти в многопоточной среде.
DC>>Докажи. G>Чего доказать? Что shared_prt медленее? Так счетчик ссылок небесплатный.
А проход GC когда бесплатным стал?
G>Зависит от реализации GC. G>В .NETовской реализации недостатков немного, по сравнению с подсчетом ссылок.
Я тебе тоже могу сказать — зависит от реализации.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, dr.Chaos, Вы писали:
DC>Здравствуйте, gandjustas, Вы писали:
G>>Ну да, всего-то
DC>Ну если именно аллокация тормозит в многопоточном окружении, то её надо ускорять, да и не так уж сложно это — написать аллокатор.
Написать аллокатор (причем именно хороший аллокатор) — далеко нетривиальная задача. Вряд ли каждый второй программист на С++ сможет такое сделать.
Дай бог каждый сотый.
DC>Мне вот интересно чего будете делать вы когда уткнётесь в GC? Пусть это и маловероятно.
Все тоже самое что и в C++ — пулинг объектов, предварительное выделение буферов.
Тем более ты сам говришь что это маловероятно.
DC>Ты, кстати, так и не объяснил мне про синхронизацию счётчиков ссылок, а всё съезжаешь на выделение памяти в многопоточной среде.
Ну если хочется использовать подсчет ссылок в многопоточно среде, то это несет дополнительный оверхед, так как требуется синхронизация.
DC>>>Докажи. G>>Чего доказать? Что shared_prt медленее? Так счетчик ссылок небесплатный. DC>А проход GC когда бесплатным стал?
Нет, но работает он быстрее стандартного аллокатора.
Здравствуйте, gandjustas, Вы писали:
DC>>Ну если именно аллокация тормозит в многопоточном окружении, то её надо ускорять, да и не так уж сложно это — написать аллокатор. G>Написать аллокатор (причем именно хороший аллокатор) — далеко нетривиальная задача. Вряд ли каждый второй программист на С++ сможет такое сделать. G>Дай бог каждый сотый.
Угу и они их давно написали и выложили, так что остальным 99% остается только скачать.
Здравствуйте, gandjustas, Вы писали:
G>Написать аллокатор (причем именно хороший аллокатор) — далеко нетривиальная задача. Вряд ли каждый второй программист на С++ сможет такое сделать. G>Дай бог каждый сотый.
Ну я думаю далеко не каждый программист на С++ натыкается на тормоза аллокации в многопоточной среде. Вообще есть мысль что стандартные аллокаторы заточены под вариант с многопоточностью, да и FR совершенно правильно заметил.
DC>>Мне вот интересно чего будете делать вы когда уткнётесь в GC? Пусть это и маловероятно. G>Все тоже самое что и в C++ — пулинг объектов, предварительное выделение буферов. G>Тем более ты сам говришь что это маловероятно.
DC>>Ты, кстати, так и не объяснил мне про синхронизацию счётчиков ссылок, а всё съезжаешь на выделение памяти в многопоточной среде. G>Ну если хочется использовать подсчет ссылок в многопоточно среде, то это несет дополнительный оверхед, так как требуется синхронизация.
А если передавать объект которым управляет GC между потоками, синхронизации не надо? Да и синхронизации будет требовать не только посчёт ссылок.
G>Нет, но работает он быстрее стандартного аллокатора.
Ну я могу сказать что ручное управление памятью в любом случае быстрее и дешевле . Вобщем ты разберись чего GC у нас быстрее shared_ptr-а или стандартного аллокатора (кстати какой имеется ввиду? Windows, Linux, у STLPort вроде что-то своё было) и можешь дать ссылки на сравнения ну или сам тест сбацать.
Короче, дискуссия скатилась к тому что быстрее .Net GC или стандартный аллокатор, мне этот диспут не очень интересен, да и влез я сюда чтоб сказать, что ручное управление памятью это скорее достоинство С++, а автоматическое управление памятью в том или ином виде есть, причём как всегда в С++, можно заточиться под свои нужды и отсутствие GC это не самый страшный недостаток плюсов. Думаю, повторять это в 4-й раз смысла не имеет.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, gandjustas, Вы писали:
DC>>>Ну если именно аллокация тормозит в многопоточном окружении, то её надо ускорять, да и не так уж сложно это — написать аллокатор. G>>Написать аллокатор (причем именно хороший аллокатор) — далеко нетривиальная задача. Вряд ли каждый второй программист на С++ сможет такое сделать. G>>Дай бог каждый сотый.
FR>Угу и они их давно написали и выложили, так что остальным 99% остается только скачать.
Здравствуйте, dr.Chaos, Вы писали:
DC>Здравствуйте, gandjustas, Вы писали:
G>>Написать аллокатор (причем именно хороший аллокатор) — далеко нетривиальная задача. Вряд ли каждый второй программист на С++ сможет такое сделать. G>>Дай бог каждый сотый.
DC>Ну я думаю далеко не каждый программист на С++ натыкается на тормоза аллокации в многопоточной среде. Вообще есть мысль что стандартные аллокаторы заточены под вариант с многопоточностью, да и FR совершенно правильно заметил.
Блокировки небесплатные, даже когда работает один поток. Но эти тормоза не настолько большие, чтобы на наих обращать внимание.
Вот также и с GC, пока не происходить сборка мусора во втором поколении каждую секунду, то работа сборщика мусора не оказывает влияния на общее быстродействие.
DC>>>Ты, кстати, так и не объяснил мне про синхронизацию счётчиков ссылок, а всё съезжаешь на выделение памяти в многопоточной среде. G>>Ну если хочется использовать подсчет ссылок в многопоточно среде, то это несет дополнительный оверхед, так как требуется синхронизация. DC>А если передавать объект которым управляет GC между потоками, синхронизации не надо?
Не надо.
DC>Да и синхронизации будет требовать не только посчёт ссылок.
А что еще?
G>>Нет, но работает он быстрее стандартного аллокатора.
DC>Ну я могу сказать что ручное управление памятью в любом случае быстрее и дешевле .
Теоретически быстрее может быть. А практически добиться таких результатов в сложных случаях выйдет настолько дорого, что реально этим никто заниматься не будет.
DC>Вобщем ты разберись чего GC у нас быстрее shared_ptr-а или стандартного аллокатора (кстати какой имеется ввиду? Windows, Linux, у STLPort вроде что-то своё было) и можешь дать ссылки на сравнения ну или сам тест сбацать.
Тест уже был, читайте холивары.
DC>Короче, дискуссия скатилась к тому что быстрее .Net GC или стандартный аллокатор, мне этот диспут не очень интересен, да и влез я сюда чтоб сказать, что ручное управление памятью это скорее достоинство С++, а автоматическое управление памятью в том или ином виде есть, причём как всегда в С++, можно заточиться под свои нужды и отсутствие GC это не самый страшный недостаток плюсов. Думаю, повторять это в 4-й раз смысла не имеет.
Он что работает в несколько потоков и при этом у этих потоков совсем нет разделяемых данных?
.
