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

[АццкоМото]

Я считаю, нужно докинуть еще пару ноликов в iter < 100000000 и быть уверенным, что GC таки включился Хотя я слышал, что у каждого гуглера по 100 терабайт оперативки, так что и это не факт

Так тест вообще как бы не особо честный. Получается, что java vm навыделяет кучу памяти (которая у java таки довольно быстрая операция), а потом целиком весь процесс закроется похерив всю эту память и не дав GC возможности ее очистить.

Не, ну сто мульенов сто объектов таки создается, т.е. больше гигабайта. Вполне возможно, что и вызывается GC. Я почему и говорю про пару ноликов еще - хочется, чтобы он не только вызывался, а вызывался очень много раз.

[crypto5]

Я считаю, нужно докинуть еще пару ноликов в iter < 100000000 и быть уверенным, что GC таки включился Хотя я слышал, что у каждого гуглера по 100 терабайт оперативки, так что и это не факт

Так тест вообще как бы не особо честный. Получается, что java vm навыделяет кучу памяти (которая у java таки довольно быстрая операция), а потом целиком весь процесс закроется похерив всю эту память и не дав GC возможности ее очистить.

Не, ну сто мульенов сто объектов таки создается, т.е. больше гигабайта. Вполне возможно, что и вызывается GC. Я почему и говорю про пару ноликов еще - хочется, чтобы он не только вызывался, а вызывался очень много раз.

Когда появится с чем сравновать можно попробовать разные параметры, не проблема вообще.

[АццкоМото]

Когда появится с чем сравновать можно попробовать разные параметры, не проблема вообще.

Ага, я уже увидел пост про 11 включений GC и даже посчитал, сколько он наосвобождал, ну типа вдруг там какой подвох. Вроде все сходится. Остается с чем-то сравнить. Сдается мне, на этапе решения, с чем и как сравнивать и начнется весь срач

[crypto5]

Когда появится с чем сравновать можно попробовать разные параметры, не проблема вообще.

Ага, я уже увидел пост про 11 включений GC и даже посчитал, сколько он наосвобождал, ну типа вдруг там какой подвох. Вроде все сходится. Остается с чем-то сравнить. Сдается мне, на этапе решения, с чем и как сравнивать и начнется весь срач

Там есть одна проблема, делается только minor collection, который типа намного быстрее чем major, но я сколько ноликов не вставлял minor со всем справлялся. Нужно писать посложнее тест что бы забабахать major gc.

[АццкоМото]

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

[vladich]

Структуры данных очень простые тут, GC особо и не напрягается (также как и счетчики ссылок, т.к. ссылок то...). Сэмулировать бы что-нибудь более реальное, с кучей референсов друг на друга. Иначе цифры не очень релевантные, думаю аналогичный код на C++ должен это побить, если не проиграет Java по аллокации памяти.

[crypto5]

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

ГЦ не блокирует программу на 2мс.

[crypto5]

Структуры данных очень простые тут, GC особо и не напрягается (также как и счетчики ссылок, т.к. ссылок то...). Сэмулировать бы что-нибудь более реальное, с кучей референсов друг на друга. Иначе цифры не очень релевантные, думаю аналогичный код на C++ должен это побить, если не проиграет Java по аллокации памяти.

Жду предложений что нужно сделать, и аналогичного Ц++ кода тоже

[vladich]

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

ГЦ не блокирует программу на 2мс.

Full GC таки блокирует, пусть и не на все время работы.

[АццкоМото]

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

ГЦ не блокирует программу на 2мс.

А это неважно

[crypto5]

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

ГЦ не блокирует программу на 2мс.

А это неважно

А что важно?

[АццкоМото]

А что важно?

возможно, что ARC не работает по вечности за раз, тормозя все остальное

[crypto5]

А что важно?

возможно, что ARC не работает по вечности за раз, тормозя все остальное

Ну я не настаиваю в юзании штатного GC без object pools и off heap caches в критичных по latency приложениях

[vladich]

