так рождаются нездоровые сенсации. java vs с++

alpet У меня дизасм, который ты привел получился при компиляции в дебаг. Ну да ладно.
Теперь интереснее:
под Pentium 640-3.2 - 94с с++ и 120с С#
под A64 3700+ - 90c c++ и 100с C#
под Pentium4 3.0 - 91c c++ и 84c C#
надо еще проверить сортировку не байтов а двордов, думаю ситуация поменяется.
возможно еще весь пример сделан умышленно, а тестовый файл подобран против P4, чтобы процент бранчпредиктов уменьшилось для кода скомпиленого именно студией - можно проверить.
но в данном случае уже можно сделать вывод, что дело не в плохой оптимизации с++, а наоборот в практически полном ее отсутствии в JIT )))

 

semen
Трудно сказать, что здесь чего причиной. Но вообще, я не исключаю, что JIT все-таки оказывается в чем-то быстрее. А файл кстати - архив 7z с рекламой, о чем утверждают его первые 2 байта.

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

Код (Text):

1. for(int i = size - 1; i; --i )
2.       for( int j = 1; j < i; ++j )
3.          if( arr[ j ] < arr[ j - 1 ] )
4.          {
5.             byte tmp = arr[ j ];
6.             arr[ j ] = arr[ j - 1 ];
7.             arr[ j - 1 ] = tmp;
8.          }

 

alpet
Ну да, оказывается быстрее, но явно случайно и только для P4-Prescott, но уже не Prescott-2М - тут явно недооптимизация JIT както помогла, видно же где он ступил и недооптимизировал и оптимизация эта вполне стандартная, а вот оптимизация для "blend" архитектуры в с++ дала сбой, но видно же, что сам оптимизатор лучше и не тупит, да и для большинства архитектур как он сделал лучше и оказалась.

 

semen

Ну что и следовало ожидать, когда алгоритм был доведен до классического (неквадратичного случая), ситуация поменялась куда более чем кардинально.
Во всяком случая мой Си++ код стал выполнятся за 81 сек, а следующий код на Шарпе за 112 сек (+31)

Код (Text):

1. static void Sort( byte[] arr)
2.         {
3.             if( arr.Length < 2 )
4.                 return 0;
5.  
6.             for (int i = arr.Length - 1; i > 0; --i)
7.                 for (int j = 1; j < i; ++j)
8.                     if (arr[j] < arr[j - 1])
9.                     {
10.                         byte tmp = arr[j - 1];
11.                         arr[j - 1] = arr[j];
12.                         arr[j] = tmp;
13.                     }
14.          
15.         }

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

Дизасм:

Код (Text):

1. for (int i = arr.Length - 1; i > 0; --i)
2. 0000002d 8B 46 04         mov         eax,dword ptr [esi+4]
3. 00000030 48               dec         eax  
4. 00000031 8B D8            mov         ebx,eax
5. 00000033 90               nop              
6. 00000034 EB 78            jmp         000000AE
7.                 for (int j = 1; j < i; ++j)
8. 00000036 BF 01 00 00 00   mov         edi,1
9. 0000003b 90               nop              
10. 0000003c EB 6B            jmp         000000A9
11.                     if (arr[j] < arr[j - 1])
12. 0000003e 3B 7E 04         cmp         edi,dword ptr [esi+4]
13. 00000041 72 05            jb          00000048
14. 00000043 E8 A9 2F 44 79   call        79442FF1
15. 00000048 0F B6 44 3E 08   movzx       eax,byte ptr [esi+edi+8]
16. 0000004d 8D 57 FF         lea         edx,[edi-1]
17. 00000050 3B 56 04         cmp         edx,dword ptr [esi+4]
18. 00000053 72 05            jb          0000005A
19. 00000055 E8 97 2F 44 79   call        79442FF1
20. 0000005a 3A 44 16 08      cmp         al,byte ptr [esi+edx+8]
21. 0000005e 73 48            jae         000000A8
22.                     {
23.                         byte tmp = arr[j - 1];
24. 00000060 8D 47 FF         lea         eax,[edi-1]
25. 00000063 3B 46 04         cmp         eax,dword ptr [esi+4]
26. 00000066 72 05            jb          0000006D
27. 00000068 E8 84 2F 44 79   call        79442FF1
28. 0000006d 0F B6 44 06 08   movzx       eax,byte ptr [esi+eax+8]
29. 00000072 89 04 24         mov         dword ptr [esp],eax
30.                         arr[j - 1] = arr[j];
31. 00000075 3B 7E 04         cmp         edi,dword ptr [esi+4]
32. 00000078 72 05            jb          0000007F
33. 0000007a E8 72 2F 44 79   call        79442FF1
34. 0000007f 0F B6 6C 3E 08   movzx       ebp,byte ptr [esi+edi+8]
35. 00000084 8D 47 FF         lea         eax,[edi-1]
36. 00000087 3B 46 04         cmp         eax,dword ptr [esi+4]
37. 0000008a 72 05            jb          00000091
38. 0000008c E8 60 2F 44 79   call        79442FF1
39. 00000091 8B D5            mov         edx,ebp
40. 00000093 88 54 06 08      mov         byte ptr [esi+eax+8],dl
41.                         arr[j] = tmp;
42. 00000097 3B 7E 04         cmp         edi,dword ptr [esi+4]
43. 0000009a 72 05            jb          000000A1
44. 0000009c E8 50 2F 44 79   call        79442FF1
45. 000000a1 8B 04 24         mov         eax,dword ptr [esp]
46. 000000a4 88 44 3E 08      mov         byte ptr [esi+edi+8],al
47.                 for (int j = 1; j < i; ++j)
48. 000000a8 47               inc         edi  
49. 000000a9 3B FB            cmp         edi,ebx
50. 000000ab 7C 91            jl          0000003E
51.             for (int i = arr.Length - 1; i > 0; --i)
52. 000000ad 4B               dec         ebx  
53. 000000ae 85 DB            test        ebx,ebx
54. 000000b0 7F 84            jg          00000036
55.                     }            
56.         }

 

