Re[11]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 16.06.09 20:29
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

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

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

DC>Да и, честно говоря, разделять объект между двумя нитями не самая хорошая идея, я бы даже при наличии GC так делать по-возможности не стал.

Тут речь идет не об объектах, а о выделении памяти.

G>>В том то и дело что GC, по крайней мере в .NET, рассчитан на огромное число сценариев работы. Главное ему не мешать, и уж тем более не пытться помогать.

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

G>>На словах просто, а на деле большое количество велосипедов делаю очень тяжелой поддержку. При этом далеко не факт что кучи велосипедов будут работать быстрее GC.

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

DC>Я, вообще, о чём говорил: отсутствие GC не самая большая проблема C++.

Решение проблем С++ требует наличия GC.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[12]: С# vs C++, голые цифры
От: dr.Chaos Россия Украшения HandMade
Дата: 17.06.09 07:40
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Не требует.


Он что работает в несколько потоков и при этом у этих потоков совсем нет разделяемых данных?

G>Тут речь идет не об объектах, а о выделении памяти.

Погоди, каким боком синхронизация счётчиков и выделение памяти? Если у нас объект между нитями не разделяется то и синхронизировать ничего не надо.

G>Ну если брать сферического программиста в вакууме, который никогда не ошибается, то да.

Ну так я и сказал — дороже.

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

Ну взяли они shared_ptr и довольны как слоны .

DC>>Я, вообще, о чём говорил: отсутствие GC не самая большая проблема C++.

G>Решение проблем С++ требует наличия GC.

Для некоторых проблем автоматическое управление памятью упростит их решение. GC — лишь один из способов автоматического управления памятью, причём он не всегда приемлем.

Вообще, ИМХО, эта проблема сильно преувеличена. Сделали из GC священную корову. Мне, например, в C++ намного бы полезнее были гигиенические макросы или другой простой способ построения eDSL-ей, удобный в использовании или отладке.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[13]: С# vs C++, голые цифры
От: kuj  
Дата: 17.06.09 07:47
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

G>>Не требует.


DC> Он что работает в несколько потоков и при этом у этих потоков совсем нет разделяемых данных?


Да, работает в несколько потоков — поток на ядро, если в server mode`е.
В .NET 4 будет background GC, которых можно будет запускать больше, чем один на ядро.
Re[13]: С# vs C++, голые цифры
От: kuj  
Дата: 17.06.09 07:52
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

DC>Для некоторых проблем автоматическое управление памятью упростит их решение. GC — лишь один из способов автоматического управления памятью, причём он не всегда приемлем.


DC>Вообще, ИМХО, эта проблема сильно преувеличена. Сделали из GC священную корову. Мне, например, в C++ намного бы полезнее были гигиенические макросы или другой простой способ построения eDSL-ей, удобный в использовании или отладке.


Ну конечно строить DSL`и без GC это вверх гениальности ;]
Re[14]: С# vs C++, голые цифры
От: dr.Chaos Россия Украшения HandMade
Дата: 17.06.09 08:01
Оценка:
Здравствуйте, kuj, Вы писали:

kuj>Ну конечно строить DSL`и без GC это вверх гениальности ;]

А какие проблемы?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[14]: С# vs C++, голые цифры
От: dr.Chaos Россия Украшения HandMade
Дата: 17.06.09 08:03
Оценка:
Здравствуйте, kuj, Вы писали:

DC>> Он что работает в несколько потоков и при этом у этих потоков совсем нет разделяемых данных?


kuj>Да, работает в несколько потоков — поток на ядро, если в server mode`е.

kuj>В .NET 4 будет background GC, которых можно будет запускать больше, чем один на ядро.

Меня не удивляет, то что он может работать в нескольких нитях. У меня вызывает сомнения выделенное.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[13]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 17.06.09 08:15
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

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


G>>Не требует.

DC> Он что работает в несколько потоков и при этом у этих потоков совсем нет разделяемых данных?
Ты не понял. Алгоритм выделения памяти в GC не требует блокировок, даже при выделении из нескольких потоков.

G>>Тут речь идет не об объектах, а о выделении памяти.

DC>Погоди, каким боком синхронизация счётчиков и выделение памяти? Если у нас объект между нитями не разделяется то и синхронизировать ничего не надо.
Ага, а кто-то тут еще предлагал не пользоваться динамическим выделением памяти
Кстати, как у вас многопоточные программы работают когда нету разделяемых данных?

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

DC>Ну взяли они shared_ptr и довольны как слоны .
Который работает еще медленее.
Тогда бы уже сразу взяли .NET

DC>>>Я, вообще, о чём говорил: отсутствие GC не самая большая проблема C++.

G>>Решение проблем С++ требует наличия GC.
DC>Для некоторых проблем автоматическое управление памятью упростит их решение. GC — лишь один из способов автоматического управления памятью, причём он не всегда приемлем.
А другой способ — считать ссылки, только он полон недостатков.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[15]: С# vs C++, голые цифры
От: kuj  
Дата: 17.06.09 08:23
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

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


