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

[crypto5]

Замечательно, вы на моей стороне, Интеррапт говорит и АццкоМотто сомневается в том же направлении что это еще и производительность(по сравнению с джава)

Я пытаюсь сказать, что во весь рост использование shared_ptr ничего не замедляет самj по себе, скажем, против явного освобождения пойнтера, там оверхед минимальный.

Тут есть два аспекта:
- во первых очевидно замедляют, не совсем понятно насколько правда
- если shared_ptr нельзя юзать без malloc на каждый раз, то это понятно их большой недостаток, без разницы насколько они эфективны сами по себе

На кой чёрт миллионам однотипных объектов отдельные хендлы? У них и life-cycle индивидуальные?

Это микробенчмарк, тестирующий один аспект(удаление освобождение памяти), алгоритм можно легко переписать что-бы вообще не выделять память на каждой итерации

[Medium-rare]

Code: Select all

class Data {
  public:
    int payload;
    Data(int _payload) : payload(_payload) {}
};

Это не жизненный пример данных, которые висят на shared_ptr. Реальные refcounted объекты в один int? Да в куче выделится в разы больше, как минимальный блок. Потому оверхед неестественен в сравнении с полезной нагрузкой. Раз.

Инкремент/декремент счётчика просто ничто против создания/уничтожения объетов. Два.

Из два выходит три, наличие в языке стандартного shared_ptr позволяет программировать проще, при том, зачастую (очень часто) и код быстрее. Не могу пересчитать в старом C++ коде, сколько раз якобы незначительные объекты копируются, а мотивация простая: сферы ответственности разных классов/ модулей. Я не лезу освобождать "твою" память, ты не лезешь освобождать "мою", такой подход в прошлом. Три.

Что за профанация shared_ptr, чтобы натянуть его на некоторый pattern, как можно легче программировать в Java? Ну легче, да.

[crypto5]

Code: Select all

class Data {
  public:
    int payload;
    Data(int _payload) : payload(_payload) {}
};

Это не жизненный пример данных, которые висят на shared_ptr. Реальные refcounted объекты в один int? Да в куче выделится в разы больше, как минимальный блок. Потому оверхед неестественен в сравнении с полезной нагрузкой. Раз.

Инкремент/декремент счётчика просто ничто против создания/уничтожения объетов. Два.

Из два выходит три, наличие в языке стандартного shared_ptr позволяет программировать проще, при том, зачастую и быстрее. Не могу пересчитать в старом C++ коде, сколько раз якобы незначительные объекты копируются, а мотивация простая: сферы ответственности разных классов/ модулей. Я не лезу освобождать "твою" память, ты не лезешь освобождать "мою". Три.

Что за профанация shared_ptr, чтобы натянуть его на некоторый pattern, как можно легче программировать в Java? Ну легче, да.

Давайте ваш тест, я есго запрограммирую на джава, вы на с++.

[АццкоМото]

АццкоМотто сомневается в том же направлении

АццкоМото не определился. Пока вы выглядете убедительней, значительно. Но каким образом GC оказывается в 3000 раз эффективнее ARC (при определенных предположениях) я не могу осознать и вы старательно обходите стороной этот вопрос

[Medium-rare]

Давайте ваш тест, я есго запрограммирую на джава, вы на с++.

In-place new? Это возможно в Java?

[crypto5]

АццкоМотто сомневается в том же направлении

АццкоМото не определился. Пока вы выглядете убедительней, значительно. Но каким образом GC оказывается в 3000 раз эффективнее ARC (при определенных предположениях) я не могу осознать и вы старательно обходите стороной этот вопрос

Я же писал, что 3000 раз это время удаления обьектов, а есть еще время их создания.
И вообще откуда 3000 взялось?
На 100млн итераций GC делался 11 раз по 1мс, в сумме это 11мс, вариант Интеррапт выполнялся 6сек, т.е. разница с GC и полной программой 500 раз где то.

[crypto5]

Давайте ваш тест, я есго запрограммирую на джава, вы на с++.

