Переквалификация c#-> ??

[crypto5]

Непонятно, почему я должен отказываться от оптимизаций и играть по правилам Джавы, где заведомо аллокация/удаление обьектов намного быстрее (за счет пожирания намного больше памяти).

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

[Интеррапт]

Вот если бы можно было ключем прикрутить алокатор который преалоцирует указанное количество памяти и на new не дергает *alloc, это другое дело. Есть такое?

Ес-но. Код я напишу. Даже попробую прикрутить свой аллокатор, который я использую со времен Qualcomm BREW.

б) вы начинаете писать небезопасный код

С какой это радости? References будут вполне безопасные в контекстах вашего теста. Иначе пишите другой тест, чтобы имитировать небезопасный код.
Просто JIT делает кучу оптимизаций, собственно в этом и сила Джавы. Непонятно, почему я должен отказываться от оптимизаций и играть по правилам Джавы, где заведомо аллокация/удаление обьектов намного быстрее (за счет пожирания намного больше памяти).

(UPDATE: сорри за репост сообщения)

[Интеррапт]

Непонятно, почему я должен отказываться от оптимизаций и играть по правилам Джавы, где заведомо аллокация/удаление обьектов намного быстрее (за счет пожирания намного больше памяти).

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

Используя референсы? Совершенно не теряю.

[Интеррапт]

Да и за Джавой в скорости никто не гонится. Мы тут рассматриваем какие-то искусственные тесты, собственно то, что можно назвать подгонкой задачи под сильные стороны Джавы. Вот если бы вы какой-то real life алгоритм привели, который я не мог бы реализовать быстрее на С++, то тогда действительно, пришлось бы признать поражение. Есть у вас такая задачка?

[crypto5]

Непонятно, почему я должен отказываться от оптимизаций и играть по правилам Джавы, где заведомо аллокация/удаление обьектов намного быстрее (за счет пожирания намного больше памяти).

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

Используя референсы? Совершенно не теряю.

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

[crypto5]

Да и за Джавой в скорости никто не гонится. Мы тут рассматриваем какие-то искусственные тесты, собственно то, что можно назвать подгонкой задачи под сильные стороны Джавы. Вот если бы вы какой-то real life алгоритм привели, который я не мог бы реализовать быстрее на С++, то тогда действительно, пришлось бы признать поражение. Есть у вас такая задачка?

Блин, ну я же уже писал, что я вполне охотно верю, что на ц++ можно путем определенных страданий достичь и даже превзойти производительность джавы. Спор был про АРК вс ГЦ.

[Интеррапт]

Непонятно, почему я должен отказываться от оптимизаций и играть по правилам Джавы, где заведомо аллокация/удаление обьектов намного быстрее (за счет пожирания намного больше памяти).

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

Используя референсы? Совершенно не теряю.

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

В этом случае очень даже можно предположить, что и JIT не будет таким же шустрым в оптимизации.

[crypto5]

Непонятно, почему я должен отказываться от оптимизаций и играть по правилам Джавы, где заведомо аллокация/удаление обьектов намного быстрее (за счет пожирания намного больше памяти).

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

Используя референсы? Совершенно не теряю.

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

В этом случае очень даже можно предположить, что и JIT не будет таким же шустрым в оптимизации.

Можно конечно, но мы меряем один единственный аспект - оверхед выделения и освобождения памяти, и данный тест отлично его демонстрирует.

[Интеррапт]

Да и за Джавой в скорости никто не гонится. Мы тут рассматриваем какие-то искусственные тесты, собственно то, что можно назвать подгонкой задачи под сильные стороны Джавы. Вот если бы вы какой-то real life алгоритм привели, который я не мог бы реализовать быстрее на С++, то тогда действительно, пришлось бы признать поражение. Есть у вас такая задачка?

Блин, ну я же уже писал, что я вполне охотно верю, что на ц++ можно путем определенных страданий достичь и даже превзойти производительность джавы. Спор был про АРК вс ГЦ.

Так я и не спорю, что в каких-то базовых случаях (как в случае вашего теста) GC будет быстрее. А вот в более сложных случаях - еще вопрос.

[Интеррапт]

Можно конечно, но мы меряем один единственный аспект - оверхед выделения и освобождения памяти, и данный тест отлично его демонстрирует.

Это мы пока еще не меряем. А на самом деле в С++ можно точно так же заалокировать эти самые 256 мегабайт памяти, как это Джава любит делать и размещать там все эти Data классы без отдельной аллокации и будет уж точно побыстрее, чем Джава.

