Коррекция к предыдущему примеру, чтобы было ближе к жава-коду, вместо

  NewSpeed2 *o[N];

  NewSpeed2 **o = new NewSpeed2*[N];

$ time ./NewSpeed2 
132
13
49999995000000

real    0m1.525s
user    0m0.979s
sys     0m0.453s

Тебе уже показали, что `java -Xms1g NewSpeed2` поможет отцу русской демократии. GC - это тоже инструмент, к использованию которого надо подходить с умом.

> Тебе уже показали, что `java -Xms1g NewSpeed2` поможет отцу русской демократии. GC - это тоже инструмент, к использованию которого надо подходить с умом.

$ time java -Xms1g NewSpeed2
130
13
49999995000000

real    0m1.768s
user    0m1.801s
sys     0m0.559s

Скорость примерно та же, что и в плюсах.

Кто-то недавно утверждал, что жава быстрая, и плюсы ее догонят только со специальным аллокатором. Пока что получилось наоборот - оттюненая жаба догнала дефолтные плюсы.

Продолжаем тюнить жабу. Поднимем значение параметра до 2 гигабайт, большие значения все равно не улучшают результат.

$ time java -Xms2g NewSpeed2
44
12
49999995000000

real    0m0.872s
user    0m0.489s
sys     0m0.327s

Круто!

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

$ cat NewSpeed3.cpp 
#include <sys/time.h>
#include <iostream>
#include <boost/pool/object_pool.hpp>

class NewSpeed2
{
public:
  int n;
  NewSpeed2(int n) { this->n = n; }
};

boost::object_pool<NewSpeed2> pool;

int main()
{
  int N = 10000000;
  NewSpeed2 **o = new NewSpeed2*[N];
  struct timeval start, end;

  gettimeofday(&start, NULL);
  for (int i = 0; i < N; i++)
    o[i] = pool.construct(i);
  gettimeofday(&end, NULL);

  std::cout << ((end.tv_sec-start.tv_sec)*1000000 + end.tv_usec - start.tv_usec)*1000/N << std::endl;

  long debugsum = 0;
  gettimeofday(&start, NULL);
  for (int i = 0; i < N; i++)
    debugsum += o[i]->n;
  gettimeofday(&end, NULL);

  std::cout << ((end.tv_sec-start.tv_sec)*1000000 + end.tv_usec - start.tv_usec)*1000/N << std::endl;
  std::cout << debugsum << std::endl;

  return 0;
}

$ g++ -O2 -o NewSpeed3 NewSpeed3.cpp

$ time ./NewSpeed3
44
5
49999995000000

real    0m0.554s
user    0m0.276s
sys     0m0.254s

Вот так легко, изменением нескольких строк кода, плюсы снова не дали яве вырваться вперед. Где ошибка? %-)

> Вот так легко, изменением нескольких строк кода, плюсы снова не дали яве вырваться вперед. Где ошибка? %-)

А что будет, если начать из десятка-другого потоков память параллельно выделять?

Достаточно использовать tcmalloc как аллокатор общего назначения, результаты более чем замечательные.

> Вот так легко, изменением нескольких строк кода, плюсы снова не дали яве вырваться вперед. Где ошибка? %-)

А сам-то как думаешь? Где узкое место обеих программ? Когда найдешь его, простая арифметика расставит все по своим местам.

Я же эту дискуссию заканчиваю, учителем информатики я здесь не работаю. :-)

> А сам-то как думаешь? Где узкое место обеих программ? Когда найдешь его, простая арифметика расставит все по своим местам.

В алгоритме. Но я не пытаюсь быстро вычислить сумму от 1 до N. Я проверяю утверждения:

В жабе выделение небольшого блока памяти занимает порядка 1-3 наносекунды.

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

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

Проверка показала, что и это утверждение ложно. На дефолтных настройках С++ обошел жаву. Это было даже немного неожиданно.

Короче, сделать на C++ свой аллокатор, что будет работать не глупее чем аллокатор Java это работа явно не на пол часа. Но если кто хочет, пусть пробует.

И это утверждение оказалось ложным. Для «написания» аллокатора не потребовалось и десяти минут.

Если ты считаешь, что в моих проверках была ошибка - укажи ее, я ее исправлю.
Имхо, ценность java совсем не в скорости.