In-place new? Это возможно в Java?

Если вы сделаете тест с shared_ptr то будет справедливо померятся. Ну и в джаве тоже есть всякие пулы обьектов, правда в доках пишут что GC нынче настолько шустр что они не добавляют производительности.

[Medium-rare]

Если вы сделаете тест с shared_ptr то будет справедливо померятся. Ну и в джаве тоже есть всякие пулы обьектов, правда в доках пишут что GC нынче настолько шустр что они не добавляют производительности.

На него отдельный malloc, или что похитрее? Сейчас почитаю, есть ли смысл в том. Я же предалагал in-place new на сами отдельные объекты.

[crypto5]

Если вы сделаете тест с shared_ptr то будет справедливо померятся. Ну и в джаве тоже есть всякие пулы обьектов, правда в доках пишут что GC нынче настолько шустр что они не добавляют производительности.

На него отдельный malloc, или что похитрее? Сейчас почитаю, есть ли смысл в том. Я же предалагал in-place new на сами отдельные объекты.

Можете похитрее ))
in-place new тоже можно померятся, но это уже другая тема.

[Medium-rare]

Можете похитрее ))
in-place new тоже можно померятся, но это уже другая тема.

When shared_ptr is created by calling std::make_shared or std::allocate_shared, the memory for both the control block and the managed object is created with a single allocation. The managed object is constructed in-place in a data member of the control block. When shared_ptr is created via one of the shared_ptr constructors, the managed object and the control block must be allocated separately. In this case, the control block stores a pointer to the managed object.

Надо так. И выделять сам объект в пуле in place. Чем потихоньку займусь, по другому, это натягивание Java на C++ с каким-то извращённом умыслом. Dot com был близок, посмотрел взад.

[crypto5]

Можете похитрее ))
in-place new тоже можно померятся, но это уже другая тема.

When shared_ptr is created by calling std::make_shared or std::allocate_shared, the memory for both the control block and the managed object is created with a single allocation. The managed object is constructed in-place in a data member of the control block. When shared_ptr is created via one of the shared_ptr constructors, the managed object and the control block must be allocated separately. In this case, the control block stores a pointer to the managed object.

Надо так. И выделять сам объект в пуле in place. Чем потихоньку займусь, по другому, это натягивание Java на C++ с каким-то извращённом умыслом.

Интеррапт уже заюзал make_shared выше, я не знал про эту штуку когда писал свой код.

[АццкоМото]

Я же писал, что 3000 раз это время удаления обьектов, а есть еще время их создания.

Возможно, я что-то пропустил, ибо этого не помню.

И вообще откуда 3000 взялось?
На 100млн итераций GC делался 11 раз по 1мс, в сумме это 11мс, вариант Интеррапт выполнялся 6сек, т.е. разница с GC и полной программой 500 раз где то.

Ну как же. Теоретически, все в джаве должно работать приерно с той же скоростью, что и в плюсах. Верно? Кроме пойнта зарубы - GC vs ARC. Вы пишете, что ваш тест на джаве, самый изначальный, выполнялся 2 секунды, а на сях в 4 раза дольше. При этом из двух секунд GC работал 11 миллисекунд. Стало быть, ARC работал 6 секунд и 11 миллисекунд. Разница - почти в 6000 раз
(в первый раз я, кажется, оценивал время выполнения одиннадцати коллекшенов в 20 миллисекунд, отсюда и разночтение 3000 или 6000 раз)

[Medium-rare]

Интеррапт уже заюзал make_shared выше, я не знал про эту штуку когда писал свой код.

А ДотКом уже использовал в примере in place, только прочёл. Нужен in place + allocate_shared. Тогда не будет миллионов malloc. allocate_shared с кастомным аллокатором. Задача сама по себе идиотская, так не делают на практике, но интересно.

[АццкоМото]

crypto5
или если по-другому зайти. С++ стало быть 75% времени потратил на мемори менеджмент. а джава - 0.05-0.1%
Ну не странно ли. Ладно бы победила, но с таким перекосом????

