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

[crypto5]

Хочу повторить, что постановка задачи изначально абсурдная, но интересовали детали имплементации.

А в чем именно абсурдность?

[Medium-rare]

На GCC выдает ошибку (КМК вполне правильную) на этой строчке
data = reinterpret_cast<data_pptr>( &std::allocate_shared<Data, myallocator<data_ptr>>( MyAllocator, i ) );

Taking the address of a temporary object of type 'typename enable_if<!is_array<Data>::value, shared_ptr<Data> >::type' (aka 'std::__1::shared_ptr<Data>')

Правда я уже приводил код, который использует boost и меньше 1-й секунды отрабатывает.

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;
    }

После этого упражнения, я больше поверю GCC. Но где в приведёном коде работает shared_ptr? Что выделяется через boost::object_pool, то видно. Надо ведь заставить объект типа shared_ptr<T> отрабатывать присвоение.

Мне подумалось, что так или так можно исправить ошибку GCC:

auto ref = *data[nextIndex];
ref = std::allocate_shared<Data, myallocator<data_ptr>>(MyAllocator, ((*current)->payload + (*newNode)->payload + 1) % COUNT);

Хотя это покажет на проблему (?).

[Medium-rare]

А в чем именно абсурдность?

shared_ptr не для того. Я уже перечислил все аргументы. Ещё: это указатель для маршаллинга данных между логически изолироваными компонентами/классами. 100 миллионов случайных присвоений на решето из 100 никто с ним не делает. Абсолютно не практично, не показывает ничего ни про что. Что Java другой язык, и приёмы программирования в нём необязательно совпадают, кто бы спорил, я не буду. Что через shared_ptr на работе передаются какие-то тяжёленькие объекты, с массой внутренних пойнтеров, а не int в struct, то данность. Да целый тип в C++ дешевле всего по значению передавать, там даже передача через простой указатель, не refcounted, и то не всегда оправдана, когда заботятся о скорости. На фига попу боян?

[Интеррапт]

Но где в приведёном коде работает shared_ptr? Что выделяется через boost::object_pool, то видно. Надо ведь заставить объект типа shared_ptr<T> отрабатывать присвоение.

Ну так о чем и речь. Уж если писать с кодом, где есть указатели, то уже проще все переписать. Например, ваша переменная current потенциально может указывать на уже освобожденный участок кода, т.к. присваивание чего-либо этой самой current не ведет к увеличению reference counter. А если попробовать current использовать по правильному, ну т.е.
data_ptr current = data[0];
(без указателя и потом ес-но в цикле без указателя), то тогда это прилично докидывает время к исполнению кода.


Ну и кажется мне, что это присваивание у вас не правильное:

Code: Select all

[1]      data_ptr* newNode = data[nextIndex];
[2]      // Yes, here we have shared_ptr working *data[nextIndex] is shared_ptr  by val
[3]      *data[nextIndex] = std::allocate_shared<Data, myallocator<data_ptr>>(MyAllocator, ((*current)->payload + (*newNode)->payload + 1) % COUNT);
[4]      current = newNode;

потому что newNode на строке 4, вместо того, чтобы указывать на старое значение data[nextIndex] (которое было на строке 1), начнет ссылаться на новое значение (которое появилось в строке 3) и теряется смысл "упражнения", т.к. вся фишка в том, чтобы current продолжало ссылаться на предидущее значение data[nextIndex]. Т.е. нужно сохранять копию Data в строке 1, чтобы потом ее присваивать в строке 4. А это все время добавляет.

Т.е. не будет работать аналогично изначальному Джава коду

Code: Select all

      final Data newNode = data[nextIndex];
      data[nextIndex] = new Data((current.payload + newNode.payload + 1) % COUNT);
      current = newNode;

[Medium-rare]

Ха, да, подправим, но теперь радикальных изменений в милисекундах вряд ли будет, компилятор внутри применённых тимплейтов пошарит, и соптимизирует. В общем, джависты на данном примере видят, что проведя генную инженерию над shared_ptr C++ способен достичь их скорости. :-p

[crypto5]

А в чем именно абсурдность?

