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

[dotcom]

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

Причем тут многопоточность и чего хватало? Сделать аллокатор thread-safe - не Бином Ньютона. Даже параллельную аллокацию можно сделать при желании. Вы бы лучше вместо демагогии на конкретный и простой вопрос ответили бы. И как вы сами писали, мы вобще про GC спорили, а не про аллокацию. Аллокацию каждый дурак сделает.

[crypto5]

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

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

Это все вода, вам тут нужно какой то код на коленках писать, а аналогичный object pool в джаве вставляется одной строчкой в maven и используется двумя методами, является thread safe, эластичным и т.д., это еще к тому почему джава заруливает Ц++.

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

Давайде дождемся кода уже ))

[crypto5]

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

Причем тут многопоточность и чего хватало? Сделать аллокатор thread-safe - не Бином Ньютона. Даже параллельную аллокацию можно сделать при желании. Вы бы лучше вместо демагогии на конкретный и простой вопрос ответили бы. И как вы сами писали, мы вобще про GC спорили, а не про аллокацию. Аллокацию каждый дурак сделает.

Аллокацию может каждый и дурак, а вот быструю и надежную уже бином Ньютона.

простой вопрос ответили бы

какой вопрос?

[Интеррапт]

Давайде дождемся кода уже ))

Может все-таки задачку подкините. Ну вот типа тут у вас такой алгоритм со всяким выделением памяти. И его нужно переписать на С++ быстрее. Без всяких условий, что мол нет, нельзя использовать references и т.п.

[crypto5]

Давайде дождемся кода уже ))

Может все-таки задачку подкините. Ну вот типа тут у вас такой алгоритм со всяким выделением памяти. И его нужно переписать на С++ быстрее. Без всяких условий, что мол нет, нельзя использовать references и т.п.

Ну может хоть этот доведем до победного конца, что бы был ARC и object pool пусть даже с референсами? А то я как то слабо пока представляю как можно их легко пересечь. А то ж ц++ сливает пока.

[АццкоМото]

Изначальный код Крипто (со 100 млн операций) у меня выполнялся 3 секунды. А у него 2.

И его же код нетронутый на С++ исполнялся 21 секунду, верно понял?

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

Ну и вот. На одном и том же коде у Крипто получилась разница почти ровно в 4 раза, а у тебя - в 7. Как мы это объясним, просто различиями компиляторов/виртуалок/операционок? Или есть объяснение попроще?

[crypto5]

Кстати расставление final везде в джава версии тоже дает 25% прирост в производительности:

Code: Select all

public class GCTestFinal {
  public static void main(String args[]) {
    final int COUNT = 100;
    // init
    final Data data[] = new Data[COUNT];
    for(int i = 0; i < COUNT; i ++) data[i] = new Data(i);
    Data current = data[0];
    // process
    for(long iter = 0; iter < 1000000000; iter ++) {
      final int nextIndex = (current.payload + 1) % COUNT;
      final Data newNode = data[nextIndex];
      data[nextIndex] = new Data((current.payload + newNode.payload + 1) % COUNT);
      current = newNode;
    }
  }
  
  static class Data {
    public final int payload;
    
    Data(int payload) {
      this.payload = payload;
    }
  }
}

$javac GCTest.java 
$ time java -server GCTest

real	0m19.423s
user	0m19.490s
sys	0m0.210s
$ javac GCTestFinal.java 
$ time java -server GCTestFinal

real	0m14.653s
user	0m14.660s
sys	0m0.210s

Задача Интеррапта становится сложнее

[dotcom]

какой вопрос?

Объсните, каким боком ваш пример иллюстрирует премущество GC над ARC?

[crypto5]

какой вопрос?

Объсните, каким боком ваш пример иллюстрирует премущество GC над ARC?

Если вам или Интеррапту удастся прикрутить пул обьектов к shared_ptr, то этот пример наглядно проилюстрирует производительность ARC vs GC.
Пока вам этого не удалось получается что он действительно илюструрует ARC+malloc vs GC, но опять же пока вам это не удалось другого варианта использовать ARC пока что не видно, и это вполне недостаток ARC.

[dotcom]

[
Если вам или Интеррапту удастся прикрутить пул обьектов к shared_ptr, то этот пример наглядно проилюстрирует производительность ARC vs GC.
Пока вам этого не удалось получается что он действительно илюструрует ARC+malloc vs GC, но опять же пока вам это не удалось другого варианта использовать ARC пока что не видно, и это вполне недостаток ARC.

Опять скачем и извиваемся. Или вы разницу между Garbage Collection и Memory Allocation не знаете или не хотите замечать. Что касательно shared_ptr , я тоже не особо понимаю, каким боком они тут. Когда ужна производительность memory allocator'а на большом кол-ве мелких объектов, то применять shared_ptr для этого, - плохая идея. И это тут уже вам объяснили. Вы же с упорством достойного лучшего применения твердите одну и ту же карму. Если нужны reference counters, то memory management импелментируется не стандартной библиотекой. Кстати, если вы думаете, что подобное нужно только в высокопроизводительных системах, то вы ошибаетесь. Например, в Adobe есть свой менджер и своя библиотека для десктопных приложений. Да, для картинок тоже нужно активно манипулировать памятью, и на Жабе это никто не делает. Где-то в это разделе я уже приводил разницу в производительности OpenCV алгоритмов на Жабе и Си++. Под рукой цифр нет, но можно и ветку раскоптаь. И главный поинт про то, что JVM делает сбор мусора в непредсказуемый моменты, блокирую приложение, что даже заметно на десктопных приложениях, в том время как в нативных языках это контролируется программистом, - вы это игнорируете. Продолжайте в том же духе... Жаба - ваше все!

[crypto5]

[
Если вам или Интеррапту удастся прикрутить пул обьектов к shared_ptr, то этот пример наглядно проилюстрирует производительность ARC vs GC.
Пока вам этого не удалось получается что он действительно илюструрует ARC+malloc vs GC, но опять же пока вам это не удалось другого варианта использовать ARC пока что не видно, и это вполне недостаток ARC.

Опять скачем и извиваемся. ... Жаба - ваше все!

Скачете и извиваетесь вы зачем то, здесь тестируется всего лишь одна гипотеза - является ли ARC производительней GC, так что вся ваша критика - мимо кассы.

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

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

[АццкоМото]

Трудно не признать, что crypto5, с которым я не согласен, пока побеждает :):)
Пойду-ка я в ближайший пуб, накиньте еще попкорна, чтобы стало повеселее, а?