[Интеррапт]

Ну как же. Теоретически, все в джаве должно работать приерно с той же скоростью, что и в плюсах. Верно? Кроме пойнта зарубы - GC vs ARC.

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

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

Под Андроидом бы надобно сравнить, насколько хорошо Dalvik справляется и оптимизирует.

[АццкоМото]

Ну как же. Теоретически, все в джаве должно работать приерно с той же скоростью, что и в плюсах. Верно? Кроме пойнта зарубы - GC vs ARC.

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

Это пойнт, да
Вот только с философской точки зрения я сей феномен не могу осознать никак. Слишком много надо букв, чтобы объяснить мое смущение.
Есть даже ощущение, что пора валить из профессии. У меня разрываются шаблоны, а мне лень даже проверить самому. Дожился

[Интеррапт]

Кстати, попробовал с tbb аллокатором, разница заметная получилась (в несколько секунд):

Code: Select all

    tbb::scalable_allocator<Data> sa;
    data_ptr data[COUNT];
    for (int i = 0; i < COUNT; i++) {
        data[i] = std::allocate_shared<Data>(sa, i);
    }

    data_ptr& current = data[0];
    for(long iter = 0; iter < 100000000; iter ++) {
        const int nextIndex = (current->payload + 1) % COUNT;
        const data_ptr& newNode = data[nextIndex];
        data[nextIndex] = std::allocate_shared<Data>(sa, (current->payload + newNode->payload + 1) % COUNT);
        current = newNode;
    }

итого спустились до 4.5 секунд

[crypto5]

итого спустились до 4.5 секунд

Пару минут назад было 5, так глядишь ц++ скоро джаву и обгонит!

[crypto5]

Я попробовал исходный пример с аллокатором от Threading building blocks.
В код добавилось
#include "tbb\scalable_allocator.h"

void* operator new (size_t size) throw (std::bad_alloc) {
if (size == 0) size=1;
if(void *ptr = scalable_malloc(size)) return ptr;
throw std::bad_alloc();
}
void operator delete (void *ptr) throw() {
if(ptr != 0) scalable_free(ptr);
}
Пример без аллокатора на моем компе отработал за 19 секунд, с аллокатором за 12. Для быстроты слепил оба примера под VS и с динамической линковкой (библиотека уже имелась) так что оценки весьма условные. Наверняка gcc++ со статической линковкой даст несколько лучший результат.

Чисто интересно, а что именно этот алокатор делает? Я не нашел в интернете нормального описания.

[Интеррапт]

итого спустились до 4.5 секунд

Пару минут назад было 5, так глядишь ц++ скоро джаву и обгонит!

Я грубо округлил в первый раз, потом еще раз замерял - 4.6 секунды. Округлил до 4.5
Но думается мне, что это максимум - затык дальше идет в копировании shared_ptr
Дальше нужно только при помощи того же Intel Threading Building Blocks распаралеливать

[Интеррапт]

shared_ptr еще и thread-safe, что тоже добавляет оверхеда. Теоретически, можно было бы написать однопоточную версию.

[Мальчик-Одуванчик]

осталось только переопределить функции operator new и operator delete для самого класса и не брать памяит из кучи

[Интеррапт]

осталось только переопределить функции operator new и operator delete для самого класса и не брать памяит из кучи

Но все-равно все это в конце концов упрется в то, что shared_ptr все-таки медленоват.

[crypto5]

shared_ptr еще и thread-safe, что тоже добавляет оверхеда. Теоретически, можно было бы написать однопоточную версию.

ГЦ тоже вроде как потокобезопасный, так что все в равных условиях

[Интеррапт]

shared_ptr еще и thread-safe, что тоже добавляет оверхеда. Теоретически, можно было бы написать однопоточную версию.

ГЦ тоже вроде как потокобезопасный, так что все в равных условиях

Правильно, только ГЦ скорее всего заоптимизирует, а вот C++ нужно все подсказывать.