На фига попу боян?

Что бы не парится о утечках и segmentation fault-ах а сосредоточится на алгоритмах как это делают джава программисты

[Интеррапт]

Что бы не парится о утечках

Ага, конечно. Никогда о ClassLoader ликах не слыхали? Причину которых и найти сложно, а чтобы починить в большом коде - иной раз можно умом тронуться

[Medium-rare]

Что бы не парится о утечках и segmentation fault-ах а сосредоточится на алгоритмах как это делают джава программисты

Я соглашусь, на Java и C# чуть-чуть пописал, а с хорошей процедурой и инструментами (!) в C++ не так много "радостей", как segmentation fault. Все опасные приёмы должны локализироваться, желательно в пределах функции, внутренние приёмы безопасности, как unique_ptr, ничего не отдавать наружу без предосторожностей, как shared_ptr. C++ 11 только что сделал жизнь немного проще.

[crypto5]

Что бы не парится о утечках

Ага, конечно. Никогда о ClassLoader ликах не слыхали? Причину которых и найти сложно, а чтобы починить в большом коде - иной раз можно умом тронуться

Не, ничего не знаю, даже не в курсе что там за механизм лика.

[Интеррапт]

Что бы не парится о утечках

Ага, конечно. Никогда о ClassLoader ликах не слыхали? Причину которых и найти сложно, а чтобы починить в большом коде - иной раз можно умом тронуться

Не, ничего не знаю, даже не в курсе что там за механизм лика.

Вот примерчик:
http://frankkieviet.blogspot.com/2006/1 ... space.html
(не смотрите, что статья старая, толком ничего не поменялось, случается сплошь и рядом).

вот кой-какое обсуждение
http://stackoverflow.com/questions/6470 ... -with-java

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

[crypto5]

Что бы не парится о утечках

Ага, конечно. Никогда о ClassLoader ликах не слыхали? Причину которых и найти сложно, а чтобы починить в большом коде - иной раз можно умом тронуться

Не, ничего не знаю, даже не в курсе что там за механизм лика.

Вот примерчик:
http://frankkieviet.blogspot.com/2006/1 ... space.html
(не смотрите, что статья старая, толком ничего не поменялось, случается сплошь и рядом).

вот кой-какое обсуждение
http://stackoverflow.com/questions/6470 ... -with-java

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

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

[Интеррапт]

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

Что не отменяет memory leaks.
И вообще это один из примеров. А иной раз Джава просто очень серьезно отжирает память и сходу даже не всегда понятно почему. Мне вот этот примерчик нравится

Code: Select all

class Stringer {
    static final int MB = 1024*512;
	static String createLongString(int length){
	    StringBuilder sb = new StringBuilder(length);
	    for(int i=0; i < length; i++)
	    	sb.append('a');
	    sb.append(System.nanoTime());
	    return sb.toString();
	}
	public static void main(String[] args) {
	    List substrings = new ArrayList();
	    for(int i=0; i< 100; i++) {
	    	String longStr = createLongString(MB);
	    	String subStr = longStr.substring(1,10);
	    	substrings.add(subStr);
	    }
	}
}

казалось бы, все нормально, на выходе в subtrings списке будет с пару килобайт. А оказывается, что с сотню мегабайт будет хранится в substrins. Вроде только совсем недавно в Java 7 это починили. Ес-но это не вина JVM сама по себе, но уж точно к Джаве относится. А всяких таких подлостей еще очень много

[crypto5]

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

Что не отменяет memory leaks.

А как именно не отменяет?

казалось бы, все нормально, на выходе в subtrings списке будет с пару килобайт.

Ну это же не мемори лик уже.

Ну и что мне нравится в джаве, это что все эти проблемы очень просто отдебажить. Например у меня во всех джобах есть пара флагов, которые заставляют jvm скидывать мемори дамп на диск по OutOfMemory exception, потом он непринужденно загружается в jvisualvm в которой очень просто отследить почему происходит лик.

[Сабина]

Что бы не парится о утечках

Ага, конечно. Никогда о ClassLoader ликах не слыхали? Причину которых и найти сложно, а чтобы починить в большом коде - иной раз можно умом тронуться