[crypto5]

Да и за Джавой в скорости никто не гонится. Мы тут рассматриваем какие-то искусственные тесты, собственно то, что можно назвать подгонкой задачи под сильные стороны Джавы. Вот если бы вы какой-то real life алгоритм привели, который я не мог бы реализовать быстрее на С++, то тогда действительно, пришлось бы признать поражение. Есть у вас такая задачка?

Блин, ну я же уже писал, что я вполне охотно верю, что на ц++ можно путем определенных страданий достичь и даже превзойти производительность джавы. Спор был про АРК вс ГЦ.

Так я и не спорю, что в каких-то базовых случаях (как в случае вашего теста) GC будет быстрее. А вот в более сложных случаях - еще вопрос.

Ну приведите более адекватный на ваш взгляд тест/алгоритм.

[Интеррапт]

Ну приведите более адекватный на ваш взгляд тест/алгоритм.

Я подумаю над более real-life алгоритмом.

[crypto5]

Можно конечно, но мы меряем один единственный аспект - оверхед выделения и освобождения памяти, и данный тест отлично его демонстрирует.

Это мы пока еще не меряем. А на самом деле в С++ можно точно так же заалокировать эти самые 256 мегабайт памяти, как это Джава любит делать и размещать там все эти Data классы без отдельной аллокации и будет уж точно побыстрее, чем Джава.

Ну я вот пытаюсь нагуглить как это можно просто сделать, и не получается, может вы дадите подсказку?

[Интеррапт]

Ну я вот пытаюсь нагуглить как это можно просто сделать, и не получается, может вы дадите подсказку?

А что ты именно гуглить пытаешься?
Вообщем ладно, обязуюсь побороть лень и переписать этот твой тест с использованием placement new (ну или кастом аллокатора), чтобы убрать overhead аллокирования памяти из уравнения.

[crypto5]

Ну я вот пытаюсь нагуглить как это можно просто сделать, и не получается, может вы дадите подсказку?

А что ты именно гуглить пытаешься?
Вообщем ладно, обязуюсь побороть лень и переписать этот алгоритм с использованием placement new (ну или кастом аллокатора), чтобы убрать overhead аллокирования памяти из уровнения.

В идеале хотелось бы ключ, который встраивал какой нибудь клевый алокатор из какой нибудь проверенной библиотеки, который бы преалоцировал 500мб и не вызывал alloc.

[Интеррапт]

Ну я вот пытаюсь нагуглить как это можно просто сделать, и не получается, может вы дадите подсказку?

А что ты именно гуглить пытаешься?
Вообщем ладно, обязуюсь побороть лень и переписать этот алгоритм с использованием placement new (ну или кастом аллокатора), чтобы убрать overhead аллокирования памяти из уровнения.

В идеале хотелось бы ключ, который встраивал какой нибудь клевый алокатор из какой нибудь проверенной библиотеки, который бы преалоцировал 500мб и не вызывал alloc.

Теоретически такое возможно, глобально переопределив new/delete. Как я уже говорил, я такое делал для BREW, с алгоритмом, который отслеживал маленькие аллокейшены и аллокировал из специального пула (при чем там было множество пулов, потому что выделить один большой кусок память в мобильном BREW не всегда было возможно). Так же там была возможность напоминающая Objective-C autorelease pool - когда ты знаешь, что будешь работать с большим кол-вом мелких блоков и потом хочешь их целиком сразу из памяти выгрузить. Но в реальном мире, особенно для desktops и servers вряд ли нужно такие дженерик решения. Особенно если подключать сторонние (уже откомпилированные) библиотеки, то такое решение с переопределением new/delete работать не будет. Так что я могу, конечно, заоптимизировать свое приложение, что оно будет в большинстве случаев намного быстрее, чем аналогичный Джава код, но при этом не смогу влиять на имплементацию 3rd party кода, который будет в виде библиотек подключаться в мое приложение.

---
Тут ведь еще что самое важно, не пытаться транслировать 1:1 функциональность Джавы в C++. Например, во многих случаях мне вообще будет достаточно использовать unique_ptr вместо shared_ptr (и иметь выигрыш в скорости в раза 3).

[Komissar]

иногда я думаю, что лучше мне остаться в манагерах...

[dotcom]

Блин, ну я же уже писал, что я вполне охотно верю, что на ц++ можно путем определенных страданий достичь и даже превзойти производительность джавы. Спор был про АРК вс ГЦ.