[Интеррапт]

Трудно не признать, что crypto5, с которым я не согласен, пока побеждает :):)
Пойду-ка я в ближайший пуб, накиньте еще попкорна, чтобы стало повеселее, а?

Скорее всего именно в данном простом случае - да Но война еще не окончена (попробуем с пулом).
Я дизассемблиовал джава код (именно в ассемблер) - hotspot неплохо соптимизировал данный тест. current = newNode присваивание вообще ушло (т.е. нет как отдельного присваивания - нужно посмотреть, возможно на регистр уехало). С++ похуже оптимизировал - он именно честно вызывает весь код. По большому счету тестик так себе, так как то, что JIT умеет не слишком сложные случае хорошо разруливать (особенно всякие циклы) - это хорошо известно. По хорошему С++ нужно было бы с поинтерами переписать, т.к. по большому счету это то, что hotspot сделал

Code: Select all

    boost::object_pool<Data> pool(sizeof(Data) * COUNT);
    Data* data[COUNT];
    for (int i = 0; i < COUNT; i++) {
        data[i] = pool.construct(i);
    }

    Data* current = data[0];
    Data nodeMem;
    for(long iter = 0; iter < 100000000; iter ++) {
        const int nextIndex = (current->payload + 1) % COUNT;
        nodeMem = *data[nextIndex];
        pool.destroy(data[nextIndex]);
        data[nextIndex] = pool.construct((current->payload + nodeMem.payload + 1) % COUNT);
        current = &nodeMem;
    }

меньше 1-й секунды

[crypto5]

Осталось узнать где тут ARC?

[dotcom]

Скачете и извиваетесь вы зачем то, здесь тестируется всего лишь одна гипотеза - является ли ARC производительней GC, так что вся ваша критика - мимо кассы.

Начнем с вам. С уроков чтения. Что обозначает слово "collection" в словосочетании Garbage Collection? Второй урок пока отложим.

ЗЫ: На мой вопрос вы так и не ответили.

[crypto5]

Скачете и извиваетесь вы зачем то, здесь тестируется всего лишь одна гипотеза - является ли ARC производительней GC, так что вся ваша критика - мимо кассы.

Начнем с вам. С уроков чтения. Что обозначает слово "collection" в словосочетании Garbage Collection? Второй урок пока отложим.

И закончим. Уроки пожалуйста читайте своим детям дома.

[dotcom]

И закончим. Уроки пожалуйста читайте своим детям дома.

У вас замечательный талант писать про что угодно, но только не по теме разговора.

[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++ со статической линковкой даст несколько лучший результат.

[АццкоМото]

меньше 1-й секунды

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

[Medium-rare]

Пример внизу - малонужная ерундистика. Такое количество объектов в C++ выделяется либо векторами, либо в уже выделенные большие массивы памяти при помощи in-place new, если не хватает непрерывного куска памяти, то вполне можно оперировать блоками. Не зачем так дёшево терять преимущество производительности, а сравнение притянуто к тому, как это привыкли делать в Java.

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

Что бы еще больше подтасовать результаты уменьшить влияние раскочегаривания 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 раза. Как востановить справедливость?

[crypto5]

Пример внизу - малонужная ерундистика. Такое количество объектов в C++ выделяется либо векторами, либо в уже выделенные большие массивы памяти при помощи in-place new, если не хватает непрерывного куска памяти, то вполне можно оперировать блоками. Не зачем так дёшево терять преимущество производительности, а сравнение притянуто к тому, как это привыкли делать в Java.

Спор возник вокруг ARC vs GC, у вас есть представление как прикрутить пул обьектов, массивы или что угодно к shared_ptr?

[Medium-rare]

Спор возник вокруг ARC vs GC, у вас есть представление как прикрутить пул обьектов, массивы или что угодно к shared_ptr?

shared_ptr это удобство и безопасность, а не производительность. Использовать shared_ptr для крутой производительности с миллионами объектов начинать не буду. Нарисовать, как inplace new сожрёт это всё? Это нужно?

P.S. Как сравнение ARC vs GC превратилось в то, во что превратилось, я пропустил.

[crypto5]

Спор возник вокруг ARC vs GC, у вас есть представление как прикрутить пул обьектов, массивы или что угодно к shared_ptr?

shared_ptr это удобство и безопасность, а не производительность. Использовать shared_ptr для крутой производительности с миллионами объектов начинать не буду. Нарисовать, как inplace new сожрёт это всё? Это нужно?

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

[Medium-rare]

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

Я пытаюсь сказать, что использование shared_ptr во весь рост ничего не замедляет само по себе, скажем, против явного освобождения пойнтера, там оверхед минимальный. На кой чёрт миллионам однотипных объектов отдельные хендлы? У них и life-cycle индивидуальные?