[java] Бить ли за new по рукам?

ТОлкьо такие:

String s = «s:»+obj+" , d:" + 3;

в

String s = new StringBuffer(«s:»).append(obj).append(" , d:").append(3);

А вот если у нас цикел то не заворачивается 8)

с подсказкой iZEN выиграл ещё 25% сменив StringBuffer на StringBuilder. итого 0.335s

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

> А из этого теста видно что ява быстрее

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

но больше хавает память

вот ты и признал( хоть будешь открещиваться ), что сам метанировал

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

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

вот ты и признал( хоть будешь открещиваться ), что сам метанировал

Ваша субъективная реальность полна плодов вашей извращенной фантазии.

> и если вы это знали, то тем хуже для вас.

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

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

5 против 6 - сможете сделать равнее?

в общем-то я не ставил цели стравнивать java с cpp. а сравнивать java string с java stingBuffer и показать, что в цикле ничего оптимизированно не будет.

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

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

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

> Попробуйте еще раз, у вас явно проблемы, приду когда протрезвете, ваша белочка.

там 5 vs 6 - специально проверил

подразумевая в яве телепатическое выделение памяти кое догадывается

я тебе сейчас шокирую, конечно, но если убрать reserve - то весь цикл отработает за 0.138 сек( а почему - можешь почитать в утренней лекции ), а теперь - я добавляю тебя в игнор, радуйся!

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

там 5 vs 6 - специально проверил

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

я тебе сейчас шокирую, конечно, но если убрать reserve - то весь цикл отработает за 0.138 сек( а почему - можешь почитать в утренней лекции ),

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

а теперь - я добавляю тебя в игнор, радуйся!

Что то игнорастов как было 81 так и осталось, а скор на единицу отрос, можыт вы кудато не туда добавили меня?

> звание шланга остается у вас.

reverse-complement   ±   1/3   2×
spectral-norm   ±   1/3   ±
pidigits   ±   1/6   1/2
fasta   ±   1/3   ±
mandelbrot   ±   ±   ±
n-body   2×   1/3   ±
k-nucleotide   2×   ±   ±
fannkuch   3×   1/2   ±
regex-dna   3×   ±   ±
binary-trees   4×   1/2   ±
chameneos-redux   5×   

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

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

Что то игнорастов как было 81 так и осталось

перепроверь

выложи на pastebin полный код сиплюплюсный я соберу и посмотрю, будет ли мне что ответить;)

reverse-complement ± 1/3 2× блаблабла

Там для вас специально три картинки сделали, вам нужно посчитать палочки на левой.

не судьба?

Зойчем? Ржать приятнее чем измерять длину выделения памяти сей. Тем более что зойдача доказать бредовость вашего теста, а не скорость явы, на яве пишут не из-за скорости какбе, если вам в утреннем треде не рассказали.

перепроверь

Скор больше не вырос.

запускал в VC2010, сейчас попробую gcc

еще наверняка в плюсах юзается сишный аналог realloc() для внутреннего буфера, тадыть не придется копировать строку, это раз.

по хорошему тест надо проводить еще на wide строках, ибо ява работает с какойто реализацией уникода, а плюсы как обычно мухлюют в данном вопросе.

звиняюсь - вот исправленная версия, которая собирается gcc

#include <cstdio>
#include <string>
#include <vector>

#include <time.h>

	char* itoa(int value, char* result) {
		// check that the base if valid
		char* ptr = result, *ptr1 = result, tmp_char;
		int tmp_value;
	
		do {
			tmp_value = value;
			value /= 10;
			*ptr++ = "zyxwvutsrqponmlkjihgfedcba9876543210123456789abcdefghijklmnopqrstuvwxyz" [35 + (tmp_value - value * 10)];
		} while ( value );
	
		// Apply negative sign
		if (tmp_value < 0) *ptr++ = '-';
		*ptr-- = '\0';
		while(ptr1 < ptr) {
			tmp_char = *ptr;
			*ptr--= *ptr1;
			*ptr1++ = tmp_char;
		}
		return result;
	}


int main( void ) 
{
	clock_t start = clock();

	char buf[ 10 ];
    std::string s;
    for( int i = 0 ; i < 2000000 ; ++i )
	{
        s += "";
		s += itoa( i, buf );
	}

	float interval = ( clock() - start ) * 1000 / CLOCKS_PER_SEC;
	printf( "%f\n", interval );

	getc( stdin );
	return 0; 
} 

собранное с -O3 работает 0.156сек

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

#include <cstdio>
#include <string>
#include <vector>

#include <time.h>

	wchar_t* itoa(int value, wchar_t* result) {
		// check that the base if valid
		wchar_t* ptr = result, *ptr1 = result, tmp_char;
		int tmp_value;
	
		do {
			tmp_value = value;
			value /= 10;
			*ptr++ = L"zyxwvutsrqponmlkjihgfedcba9876543210123456789abcdefghijklmnopqrstuvwxyz" [35 + (tmp_value - value * 10)];
		} while ( value );
	
		// Apply negative sign
		if (tmp_value < 0) *ptr++ = '-';
		*ptr-- = '\0';
		while(ptr1 < ptr) {
			tmp_char = *ptr;
			*ptr--= *ptr1;
			*ptr1++ = tmp_char;
		}
		return result;
	}


int main( void ) 
{
	clock_t start = clock();

	wchar_t buf[ 20 ];
    std::wstring s;
    for( int i = 0 ; i < 2000000 ; ++i )
		s += itoa( i, buf );

	float interval = ( clock() - start ) * 1000 / CLOCKS_PER_SEC;
	printf( "%f\n", interval );

	getc( stdin );
	return 0; 
} 