Еще что выяснилось - под VS2005 напрямую видимо на самом деле запускается debug, не зависимо от компиляции. Видимо по этому и тормозит - напрямую запущенный он выдал всего 93,5 сек, на обновленном алгоритме.

 

alpet, вот вот, чтото не так у тебя с дебаг-релизом, листинг у тебя от дебага. я делал так - из командной строки запускаю экзешник, другой студией(не там где проект открыт) делаю аттач к процессу и брякаюсь - никаких лишних call`ов нету. вот если дебаг собрать и сделать тоже самое, то листинг такой же как у тебя. возможно при запуске напрямую из студии JIT полюбому рекомпилит с дебагом..

 

semen

Видимо в самом деле так и есть. Но пока что выяснилось, что не с любым алгоритмом JIT справляется оптимально, и многие классические алгоритмы все-же оптимальнее будет компилировать в С++. Может когда-нибудь эта ситуация да изменится, но имхо открытый код иногда будет все-же предпочтительнее MSIL-программы...

 

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

 

http://citforum.ru/programming/java/netvsjava/

Тут можно подумать...

 

Кто бы сомневался, что .NET микро-тормоз (или майкро?)

 

А кто-нить тестировал COM по полной?

 

Подумать можно, только слижком уж старые версии использовались, сейчас версия Java 1.3 стала настолько стара что больше не поддерживается - настал ее "end of life" (как выражается SUN), некоторые участки кода стали быстрее в 3-4 раза, не говоря о существующей версии которая почти готова: Java 1.6 - в этой версии даже скорость Swing показывает хорошие результаты. Я уже не говорю о новой библиотеке java.nio которая повзоляет читать-записывать большие файлы быстрее чем при помощи стандартных библиотек С, это было доказано. File I/O действительно хорош. Я уверен что в СИ ШАРП тоже есть большие изменения к лучшему не знаю если на столько большие, скажу лишь что разница между Java 1.3 & Java 1.6 это разница в скорости почти во всех областях как минимум в 2 раза, больше всего это заметно в графике 2D & 3D. Более того, есть большая разница при работе с обьектами типа ArrayList & HashMap если запустить Java приложение при помощи опции -server, по умолчанию же это -client - который работает в несколько раз медленнее чем с опцией -server. Это тоже важно. Кроме того Java работает по историческим причинам быстрее на юникс машинах в частности при работе с файлами - чего я не могу сказать о си шарпе. Кароче есть еще много моментов о которых автор ничего не упомянул.

Это Java уже тоже поддерживает.
Меня ВСЕ устраивает в JAVA включительно скорость - только одно БЕСИТ - на ней хреново писать серьезные десктопные приложения так как нет надлежащих айпишных функций (например прозрачные окна и много других вещей). Очень жаль.