Объсните, каким боком ваш пример иллюстрирует премущество GC над ARC? К слову, многие считают ARC частным видом GC, но эту терминологическую кашу мы оставим за кадром. Как демонстрация memory preallocation'а ваш пример подходит. В Си++ для этого никаких библиотек не надо, достаточно также аллоцировать память, как это делает JVM. Наивно полагать, что надстройка на аллокатором libc будет работать всегда лучше и оптимальнее любой другой надстройки над libc, сделанной ручками, автоматом, пулетом или согласно тезиса очередного PhD.

[Интеррапт]

иногда я думаю, что лучше мне остаться в манагерах...

Блин, вот именно. Вместо того, чтобы ломать голову, какой алгоритм даст выигрыш в несколько секунд (или миллисекунд), ты просто прикажешь рабу-программисту с этим вопросом разобраться.

[crypto5]

В Си++ для этого никаких библиотек не надо, достаточно также аллоцировать память, как это делает JVM.

Расскажите как, желательно с примерами кода.

[dotcom]

В Си++ для этого никаких библиотек не надо, достаточно также аллоцировать память, как это делает JVM.

Расскажите как, желательно с примерами кода.

MySmallChunk *mySmallChunks[COUNT];
char *myBigChunk= new char[sizeof(MySmallChunk * COUNT)]; // or whatever size > MySmallChunk * COUNT
for (int i = 0; i < COUNT; ++i) {
mySmallChunks = new(myBigChunk + sizeof(MySmallChunk) * i) MySmallChunk;
}

ЗЫ: А ответить на вопрос?

[Интеррапт]

В Си++ для этого никаких библиотек не надо, достаточно также аллоцировать память, как это делает JVM.

Расскажите как, желательно с примерами кода.

А о каких примерах идет речь? Не могу же я выложить сюда весь фреймворк, который я написал под свой аллокатор, который я уверен, намного более performant чем GC в джаве для аллокирования мелких обьектов (впрочем сходу я сравнить не могу, т.к. он использует BREW API, поэтому проверить это под десктопом я не смогу). Уверен, что мог бы спортировать на тот же iOS, но не было такой надобности.
На 100% уверен, что GC не может побить специализированные аллокаторы под C++. Но с другой стороны готов признать, что в 90% случаях это и не нужно. Чего уж там - память дешевая, процессорные ресурсы тоже.

[Интеррапт]

В Си++ для этого никаких библиотек не надо, достаточно также аллоцировать память, как это делает JVM.

Расскажите как, желательно с примерами кода.

MySmallChunk *mySmallChunks[COUNT];
char *myBigChunk= new char[sizeof(MySmallChunk * COUNT)]; // or whatever size > MySmallChunk * COUNT
for (int i = 0; i < COUNT; ++i) {
mySmallChunks = new(myBigChunk + sizeof(MySmallChunk) * i) MySmallChunk;
}

ЗЫ: А ответить на вопрос?

Во-во. Placement new Ну какой GC может быть быстрее?

[crypto5]

В Си++ для этого никаких библиотек не надо, достаточно также аллоцировать память, как это делает JVM.

Расскажите как, желательно с примерами кода.

MySmallChunk *mySmallChunks[COUNT];
char *myBigChunk= new char[sizeof(MySmallChunk * COUNT)]; // or whatever size > MySmallChunk * COUNT
for (int i = 0; i < COUNT; ++i) {
mySmallChunks = new(myBigChunk + sizeof(MySmallChunk) * i) MySmallChunk;
}

ЗЫ: А ответить на вопрос?

А потом вы напишите логику что бы отдавать и возвращать чанки, потом что бы обеспечить поддержку многопоточности, потом что бы отдавать память назад, что бы остальным частям программы хватало, и не факт что получится быстрее jvm gc.

[Интеррапт]

А потом вы напишите логику что бы отдавать и возвращать чанки, потом что бы обеспечить поддержку многопоточности, потом что бы отдавать память назад, что бы остальным частям программы хватало, и не факт что получится быстрее jvm gc.

Для generic solution - вы правы, вряд-ли получится быстрее, все-таки GC и прочие Hotspot не дураки писали. А вот для того, чтобы обеспечить оптимизацию какой-то части программы - то очень даже быстрее. Что собственно имеет смысл делать - выяснить где затыки и провести оптимизацию. И в С++ всегда возможность оптимизровать что-либо - на порядок больше чем для Java.

И грамотное использование ARC в совокупности с другими инструментами - даст намного больше производительность С++ приложения по сравнению с Java.