В некоторых инвестбанках используют zero GC Java код. Вся память или off heap или на примитивных типах.
Так что если _очень_очень_хочется, то это не проблема .

[dotcom]

Ну так при желании Жабу можно в нативный код скомпилировать и подцепить libc. Есть и такие извращенцы.

[crypto5]

Области интересов не совпадают.

Ничего страшного. Я ради дружбы могу и в Жабу податься и в ее замечательные фреймворки.

Как насчет scala, cassandra, big data, machine learning? ))

[dotcom]

Области интересов не совпадают.

Ничего страшного. Я ради дружбы могу и в Жабу податься и в ее замечательные фреймворки.

Как насчет scala, cassandra, big data, machine learning? ))

Scala - уже в процессе. ML и Big Data пока заброшены. Но ради дружбы, готов и их открыть.

[crypto5]

Продолжим реалити шоу.
Раз смельчаков не нашлось, пришлось самому стряхнуть пыль с знаний изобретения Мертвой Птицы.

Что бы еще больше подтасовать результаты уменьшить влияние раскочегаривания jvm на результат я увеличил количество итераций до миллиарда.
Получилось вот что:

Code: Select all

#include<memory>

int COUNT = 100;

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

typedef std::shared_ptr<Data> DataPtr;

int main() {
  DataPtr data[COUNT];
  for(int i = 0; i < COUNT; i ++) data[i] = DataPtr(new Data(i));
  auto curr = data[0];
  for(long i = 0; i < 1000000000; i ++) {
    int next_index = (curr -> payload + 1) % COUNT;
    auto next_node = data[next_index];
    data[next_index] = DataPtr(new Data((curr->payload + next_node->payload + 1) % COUNT));
    curr = next_node;
  }
}

#g++ -std=c++0x -O3 arc_test.cpp
#time ./a.out
real	1m22.769s
user	1m22.730s
sys	0m0.010s

#javac GCTest.java
#time java -server GCTest
real	0m20.338s
user	0m20.220s
sys	0m0.260s

Отставание в безобразные 4 раза. Как востановить справедливость?

[АццкоМото]

да хренотень какая-то. сколько там занял GC за одинадцать пришествий в джавовском примере? менее 0.002 секунды в примере в 10 раз короче, так вроде? Т.е. в этом примере он должен был занять 0.02 секунды, плюс-минус подоходный. А разница во времени исполнения - минута. Т.е. если вся разница обусловлена выделением и освобождением памяти, оно должно различаться в 3000 раз. ТРИ ТЫСЯЧИ.
Дело было не в бобине, однозначно. Какой-то другой фактор играет роль

[АццкоМото]

кстати, а у вас, чисто случайно, не 4х ядерный процессор? я хрен его знает, конечно, как там джава может что соптимизировать, но как-то разница в 4 раза символизирует

[crypto5]

да хренотень какая-то. сколько там занял GC за одинадцать пришествий в джавовском примере? менее 0.002 секунды в примере в 10 раз короче, так вроде? Т.е. в этом примере он должен был занять 0.02 секунды, плюс-минус подоходный. А разница во времени исполнения - минута.

ГЦ это только освобождение памяти, а еще есть выделение.

Т.е. если вся разница обусловлена выделением и освобождением памяти, оно должно различаться в 3000 раз. ТРИ ТЫСЯЧИ.
Дело было не в бобине, однозначно. Какой-то другой фактор играет роль

У товарищей с окамлом такая же фигня случилась, они поменяли malloc на shared_ptr, и программа замедлилась в 10 раз.

[crypto5]

кстати, а у вас, чисто случайно, не 4х ядерный процессор? я хрен его знает, конечно, как там джава может что соптимизировать, но как-то разница в 4 раза символизирует

Ядер наверное 4 или 2 )) ГЦ понятно в параллеьном потоке запускается, остальное вряд ли.

[Интеррапт]

Отставание в безобразные 4 раза. Как востановить справедливость?

