Сообщение Re[56]: Nemerle через 5 лет - выстрелит или скончается? от 08.10.2014 21:19
Изменено 08.10.2014 21:27 Evgeny.Panasyuk
Здравствуйте, WolfHound, Вы писали:
WH>>>>>И не дай байт написать это лишний раз.
EP>>>>Это уже вопрос к корректности, надёжности, тестированию, а не к производительности.
WH>>>Если на асме каждую инструкцию отполировать будет ещё быстрее.
EP>>Да, и?
WH>И сколько времени у тебя на это уйдёт?
На порядок больше чем если бы не было полировки, так как код C++ — optimization-friendly, после прохода оптимизатора остаётся не так много возможностей для улучшения
К чему вопрос-то?
Неужели ты считаешь цену ручной оптимизации ASM кода сопоставимой с ценой правильной расстановкой move/copy?
Или это как-то сравнимо с тем, когда для производительности полностью отказываются от GC, а-ля garbage-free?
EP>>Действительно не стоит, речь ведь шла не только про stop-the-world, но и про прочие GC радости
EP>>А уж какие там конкретно GC радости в замену нескольких атомарных передёргиваний счётчика — рояли не играет.
WH>Это ещё большой вопрос.
Поделись соображениями. С одной стороны у нас редкие wait-free inc/dec, с другой — конкурентная-пакость, которая параллельно основным потокам шарит по их данным и делает какие-то манипуляции, хорошо ещё если lock-free.
EP>>И что, прям весь код был заселён ref-counting'ом, и он там был действительно к месту?
WH>Разные проекты были. Был такой, где действительно всё было засалено этой субстанцией. И иначе было нельзя.
А хотя бы чем было обусловлено? Какими-то алгоритмическими/прикладными особенностями? Или возможно каким-то interop'ом?
EP>>Можно и так, а при желании можно и GC — C++ -то позволяет
Для некоторых задач GC действительно удобнее всего, но таких задач крайне мало.
WH>Это не ГЦ. Это говно.
WH>Нормальный ГЦ С++ не позволяет.
Нормальный это какой?
В стандарте есть интерфейс для для консервативного GC.
Есть точные GC — но они менее автоматизированные чем консервативные. При использовании точных нужно заменять T* на gc_ptr<T> и т.п. При решении каких-то затейливых задач с жёсткими циклами — вполне себе вариант.
EP>>Конечно здорово, но это не ответ на вопрос. Если ничего готового нет — то ок, с prompt finalization проблемы
WH>Ты первый кто её просит. А раз никто не просит то никто и не делает.
Хотя бы как тогда разруливается ситуация с IDisposable? Например — один метод поставил using скобки на объект x, передал его в другой метод, который втихую сохранил его до лучших времён — в итоге у него окажется ссылка на disposed объект. Фейерверк?
WH>>>>>И не дай байт написать это лишний раз.
EP>>>>Это уже вопрос к корректности, надёжности, тестированию, а не к производительности.
WH>>>Если на асме каждую инструкцию отполировать будет ещё быстрее.
EP>>Да, и?
WH>И сколько времени у тебя на это уйдёт?
На порядок больше чем если бы не было полировки, так как код C++ — optimization-friendly, после прохода оптимизатора остаётся не так много возможностей для улучшения
К чему вопрос-то?
Неужели ты считаешь цену ручной оптимизации ASM кода сопоставимой с ценой правильной расстановкой move/copy?
Или это как-то сравнимо с тем, когда для производительности полностью отказываются от GC, а-ля garbage-free?
EP>>Действительно не стоит, речь ведь шла не только про stop-the-world, но и про прочие GC радости
EP>>А уж какие там конкретно GC радости в замену нескольких атомарных передёргиваний счётчика — рояли не играет.
WH>Это ещё большой вопрос.
Поделись соображениями. С одной стороны у нас редкие wait-free inc/dec, с другой — конкурентная-пакость, которая параллельно основным потокам шарит по их данным и делает какие-то манипуляции, хорошо ещё если lock-free.
EP>>И что, прям весь код был заселён ref-counting'ом, и он там был действительно к месту?
WH>Разные проекты были. Был такой, где действительно всё было засалено этой субстанцией. И иначе было нельзя.
А хотя бы чем было обусловлено? Какими-то алгоритмическими/прикладными особенностями? Или возможно каким-то interop'ом?
EP>>Можно и так, а при желании можно и GC — C++ -то позволяет
Для некоторых задач GC действительно удобнее всего, но таких задач крайне мало.WH>Это не ГЦ. Это говно.
WH>Нормальный ГЦ С++ не позволяет.
Нормальный это какой?
В стандарте есть интерфейс для для консервативного GC.
Есть точные GC — но они менее автоматизированные чем консервативные. При использовании точных нужно заменять T* на gc_ptr<T> и т.п. При решении каких-то затейливых задач с жёсткими циклами — вполне себе вариант.
EP>>Конечно здорово, но это не ответ на вопрос. Если ничего готового нет — то ок, с prompt finalization проблемы
WH>Ты первый кто её просит. А раз никто не просит то никто и не делает.
Хотя бы как тогда разруливается ситуация с IDisposable? Например — один метод поставил using скобки на объект x, передал его в другой метод, который втихую сохранил его до лучших времён — в итоге у него окажется ссылка на disposed объект. Фейерверк?
Re[56]: Nemerle через 5 лет - выстрелит или скончается?
Здравствуйте, WolfHound, Вы писали:
WH>>>>>И не дай байт написать это лишний раз.
EP>>>>Это уже вопрос к корректности, надёжности, тестированию, а не к производительности.
WH>>>Если на асме каждую инструкцию отполировать будет ещё быстрее.
EP>>Да, и?
WH>И сколько времени у тебя на это уйдёт?
В разы, а то и на порядок больше чем если бы не было полировки, так как код C++ — optimization-friendly, после прохода оптимизатора остаётся не так много возможностей для улучшения
К чему вопрос-то?
Неужели ты считаешь цену ручной оптимизации ASM кода сопоставимой с ценой правильной расстановкой move/copy?
Или это как-то сравнимо с тем, когда для производительности полностью отказываются от GC, а-ля garbage-free?
EP>>Действительно не стоит, речь ведь шла не только про stop-the-world, но и про прочие GC радости
EP>>А уж какие там конкретно GC радости в замену нескольких атомарных передёргиваний счётчика — рояли не играет.
WH>Это ещё большой вопрос.
Поделись соображениями. С одной стороны у нас редкие wait-free inc/dec, с другой — конкурентная-пакость, которая параллельно основным потокам шарит по их данным и делает какие-то манипуляции, хорошо ещё если lock-free.
EP>>И что, прям весь код был заселён ref-counting'ом, и он там был действительно к месту?
WH>Разные проекты были. Был такой, где действительно всё было засалено этой субстанцией. И иначе было нельзя.
А хотя бы чем было обусловлено? Какими-то алгоритмическими/прикладными особенностями? Или возможно каким-то interop'ом?
EP>>Можно и так, а при желании можно и GC — C++ -то позволяет Для некоторых задач GC действительно удобнее всего, но таких задач крайне мало.
WH>Это не ГЦ. Это говно.
WH>Нормальный ГЦ С++ не позволяет.
Нормальный это какой?
В стандарте есть интерфейс для для консервативного GC.
Есть точные GC — но они менее автоматизированные чем консервативные. При использовании точных нужно заменять T* на gc_ptr<T> и т.п. При решении каких-то затейливых задач с жёсткими циклами — вполне себе вариант.
EP>>Конечно здорово, но это не ответ на вопрос. Если ничего готового нет — то ок, с prompt finalization проблемы
WH>Ты первый кто её просит. А раз никто не просит то никто и не делает.
Хотя бы как тогда разруливается ситуация с IDisposable? Например — один метод поставил using скобки на объект, передал его в другой метод, который втихую сохранил его до лучших времён — в итоге у него окажется ссылка на disposed объект. Фейерверк?
WH>>>>>И не дай байт написать это лишний раз.
EP>>>>Это уже вопрос к корректности, надёжности, тестированию, а не к производительности.
WH>>>Если на асме каждую инструкцию отполировать будет ещё быстрее.
EP>>Да, и?
WH>И сколько времени у тебя на это уйдёт?
В разы, а то и на порядок больше чем если бы не было полировки, так как код C++ — optimization-friendly, после прохода оптимизатора остаётся не так много возможностей для улучшения
К чему вопрос-то?
Неужели ты считаешь цену ручной оптимизации ASM кода сопоставимой с ценой правильной расстановкой move/copy?
Или это как-то сравнимо с тем, когда для производительности полностью отказываются от GC, а-ля garbage-free?
EP>>Действительно не стоит, речь ведь шла не только про stop-the-world, но и про прочие GC радости
EP>>А уж какие там конкретно GC радости в замену нескольких атомарных передёргиваний счётчика — рояли не играет.
WH>Это ещё большой вопрос.
Поделись соображениями. С одной стороны у нас редкие wait-free inc/dec, с другой — конкурентная-пакость, которая параллельно основным потокам шарит по их данным и делает какие-то манипуляции, хорошо ещё если lock-free.
EP>>И что, прям весь код был заселён ref-counting'ом, и он там был действительно к месту?
WH>Разные проекты были. Был такой, где действительно всё было засалено этой субстанцией. И иначе было нельзя.
А хотя бы чем было обусловлено? Какими-то алгоритмическими/прикладными особенностями? Или возможно каким-то interop'ом?
EP>>Можно и так, а при желании можно и GC — C++ -то позволяет
Для некоторых задач GC действительно удобнее всего, но таких задач крайне мало.WH>Это не ГЦ. Это говно.
WH>Нормальный ГЦ С++ не позволяет.
Нормальный это какой?
В стандарте есть интерфейс для для консервативного GC.
Есть точные GC — но они менее автоматизированные чем консервативные. При использовании точных нужно заменять T* на gc_ptr<T> и т.п. При решении каких-то затейливых задач с жёсткими циклами — вполне себе вариант.
EP>>Конечно здорово, но это не ответ на вопрос. Если ничего готового нет — то ок, с prompt finalization проблемы
WH>Ты первый кто её просит. А раз никто не просит то никто и не делает.
Хотя бы как тогда разруливается ситуация с IDisposable? Например — один метод поставил using скобки на объект, передал его в другой метод, который втихую сохранил его до лучших времён — в итоге у него окажется ссылка на disposed объект. Фейерверк?