А еще мне очень интересна эта задача:
> Пока что рекорд такой:

Haskell: ~50 строк C++: ~1000 строк

Можно узнать ее условие?

> В алгоритме.

А если подумать? Алгоритм немного разный, но это не главное.

У Вас на компьютере память работает мгновенно? Или хотя бы влезает в кеш L1? :)

Размер объектов в этих примерах какой? Сколько памяти выделилось в этих случаях? Посчитайте, подумайте.

Можно узнать ее условие?

Я ее даю на собеседованиях. :) Так что раскрывать карты не буду. Могу лишь сказать, что речь идет о многопоточности и эффективных контейнерах.

> И это утверждение оказалось ложным. Для «написания» аллокатора не потребовалось и десяти минут.

Кстати.. Ты бы, попробовал ради смеха еще и освободить ту память. %) Или у тебя во всех программах память сначала выделяется, а потом скопом освобождается.

Еще было бы интересно, как ты будешь использовать созданные таким образом объекты в реальной жизни. Повседневная ситуация: есть API, где принимают, скажем, std::string, причем либо указатель на него, либо ссылку. Если указатель, то в ряде случаев API предполагает, что объект будет освобождаться этой сторонней библиотекой при помощи обычного delete. Ну что, справится твой бустанутый object_pool? В какую позу прийдется с ним встать, и удастся ли? Смотрите в новых выпусках журнала BDSM++. Объекты же, созданные обычным new в жабке, отлично сами убираются, передаются куда нужно без геморроя и утилизуются по мере надобности. Причем если не держать на них ссылки долго - утилизуются очень быстро. Если держать - ну кто ж тебе виноват.

Вообще-то Java и С++ это просто инструменты. Прийдет время, и ты сможешь их нормально использовать. Все ОК. :-)

> Достаточно использовать tcmalloc как аллокатор общего назначения, результаты более чем замечательные

Где гарантия, что его получится использовать с любой сторонней библиотекой?

А чем собственно твоё переопределение операторов new и delete будет отличаться от использования этой библиотеки? Где гарантия, что такое переопределение ничего не сломает?

> А чем собственно твоё переопределение операторов new и delete будет отличаться от использования этой библиотеки? Где гарантия, что такое переопределение ничего не сломает?

Ты определенно делаешь успехи :-)

>> Пока что рекорд такой:

Haskell: ~50 строк C++: ~1000 строк

Можно узнать ее условие?

Это очень секретная задача!
Кроме того этот фантазёр её ещё не придумал.

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

>> Можно узнать ее условие?

Я ее даю на собеседованиях. :) Так что раскрывать карты не буду.

:)
Я плакаль
:)

> Кстати.. Ты бы, попробовал ради смеха еще и освободить ту память. %) Или у тебя во всех программах память сначала выделяется, а потом скопом освобождается.

Это, разве что, ради смеха. :) Для object_pool-а многое можно проверить. Можно удалить объекты в прямом или в обратном порядке, или через одного, а можно и все сразу. Но, поскольку к жаве это отношения не имеет, стоит ли засорять тред такими кусками кода? Интересущиеся смогут измерить.

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

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

> Повседневная ситуация: есть API, где принимают, скажем, std::string, причем либо указатель на него, либо ссылку. Если указатель, то в ряде случаев API предполагает, что объект будет освобождаться этой сторонней библиотекой при помощи обычного delete. Ну что, справится твой бустанутый object_pool?

Так много глупостей сразу, какое-то мазохистское API. Передавать по указателю - уже не самое лучшее решение. Разносить выделение и освобождение в разный код - тем более. А для string вообще нет смысла использовать object_pool. Но если очень хочется...

class ShootYourLeg {
  static boost::object_pool<ShootYourLeg> pool;
public:
  int n;
  ShootYourLeg(int n) { this->n = n; }
  void* operator new(size_t) { return pool.malloc(); }
  void operator delete(void*p) { return pool.free((ShootYourLeg*)p); }
};

И не сложно, вроде. Этот класс можно выделять через new, освобождать через delete, и передавать по указателю. При необходимости придется навесить внутри на object_pool синхронизацию. Плюсы позволяют выстрелить себе в ногу многими разными способами, в жабе столько нет.

