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

@Elderine

Если писать код на C# тютелька-в-тютельку с твоим на C++, то он будет работать медленнее возможного ввиду необходимости использования usafe. (смотри пример на 4 поста выше - там на C# по разному одно и то же написано. С usafe получалось на 10% медленнее).

Если поменять это в коде, то эксперимент будет нечистый, хотя и быстрее.

 

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

А зачем же тогда по-вашему МС так отчаянно способствует ужесточению законов об авторском праве? Переговоры ведут с правительством КНР (удачно Вы китайцев вспомнили), задаривают европейцев "бесплатными" лицензиями своего фирменного ПО лишь бы побыстрее утвердили "смертную казнь" для всех пиратов. О менее авторитетных государствах вообще говорить не приходится. К примеру, не так давно в Эквадоре узаконили пиратские копии на оптических носителях. Помните чем это закончилось? Намерения этой компании не вызывают у меня сомнений.

 

Quantum

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

 

masquer

Привычка. Извини. Исправлюсь.

Мне кажется, что эти пределы уже давно нарушились и МС спохватилось.



А обсуждение начиналось то о java vs. c++



Возвращаясь к теме, тут немного устаревшей но очень интересной информации по оптимизации JIT Java.

 

и то, и то - флейм, так что нормально )

 

Имхо, "аппаратная поддержка NET" - это такая же глупость как "аппаратная поддержка Windows".



Впрочем, некоторых производителей процессоров подозревают в "аппаратной поддержке Linux":

http:/www.computerra.ru/news/265469/

 

captain cobalt

Странная аналогия: виртуальная машина vs. операционная система. Что значит

? В той статье намекается на возможность сотрудничества AMD с линуксоидами, чтоб последние научились нормально оптимизировать свои приложения, включая ядро самого Линукса, под процессоры AMD. Лучше бы они пригласили к себе разработчиков GCC Хмм... Так это и есть

? Хотя, может в AMD решили взять к себе опенсорсников, т.к. ценят их умение работать усердно и бесплатно...

 

Quantum

Странная аналогия: виртуальная машина vs. операционная система.



Операционная система - это, по определению, виртуальная машина плюс менеджер ресурсов.



Лучше бы они пригласили к себе разработчиков GCC



Разработчиков GCC уже пригласили к себе RedHat.

GCC всегда делали упор больше на переносимости, чем на оптимизации.



может в AMD решили взять к себе опенсорсников, т.к. ценят их умение работать усердно и бесплатно...



Более точно сказать так: дешевле нанять на работу одного руководителя открытого проекта, а остальные "энтузиасты" будут работать бесплатно.



Торвальдс и все "предводители" относятся именно к такой категории.

 

captain cobalt

ОС - это менеджер ресурсов. Если VM в данном контексте является намёком на HAL, то, строго говоря, HAL - это не совсем VM, да и не является обязательным компонентом системы. В досе ничего такого не было, к примеру. А засунуть HAL в процессор, естественно, глупо.

Одно другому не мешает. Тут можно перефразировать Р. Хайда: линуксоиды всё время трындят о высокой степени переносимости сишного кода, но при этом пишут совершенно непереносимый код. Так на SF рождаются проекты по портированию сишного кода (!) проекта X под SPARC, m68K, микроблейз и т.д. и т.п.



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

 

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



Короче, аппаратного выполнения MSIL не будет никогда. Причин очень много. Хотя могут оказаться полезными инструкции, ускоряющие отдельные сложные операции. Например сборку мусора. Но это будет полезно не только для .net



И ещё о GCC. Вкладывать сюда собирается не только AMD но и Итаниумщики:

http:/www.zdnet.co.uk/print/?TYPE=story&AT=39257054-39020354t-10000009c



Хотя всё равно непонятно, что они там забыли. Ну хорошо, GCC нужен чтобы компилировать ядро Linux. Но ядро - это не та часть софта, которая использует 99% процессорного времени. Тогда зачем его оптимизировать?

 

чтобы оно продолжало использовать менее 99% процессорного времени

 

GCC и в правду надо оптимизировать, особенно его порт под MinGW. Очень уж он долго самого себя собирает, как впрочем и ядро. Основная идея - вынести компилятор в сервис, дабы он не загружался по сотне раз (процесс то в Win32 создается небыстро, в отличии от потока особенно если надо грузить всякие DLL). Вот как-то только сервису передавать команды на компиляцию...

 

captain cobalt

Почти всё в *никсах компилируется этим GCC. Кроме ядра есть ещё монстр скромно именуемый LIBC, которому тоже не помешала бы оптимизация. Но AMD почему-то решили связаться с ядерщиками, кажется (новость то из разряда слухов). Видимо, у них другие планы.