kuj>>Ну конечно строить DSL`и без GC это вверх гениальности ;]

DC>А какие проблемы?
Перечислить по пунктам?
Re[14]: С# vs C++, голые цифры
От: dr.Chaos Россия Украшения HandMade
Дата: 17.06.09 08:28
Оценка:
Здравствуйте, gandjustas, Вы писали:

DC>> Он что работает в несколько потоков и при этом у этих потоков совсем нет разделяемых данных?

G>Ты не понял. Алгоритм выделения памяти в GC не требует блокировок, даже при выделении из нескольких потоков.
Ну а синхронизация счётчиков ссылок тут при чём? Да и если не устраивает стандартный аллокатор, берёшь и делаешь свой .

G>Кстати, как у вас многопоточные программы работают когда нету разделяемых данных?

Отлично и с линейной масштабируемостью

DC>>Ну взяли они shared_ptr и довольны как слоны .

G>Который работает еще медленее.
G>Тогда бы уже сразу взяли .NET
Докажи.

G>А другой способ — считать ссылки, только он полон недостатков.

А GC недостатков не имееет?
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[15]: С# vs C++, голые цифры
От: kuj  
Дата: 17.06.09 08:38
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

DC>>> Он что работает в несколько потоков и при этом у этих потоков совсем нет разделяемых данных?


kuj>>Да, работает в несколько потоков — поток на ядро, если в server mode`е.

kuj>>В .NET 4 будет background GC, которых можно будет запускать больше, чем один на ядро.

DC>Меня не удивляет, то что он может работать в нескольких нитях. У меня вызывает сомнения выделенное.


В server-mode создается несколько GC`ов — по одному на ядро. У каждого GC своя собственная managed куча. Каждый пользовательский поток получает место в одной из куч то ли рандомно то ли по очередно — точно не знаю — надо гуглить этот момент. Ну и еще там мутки с достижением gen0 лимита (примерно: если достигли лимита нулевой генерации в одной из куч, то последующие allocations будут производиться на второй/третьей/т.д. пока не будет выбран лимит и там или пока GC не наведет шмон в первой).
Re[15]: С# vs C++, голые цифры
От: kuj  
Дата: 17.06.09 08:40
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

G>>А другой способ — считать ссылки, только он полон недостатков.

DC>А GC недостатков не имееет?
В контексте многих (не побоюсь этого слова — большинства) задач достоинства GC с лихвой перевешивают все недостатки.
Re[15]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 17.06.09 08:53
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

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


DC>>> Он что работает в несколько потоков и при этом у этих потоков совсем нет разделяемых данных?

G>>Ты не понял. Алгоритм выделения памяти в GC не требует блокировок, даже при выделении из нескольких потоков.
DC>Ну а синхронизация счётчиков ссылок тут при чём? Да и если не устраивает стандартный аллокатор, берёшь и делаешь свой .
Ну да, всего-то


DC>>>Ну взяли они shared_ptr и довольны как слоны .

G>>Который работает еще медленее.
G>>Тогда бы уже сразу взяли .NET
DC>Докажи.
Чего доказать? Что shared_prt медленее? Так счетчик ссылок небесплатный.

G>>А другой способ — считать ссылки, только он полон недостатков.

DC>А GC недостатков не имееет?
Зависит от реализации GC.
В .NETовской реализации недостатков немного, по сравнению с подсчетом ссылок.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[16]: С# vs C++, голые цифры
От: dr.Chaos Россия Украшения HandMade
Дата: 17.06.09 08:59
Оценка:
Здравствуйте, kuj, Вы писали:

kuj>В server-mode создается несколько GC`ов — по одному на ядро. У каждого GC своя собственная managed куча. Каждый пользовательский поток получает место в одной из куч то ли рандомно то ли по очередно — точно не знаю — надо гуглить этот момент. Ну и еще там мутки с достижением gen0 лимита (примерно: если достигли лимита нулевой генерации в одной из куч, то последующие allocations будут производиться на второй/третьей/т.д. пока не будет выбран лимит и там или пока GC не наведет шмон в первой).


А если один поток передал объект другому чего происходит? Вобщем приведённое тобой не доказывает отсутствия издержек у GC.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[16]: С# vs C++, голые цифры
От: dr.Chaos Россия Украшения HandMade
Дата: 17.06.09 09:06
Оценка:
Здравствуйте, kuj, Вы писали:

kuj>Перечислить по пунктам?


Да. Причём лучше всего и для варианта реализации гигиенических макросов и для eDSL на монадах и комбинаторах a la Хаскель
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[16]: С# vs C++, голые цифры
От: dr.Chaos Россия Украшения HandMade
Дата: 17.06.09 09:07
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Ну да, всего-то


Ну если именно аллокация тормозит в многопоточном окружении, то её надо ускорять, да и не так уж сложно это — написать аллокатор. Мне вот интересно чего будете делать вы когда уткнётесь в GC? Пусть это и маловероятно.
Ты, кстати, так и не объяснил мне про синхронизацию счётчиков ссылок, а всё съезжаешь на выделение памяти в многопоточной среде.