Дайте линков мы изучим

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

Ха, да, подправим, но теперь радикальных изменений в милисекундах вряд ли будет, компилятор внутри применённых тимплейтов пошарит, и соптимизирует. В общем, джависты на данном примере видят, что проведя генную инженерию над shared_ptr C++ способен достичь их скорости. :-p

Спасибо за приведенный пример - действительно интересно.

[Интеррапт]

А как именно не отменяет?

Потому что это и остается ликом, который лечится тем, что нужно перестартовывать контейнер.

Ну это же не мемори лик уже.

Я и не говорил, что это memory leak, я поэтому и написал "А иной раз Джава просто очень серьезно отжирает память и сходу даже не всегда понятно почему"

в которой очень просто отследить почему происходит лик.

Ага, т.е. все-таки иной раз приходится (как вы написали) "париться о утечках", вместо того, чтобы просто "сосредоточиться на алгоритмах".

[Интеррапт]

Что бы не парится о утечках

Ага, конечно. Никогда о ClassLoader ликах не слыхали? Причину которых и найти сложно, а чтобы починить в большом коде - иной раз можно умом тронуться

Дайте линков мы изучим

Так выше уже привел.

[Интеррапт]

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

Я тоже так думал, насчет оптимизации. Но вот только когда вместо присваиваний указателей, начинаются присваивания shared_ptr - то вся производительность летит насмарку. Проверено. И custom allocator тут совсем не при чем (я вон boost pool использовал, который тоже в одной области памяти размещает обьекты без free/malloc). Задержки начнутся именно при присваиваниях и соответственно копированиях с атомарным увеличентием счетчика (для thread-safety) одного shared_ptr другому.

[crypto5]

А как именно не отменяет?

Потому что это и остается ликом, который лечится тем, что нужно перестартовывать контейнер.

Это не лик сам по себе, а результат другого лика, типа кто-то забыл в сессии или thread local обьект который ссылается на класлоадер, вот этот обьект и есть лик.

в которой очень просто отследить почему происходит лик.

Ага, т.е. все-таки иной раз приходится (как вы написали) "париться о утечках", вместо того, чтобы просто "сосредоточиться на алгоритмах".

Ну с утечками я как раз как то не сталкивался, все больше кто-то пишет код который рожает слишком много обьектов на ровном месте как в моем примере выше и программа не справляется, или например в программу приходит супергиганский request

[crypto5]

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

Задержки начнутся именно при присваиваниях и соответственно копированиях с атомарным увеличентием счетчика (для thread-safety) одного shared_ptr другому.

Ну наконец то!

[Medium-rare]

И custom allocator тут совсем не при чем

После того, как он уже дал выигрыш в несколько раз, да, возможно.
Ну тогда эксперимент будет GCC имплементация vs. MS. А то некоторые люди такие лекции на MSDN Channel 9 читали, как они всё замечательно сделали в новом VC++ компиляторе...

[Интеррапт]

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

Задержки начнутся именно при присваиваниях и соответственно копированиях с атомарным увеличентием счетчика (для thread-safety) одного shared_ptr другому.

Ну наконец то!

Ну так я спорил только потому, что думал, что С++11 компилятор получше оптимизирует всякие shared_ptr.

[Alexandr]

PS у меня C# сильно лучше, чем у вас, и C++ есть, но я тож жабу качаю

а что конкретно, кроме самой Java, какие фреймворки?
зы Вопрос ко всем

отвечаю с опозданием, мини отпуск был аднака

на совсем ближайшее время - довести Java SE (весь стек) до экспертного уровня, а дальше видно будет
если жизнь заставит лезть в JEE, то и туда полезу

[Alexandr]

PS у меня C# сильно лучше, чем у вас, и C++ есть, но я тож жабу качаю

В каком клане сидите?

клан называется system architect, положено "все знать" (с)

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

PS у меня C# сильно лучше, чем у вас, и C++ есть, но я тож жабу качаю

В каком клане сидите?

клан называется system architect, положено "все знать" (с)

клан неспящих