Об этом я уже высказался. .NET в кремнии будет, IMO.

 

[оффтоп]

Вопрос.

А насколько нереально создание в win32 аналога fork? Со сравнимой производительностью.

Ребята, которые newlib пишут (c-шная либа, на которой MinGW/Cygwin стоят), очень сокрушались на тему необходимости использования CreateProcess в своей реализации fork. И мне просто любопытно -- а так ли это необходимо?

[/оффтоп]

 

в psxdll.dll есть fork()

ставь sfu и будет счастье

 

Elderine

А деструкторы в C++ за тебя дядя писать будет? Вот и тормозит - постоянная подкачка с диска идет (объектов ты создаешь не меряно). Еще советую заботать линейную алгебру и никогда не обращать матрицу за n!*(n^2) .

 

Откомпилил сишарп, запустил, пока он работал брякнулся в него отладчиком:

Код (Text):

1. --- D:\tmp\SortFile\SortFile\Program.cs ----------------------------------------
2. 00000000  push        edi  
3. 00000001  push        esi  
4. 00000002  push        ebx  
5. 00000003  push        ebp  
6. 00000004  mov         esi,ecx
7. 00000006  mov         edi,dword ptr [esi+4]
8. 00000009  cmp         edi,2
9. 0000000c  jge         00000013
10. 0000000e  pop         ebp  
11. 0000000f  pop         ebx  
12. 00000010  pop         esi  
13. 00000011  pop         edi  
14. 00000012  ret              
15. 00000013  xor         ebp,ebp
16. 00000015  test        edi,edi
17. 00000017  jle         0000004E
18. 00000019  mov         ecx,1
19. 0000001e  cmp         edi,1
20. 00000021  jle         00000047
21. 00000023  movzx       eax,byte ptr [esi+ecx+8]
22. 00000028  cmp         al,byte ptr [esi+ecx+7]
23. 0000002c  jae         00000040
24. 0000002e  movzx       ebx,byte ptr [esi+ecx+7]
25. 00000033  movzx       edx,byte ptr [esi+ecx+8]
26. 00000038  mov         byte ptr [esi+ecx+7],dl
27. 0000003c  mov         byte ptr [esi+ecx+8],bl
28. 00000040  add         ecx,1
29. 00000043  cmp         edi,ecx
30. 00000045  jg          00000023
31. 00000047  add         ebp,1
32. 0000004a  cmp         edi,ebp
33. 0000004c  jg          00000019
34. 0000004e  pop         ebp  
35. 0000004f  pop         ebx  
36. 00000050  pop         esi  
37. 00000051  pop         edi  
38. 00000052  ret

Хорошо видно, что JIT оптимизировал хуже чем с++ компилятор:

Код (Text):

1. ?Sort@@YAXPAEH@Z PROC                                   ; Sort, COMDAT
2. ; _arr$ = ebx
3. ; _size$ = edi
4. ; File d:\tmp\sortfile_cpp\sortfile_cpp\main.cpp
5. ; Line 54
6.         test    edi, edi
7.         jle     SHORT $LN5@Sort
8.         push    ebp
9.         push    esi
10.         mov     ebp, edi
11. $LL7@Sort:
12. ; Line 55
13.         cmp     edi, 1
14.         jle     SHORT $LN6@Sort
15.         mov     eax, ebx
16.         lea     esi, DWORD PTR [edi-1]
17. $LL4@Sort:
18. ; Line 56
19.         mov     cl, BYTE PTR [eax]
20.         mov     dl, BYTE PTR [eax+1]
21.         cmp     dl, cl
22.         jae     SHORT $LN3@Sort
23. ; Line 59
24.         mov     BYTE PTR [eax+1], cl
25. ; Line 60
26.         mov     BYTE PTR [eax], dl
27. $LN3@Sort:
28.         add     eax, 1
29.         sub     esi, 1
30.         jne     SHORT $LL4@Sort
31. $LN6@Sort:
32. ; Line 54
33.         sub     ebp, 1
34.         jne     SHORT $LL7@Sort
35.         pop     esi
36.         pop     ebp
37. $LN5@Sort:
38. ; Line 62
39.         ret     0
40. ?Sort@@YAXPAEH@Z ENDP                                   ; Sort