Легким движением руки отставание уменьшается в 2 раза (протестировано под Маком в XCode). Ну и сравнивал с вашим первоначальным вариантом Джава версии (c 100000000 итераций):

Code: Select all

#include <iostream>

class Data
{
public:
    int payload;
    Data() : payload(0) {
    }
    Data(int value) : payload(value) {
    }
};

typedef std::shared_ptr<const Data> data_ptr;

int main(int argc, const char * argv[])
{
    const int COUNT = 100;
    
    data_ptr data[COUNT];
    for (int i = 0; i < COUNT; i++) {
        data[i] = std::make_shared<Data>(i);
    }

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

    return 0;
}

Ваш Джава код у меня выполнялся 3 сек, ваш С++ код - 21 секунду, мой С++ код - 6 секунд. Отставание в два раза есть, это правда.

Что бы еще больше подтасовать результаты уменьшить влияние раскочегаривания jvm на результат я увеличил количество итераций до миллиарда.

Не думаю, что увеличив число итераций - вы чего-то добились. Слишком уж простой тест для Джавы. Вообще на самом деле вы почему-то выбрали самое простое задание, с которым Джава действительно лучше справляется - обычная и очень простая аллокация памяти. Потому как new/delete у C++ - более дорогостоящая операция, чем аллокация памяти у Джавы (как бы понятно почему). Фактически С++ поэтому в данном тесте и проигрывает по скорости (при этом имея более детерминированное освобождение памяти, т.к. освобождение памяти и вызов деструктора происходит сразу же, как обьект вышел и области видимости в итерации цикла). Но вот если мы добавим custom allocator (или object pool), при котором new будет брать память уже из заранее выделенного участка памяти - то ес-но перфоманс у С++ будет выше.

В этом собствено и штука, в Java вы можете оптимизировать только до какого-то определенного предела. А в C++ возможностей для оптимизации несравненно больше.

[АццкоМото]

Ваш Джава код у меня выполнялся 3 сек, ваш С++ код - 21 секунду, мой С++ код - 6 секунд. Отставание в два раза есть, это правда.

И все-таки. Чегойта у crypto5 разница во времени практически ровно в 4 раза, а у тебя - в 7? При том, что GC занимает доли процента а все, кроме управления памятью, в джаве и сях должно быть примерно равнозначно?
Может, у него, например, 4 честных ядра, а у тебя - 4 ядра с hyperthreading, что почти как 8, но меньше, 7.
Ну честно, не верю я в такие странности. Да, new/delete могут быть дороже, но не в тысячи же раз
Да, я понятия не имею, как далеко может зайти оптимизация в джаве. Возможно, она даже теоретически не может сама раскидать задачу по ядрам, да и сама задача не так чтобы легко раскидывалась. Но уж очень цифры круглые и разница у вас большая в результатах

[crypto5]

Отставание в безобразные 4 раза. Как востановить справедливость?

Легким движением руки отставание уменьшается в 2 раза (протестировано под Маком в XCode).

А помоему вы легким движением руки зачитили, переписав абсолютно безопасный код в небезопасный. Будь там алгоритм по сложнее и у вас уже появляется неилюзорная возможность получить в current указатель на удаленный обьект с последующим segmentation fault. Смысл тогда shared_ptr вообще юзать?

Не думаю, что увеличив число итераций - вы чего-то добились.

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

Фактически С++ поэтому в данном тесте и проигрывает по скорости (при этом имея более детерминированное освобождение памяти, т.к. освобождение памяти и вызов деструктора происходит сразу же, как обьект вышел и области видимости в итерации цикла).

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

Но вот если мы добавим custom allocator (или object pool), при котором new будет брать память уже из заранее выделенного участка памяти - то ес-но перфоманс у С++ будет выше.

Давайте код, не будьте голословны ))

В этом собствено и штука, в Java вы можете оптимизировать только до какого-то определенного предела. А в C++ возможностей для оптимизации несравненно больше.

Я с этим не спорю, я возбудился исключительно на ваше заявление что ARC производительней чем GC.