я сам удивился - но работает быстрее чем с char*, 0.107сек

Индус, не нашел в С++ конвертацию int в string, от жешь....

омг, ка можно писать на языке который даже не тормозит когда от него это ожидаешь?

> Индус, не нашел в С++ конвертацию int в string, от жешь....

толстячок ты :) я выбрал более быстрое решение, которое ничем не хуже

> омг, ка можно писать на языке который даже не тормозит когда от него это ожидаешь?

сам в шоке - после такого думаю перебраться на Java, там стабильно все

И кто после этого толстячек? Если вы даже itoa решили с оптимизировать.

Да, а какой виртуал меня всетаки заигнорил?

> И кто после этого толстячек? Если вы даже itoa решили с оптимизировать.

я его не оптимизировал, просто itoa не реализован в gcc - потому нагуглил по быстрому готовое

> Да, а какой виртуал меня всетаки заигнорил?

сверху справа фильтр есть - я пока выставил на все сообщения

Читерство. Макском говорил вроде, что отключали эту фишку чтобы игнор был настоящий.

> Читерство. Макском говорил вроде, что отключали эту фишку чтобы игнор был настоящий.

как видишь работает

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

> Ну у меня нет возможности проверить. Надо когото для этого заигнорить, себя шоле?

меня давай - будем на равных

Низя, религия запрещает, лучше я спасть пойду, а то развели толксы в девелопменте панимаишь. (и как обычно ответа на вопрос топика нету)

[code] qnikst@qnikst ~/prog/contest $ java Test 240 qnikst@qnikst ~/prog/contest $ ./a.out 160.000000 [/code]

50% потери.

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

а код на Java можно посмотреть?

> будут ли строки на выходе одинаковые мне вдаваться лень.

на С++ строка правильно формируется - я проверял начальные и конечные значения

не, интересует вывести значения и того и другого в файлик и прогнать diff'ом. Поскольку могут быть всякие интересные оптимизации внутреннего представления строк при работе с ними.

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

> Поскольку могут быть всякие интересные оптимизации внутреннего представления строк

в С++ там обычный буфер из wchar_t( т.е. UTF32 для линукса ), что опять же прямо видно в дебаггере

> тут даже .NET лучше

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

> oh'really?

Y'rly.

Надо смотреть ассемблерный выхлоп, а не тесты замерять. Компилятор не гарантирует самой эффективной замены, и сама замена происходит не всегда и не везде - как решит javac.

> Дотнет ничуть не лучше, у него меньше оверхед, т.к. во всю используются нативные библиотеки.

не спорю, но я писал как раз только про то, что приложения на .NET таки работают быстро, в отличие от, а то что это по выражению белки - «махлевание», просто оправдание для бедных

> Надо смотреть ассемблерный выхлоп, а не тесты замерять.

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

Заменяются выражения типа S += «asd»+asd+«dfgh»+ddd; или т.п. в массиве максим что будет сделано это:

for (..) { StringBuilder Sb = new StringBuilder(s); Sb.append(i); s=Sb; }

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

Так, что радостно читаем документацию и комментарии к ней.

сама замена происходит не всегда и не везде - как решит javac.

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

Вопрос, каким психом надо быть, чтобы утверждать что это может работать лучше чем cpp?

Во-первых всегда быстрее - не может. Во-вторых в некоторых случаях - может, для того чтобы это утверждать нужно быть Cameron Purdy http://www.linkedin.com/pub/cameron-purdy/0/10/23a или Cliff Click http://blogs.azulsystems.com/cliff/2009/09/java-vs-c-performance-again.html

www.theserverside.com/discussions/thread.tss?thread_id=59756

> или Cliff Click http://blogs.azulsystems.com/cliff/2009/09/java-vs-c-performance-again.html

«but it's pain to use them in practice... so probably 99% of all C/C++ programs compile without the benefit of profiling.» - брехня :)

«allows teams to write larger programs quicker than they could in C/C++» - быстрее написать да, лучше сделать - нет :) что видно по тем же большим программам

«Garbage Collection is just easier to use than malloc/free» - а кто-то спорил? С++ вообще более сложный язык

«GC allows for entirely different algorithms, isn't just easier to use than malloc/free.» - внезапно в С/С++ тоже есть много вариантов, ну и недавно показынные мной примеры с vector/string опять же показывают, что malloc то и не нужен для простых операций

«For the example of super-fast memory DB in Java visit http://www.h2database.com it beats MySQL both in performance and footprint :) Of course it's specifically tuned for in-memory use.» - ну это уже совсем бред, во-первых MySQL не самая быстрая СУБД, а совсем наоборот, во-вторых MySQL умеет намноооого больше - а это что-то да значит, в третьих - «tuned for in-memory use», ну так епт, на С/С++ тоже есть небольшие быстрые СУБД, которые работают с БД в памяти - почему не сравнить с ними

«Raw Small Benchmark Speed» - тут С/С++ как раз впереди, если-что

«First-Person „Shooter“ PC Games» - пусть расскажет об этом Id, Valve и т.д.

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

П.С. вобщем поверить этой статье, что Java при равных условиях может быть быстрее( то что писать на ней проще - никто и не спорит ), смогут только фанаты Java

вобщем не поверить этой статье, что С++ при равных условиях может быть быстрее( то что писать на нем гиморнее - никто и не спорит ), смогут только фанаты С++

fix