Что неудивительно, всетаки JIT должен быстро компилировать, у него нет особо времени компилировать часами). Так что искать причины "тормознутости" c++ нужно в другом месте, возможно тут специально внесена незаметная закладка, например в измерении времени. Добавим сюда невозможность пока использования в JIT блоков MMX\XMM а так же низкоуровневых GPR интринзиков, например для инструкций bswap, bsr итд. что поддерживаются во всех современных компиляторах intel, msvs, gcc. Принципиально можно конечно сделать JIT с автовекторизацией, как в интел компиляторе(вставление векторных XMM инструкций), но это замедляет компиляцию, а мы то обычную тут не добиваем, потом отсутствие спец. встроенных типов делает анализ еще сложнее т.е. работать будет еще дольше, а качество анализа пока и в компилаторах неочень, короче такого пока нет нигде)

 

semen
Довольно смешная тема:

Не сразу люди додумали, как надо делать бенчмарки. Ты кстати в своем тесте использовал GetThreadTimes или то что в оригинале (GetSystemTimeAsFileTime)? У меня расхождение занимает впрочем для bubble всего около 1.5 секунды...
Итого 97 сек. для C# и 106.4 для нативного C++.

У меня кстати такой вот дизасм C# кода:

Код (Text):

1.              for( int i = 0; i < arr.Length; ++i )
2. 00000038  xor         edx,edx
3. 0000003a  mov         dword ptr [esp],edx
4. 0000003d  nop              
5. 0000003e  jmp         000000C0
6.                 for( int j = 1; j < arr.Length; ++j )
7. 00000043  mov         edi,1
8. 00000048  nop              
9. 00000049  jmp         000000B8
10.                     if( arr[ j ] < arr[ j - 1 ] )
11. 0000004b  cmp         edi,dword ptr [esi+4]
12. 0000004e  jb          00000055
13. 00000050  call        79442FC9
14. 00000055  movzx       eax,byte ptr [esi+edi+8]
15. 0000005a  lea         edx,[edi-1]
16. 0000005d  cmp         edx,dword ptr [esi+4]
17. 00000060  jb          00000067
18. 00000062  call        79442FC9
19. 00000067  cmp         al,byte ptr [esi+edx+8]
20. 0000006b  jae         000000B7
21.                     {
22.                         byte tmp = arr[ j - 1 ];
23. 0000006d  lea         eax,[edi-1]
24. 00000070  cmp         eax,dword ptr [esi+4]
25. 00000073  jb          0000007A
26. 00000075  call        79442FC9
27. 0000007a  movzx       eax,byte ptr [esi+eax+8]
28. 0000007f  mov         dword ptr [esp+4],eax
29.                         arr[ j - 1 ] = arr[ j ];
30. 00000083  cmp         edi,dword ptr [esi+4]
31. 00000086  jb          0000008D
32. 00000088  call        79442FC9
33. 0000008d  movzx       ebp,byte ptr [esi+edi+8]
34. 00000092  lea         eax,[edi-1]
35. 00000095  cmp         eax,dword ptr [esi+4]
36. 00000098  jb          0000009F
37. 0000009a  call        79442FC9
38. 0000009f  mov         edx,ebp
39. 000000a1  mov         byte ptr [esi+eax+8],dl
40.                         arr[ j ] = tmp;
41. 000000a5  cmp         edi,dword ptr [esi+4]
42. 000000a8  jb          000000AF
43. 000000aa  call        79442FC9
44. 000000af  mov         eax,dword ptr [esp+4]
45. 000000b3  mov         byte ptr [esi+edi+8],al
46.                 for( int j = 1; j < arr.Length; ++j )
47. 000000b7  inc         edi  
48. 000000b8  cmp         edi,dword ptr [esi+4]
49. 000000bb  jl          0000004B
50.             for( int i = 0; i < arr.Length; ++i )
51. 000000bd  inc         dword ptr [esp]
52. 000000c0  mov         eax,dword ptr [esp]
53. 000000c3  cmp         eax,dword ptr [esi+4]
54. 000000c6  jl          00000043
55.                     }

 

alpet Я запускал те проекты по линку as is на vs2005, ничего не менял. У тебя какие то call вставились, точно Release компилил и на 2005 студии? Может еще версии самого JIT`а отличаться...
UPD: точно, ты компилил дебаг.
Здесь гдето чтото не так, иначе придется признать что просто более неоптимальный с точки зрения асм программиста код работает быстрее из-за особенностей архитектуры, т.е. просто компилятор "перестарался"))

 

semen
Компилировал релиз. Настройки шарповского проекта вобщем не трогал совсем. Использовал встроенный отладчик студии. VS2k5 (v 8.0.50727.42) и .Net Framework 2.0.50727. Запускал так-же из под cmd.

Железо: P4.Presscott @ 2.8 Ghz (L2-1Mb), 1Gb RAM.

P.S. Бросилось в глаза, что call'ы отладчик пропускает при трассировке.