> Вообще-то Java и С++ это просто инструменты. Прийдет время, и ты сможешь их нормально использовать. Все ОК. :-)

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

> Я ее даю на собеседованиях. :) Так что раскрывать карты не буду. Могу лишь сказать, что речь идет о многопоточности и эффективных контейнерах.

Как на счет собеседования через интернет? :)

> Я плакаль

А я рыдаль

> Это, разве что, ради смеха. :) Для object_pool-а многое можно проверить. Можно удалить объекты в прямом или в обратном порядке, или через одного, а можно и все сразу. Но, поскольку к жаве это отношения не имеет, стоит ли засорять тред такими кусками кода? Интересущиеся смогут измерить.

В том то и дело, сынок, что тебе не интересна истина. Тебе на нее настрать. Все что тебе интересно, это повыпендриваться.

Особенно это хорошо видно, когда ты отказываешься сделать простой тест, и заехать мордой в .. плюсы. :)

Я не зря предложил тебе его сделать. Плюсанутые вроде тебя любят не смотреть на алгоритмическую сложность задачи. Цена destroy в тоем object_pool O(N). Надеюсь, такое ты читать умеешь?

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

Ога. Но для поливания жабки грязью - сойдет.

Так много глупостей сразу, какое-то мазохистское API.

Ну-ну. И сколько ты видел разных API в своей жизни? :)

Передавать по указателю - уже не самое лучшее решение.

И чем же посоветует передавать глубокоуважаемый эксперт? В плюсах вариантов немного. Передавать объект по значению? Не жирно ли? По ссылке? :)

А ты в курсе, что в некоторых API предполагается, что библиотека должна будет «видеть» объект какое-то время после вызова метода? Что посоветуешь им сделать: снять копию (дорого) или просто написать в комментариях, что пользователь должен не убивать объект до определенного времени (leaky abstraction)?

И не сложно, вроде. Этот класс можно выделять через new, освобождать через delete, и передавать по указателю.

См. выше про цену такого «delete». Не удивительно, что часто софт на плюсах тупит просто адово. Всегда найдется любитель буста, не читающий их доки.

При необходимости придется навесить внутри на object_pool синхронизацию.

Ты хоть раз в своей жизни мерял цену этого? Я мерял пару месяцев назад для POSIX threads. Как по-мне - дорого. :-) Уж лучше thread-local malloc с непосредственно выделением памяти в одном потоке. Как писали одни товарищи (статья пробегала на LtU), по сравнению с обычным malloc это на 25% быстрее.

Как на счет собеседования через интернет? :)

Спасибо, Вы его уже завалили.

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

LOL

Спасибо, я посмеялся. Вспомнил анекдот:

Сын приходит к отцу и спрашивает:

- Папа, а правда что интернет убивает мозг?

- Гы-гы, сынок. LOL.

Все это многословные рассуждения из серии «если бы у бабушки был икс», от них веет беспомощностью, поэтому лучше держаться фактов. По факту, ты сначала намекал на то, как страшно ты расправляешься с цэ/цэпэпэ, орудуя джавой и хаскелем, причем пишется все за считанные часы, занимает считанные строки и работает чуть-чуть быстрее процессора. Все: «да ну на, быть не может, докажи». Ты: «мамой клянусь». Завесу коммерческой тайны удалось приподнять только над гениальным циклом, который создавал(?) миллиард объектов и занимал в памяти менее 200МБ. Этот код, по мысли «учителя информатики», должен был мерять производительность аллокатора джавы. Код довели до вменяемого и привели замеры для плюсов. Вот это факт, который каждый может проверить и сделать выводы. ПС: Сколько можно лажать в одном и том же треде, оставь что-нибудь на потом.

> Все это многословные рассуждения из серии «если бы у бабушки был икс», от них веет беспомощностью, поэтому лучше держаться фактов. По факту, ты сначала намекал на то, как страшно ты расправляешься с цэ/цэпэпэ, орудуя джавой и хаскелем, причем пишется все за считанные часы, занимает считанные строки и работает чуть-чуть быстрее процессора. Все: «да ну на, быть не может, докажи». Ты: «мамой клянусь». Завесу коммерческой тайны удалось приподнять только над гениальным циклом, который создавал(?) миллиард объектов и занимал в памяти менее 200МБ. Этот код, по мысли «учителя информатики», должен был мерять производительность аллокатора джавы. Код довели до вменяемого и привели замеры для плюсов. Вот это факт, который каждый может проверить и сделать выводы. ПС: Сколько можно лажать в одном и том же треде, оставь что-нибудь на потом.