DC>>Докажи.

G>Чего доказать? Что shared_prt медленее? Так счетчик ссылок небесплатный.
А проход GC когда бесплатным стал?

G>Зависит от реализации GC.

G>В .NETовской реализации недостатков немного, по сравнению с подсчетом ссылок.
Я тебе тоже могу сказать — зависит от реализации.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[17]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 17.06.09 09:23
Оценка:
Здравствуйте, dr.Chaos, Вы писали:

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


G>>Ну да, всего-то


DC>Ну если именно аллокация тормозит в многопоточном окружении, то её надо ускорять, да и не так уж сложно это — написать аллокатор.

Написать аллокатор (причем именно хороший аллокатор) — далеко нетривиальная задача. Вряд ли каждый второй программист на С++ сможет такое сделать.
Дай бог каждый сотый.

DC>Мне вот интересно чего будете делать вы когда уткнётесь в GC? Пусть это и маловероятно.

Все тоже самое что и в C++ — пулинг объектов, предварительное выделение буферов.
Тем более ты сам говришь что это маловероятно.

DC>Ты, кстати, так и не объяснил мне про синхронизацию счётчиков ссылок, а всё съезжаешь на выделение памяти в многопоточной среде.

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


DC>>>Докажи.

G>>Чего доказать? Что shared_prt медленее? Так счетчик ссылок небесплатный.
DC>А проход GC когда бесплатным стал?
Нет, но работает он быстрее стандартного аллокатора.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[18]: С# vs C++, голые цифры
От: FR  
Дата: 17.06.09 09:56
Оценка:
Здравствуйте, gandjustas, Вы писали:

DC>>Ну если именно аллокация тормозит в многопоточном окружении, то её надо ускорять, да и не так уж сложно это — написать аллокатор.

G>Написать аллокатор (причем именно хороший аллокатор) — далеко нетривиальная задача. Вряд ли каждый второй программист на С++ сможет такое сделать.
G>Дай бог каждый сотый.

Угу и они их давно написали и выложили, так что остальным 99% остается только скачать.
Re[18]: С# vs C++, голые цифры
От: dr.Chaos Россия Украшения HandMade
Дата: 17.06.09 10:50
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Написать аллокатор (причем именно хороший аллокатор) — далеко нетривиальная задача. Вряд ли каждый второй программист на С++ сможет такое сделать.

G>Дай бог каждый сотый.

Ну я думаю далеко не каждый программист на С++ натыкается на тормоза аллокации в многопоточной среде. Вообще есть мысль что стандартные аллокаторы заточены под вариант с многопоточностью, да и FR совершенно правильно заметил.

DC>>Мне вот интересно чего будете делать вы когда уткнётесь в GC? Пусть это и маловероятно.

G>Все тоже самое что и в C++ — пулинг объектов, предварительное выделение буферов.
G>Тем более ты сам говришь что это маловероятно.

DC>>Ты, кстати, так и не объяснил мне про синхронизацию счётчиков ссылок, а всё съезжаешь на выделение памяти в многопоточной среде.

G>Ну если хочется использовать подсчет ссылок в многопоточно среде, то это несет дополнительный оверхед, так как требуется синхронизация.
А если передавать объект которым управляет GC между потоками, синхронизации не надо? Да и синхронизации будет требовать не только посчёт ссылок.

G>Нет, но работает он быстрее стандартного аллокатора.


Ну я могу сказать что ручное управление памятью в любом случае быстрее и дешевле . Вобщем ты разберись чего GC у нас быстрее shared_ptr-а или стандартного аллокатора (кстати какой имеется ввиду? Windows, Linux, у STLPort вроде что-то своё было) и можешь дать ссылки на сравнения ну или сам тест сбацать.

Короче, дискуссия скатилась к тому что быстрее .Net GC или стандартный аллокатор, мне этот диспут не очень интересен, да и влез я сюда чтоб сказать, что ручное управление памятью это скорее достоинство С++, а автоматическое управление памятью в том или ином виде есть, причём как всегда в С++, можно заточиться под свои нужды и отсутствие GC это не самый страшный недостаток плюсов. Думаю, повторять это в 4-й раз смысла не имеет.
Побеждающий других — силен,
Побеждающий себя — Могущественен.
Лао Цзы
Re[19]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 17.06.09 11:06
Оценка:
Здравствуйте, FR, Вы писали:

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


DC>>>Ну если именно аллокация тормозит в многопоточном окружении, то её надо ускорять, да и не так уж сложно это — написать аллокатор.

G>>Написать аллокатор (причем именно хороший аллокатор) — далеко нетривиальная задача. Вряд ли каждый второй программист на С++ сможет такое сделать.
G>>Дай бог каждый сотый.

FR>Угу и они их давно написали и выложили, так что остальным 99% остается только скачать.


Ссылки дашь?
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Re[19]: С# vs C++, голые цифры
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 17.06.09 11:14
Оценка:
Здравствуйте, 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-й раз смысла не имеет.
http://files.rsdn.org/67312/MVP_Horizontal_Mini.png
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.