Похоже, что Вы - писатель, но не читатель и не пониматель. Ничего, бывает и хуже.

да ладно, бро, ну ты позорно слил, чего уж теперь...

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

>А я рыдаль
Но задачу так и не придумаль?

Видно же что молодой зеленый студентег пишет

>Видно же что молодой зеленый студентег пишет
Да я, в общем-то для развлечения.
И молодой/пожилой человек мне доставил достаточно веслья, чтобы не считать время на ответы - зря потраченным :)

> В том то и дело, сынок, что тебе не интересна истина. Тебе на нее настрать.

Мне нет смысла ее проверять, я ее знаю. Ты, видимо, тоже, а значит проверять тем более нет смысла. Конечно, можно написать код, но он уже не имеет отношения к теме.

> Я не зря предложил тебе его сделать. Цена destroy в тоем object_pool O(N).

Знаю. И я тоже не зря написал про порядок удаления. Если удалять в обратном порядке - цена может вдруг стать O(1). И что? Это разве имеет какое-то отношение к вопросу? Если да, то к какому вопросу?

Я что-то перестаю понимать, какой вопрос мы обсуждаем. Я же сам писал «Плюсы позволяют выстрелить себе в ногу многими разными способами», не надо мне же ее доказывать. :)

> И сколько ты видел разных API в своей жизни? :)

Не буду раскрывать карты. :)

> В плюсах вариантов немного.

В каком языке больше?

> Передавать объект по значению? Не жирно ли? По ссылке? :)

По ссылке, конечно. Не забыв const, если объект не меняется.

> А ты в курсе, что в некоторых API предполагается, что библиотека должна будет «видеть» объект какое-то время после вызова метода? Что посоветуешь им сделать: снять копию или написать в комментариях ...

Если это - std::string, то снимать копию. Например, функция:

void setMyPath(const std::string &path);

setMyPath("/home/user/data/");

В отдельных случаях, когда надо передать одному объекту интерфейс другого объекта, с которыми он потом будут обмениваться данными, передача по указателю имеет смысл. Но я не могу придумать ни одного вменяемого случая, когда это было бы нужно для std::string.

> См. выше про цену такого «delete».

Не так. Вопрос был:
> ... справится твой бустанутый object_pool?
И с поставленной задачей он справился. В задаче не шла речь о производительности, только о возможности использовать object_pool в случае, если объект будет удаляться в другом коде через delete.

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

>> При необходимости придется навесить внутри на object_pool синхронизацию.

Уж лучше thread-local malloc с непосредственно выделением памяти в одном потоке.

«При необходимости» подразумевает, что для thread-local данных синхронизация не нужна.

> Спасибо, Вы его уже завалили.

Жаль. Очень хотелось попробовать свои силы в задаче с постановкой «решить за минимальное число строк».

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

Да ладно уж. Нельзя сказать, что он был не прав в корне. Он ошибся только в замере скорости выделения памяти. Ошибка в бенчмарках - очень распространенное явление. Мало кто представляет, что транслятор может соптимизировать, и может учесть в тестах все подобные моменты. Вероятно, даже, не любой разработчик gcc или ядра знает все тонкости. Соседний тред про memcpy это подтверждает.

А так, в целом, он во многом был прав. Прав, что выделение памяти в java при определенных условиях может быть быстрее, чем в C++. Прав, что для достижения при этих условиях той же скорости в С++, нужен аллокатор. И, вообще, если я его правильно понимаю, я согласен с ним в том, что язык программирования - это инструмент, и его надо выбирать исходя из задачи.

Жаль, только, что он так и не сказал мне эту свою задачу. :)

>Oracle будет разрабатывать две версии JVM на основе OpenJDK: платную и бесплатную.

Совсем офанарели, дурни.

JavaScript спасёт этот мир!

Враньё

В источнике ясно сказано: «Oracle cooks up free and premium JDKs» а вы почему-то заменили JDK на JVM. JDK - это Java Development Kit, для разработчиков, а JVM - Java Virtual Machine, для пользователей.