> обычный write barier. Да и по поведению в 1.1 vs 2.0 очень похоже.
вообще, write barier актуален только для reference полей (т.к. при изменении reference поля возможно изменение графа зависимостей объектов). Если же в поле хранится не reference тип то, при записи в данное поле никакой write barier не нужет т.к. такие поля не влияют на сборку мусора. Не знаю, как надо написать тест с матрицами что-бы write barier стал актуальным...
Posted via RSDN NNTP Server 1.9
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
На небольших nSize C# ничем не уступает C++. Правда, обращает на себя странная аномалия — при переходе от 500 к 600 время уменьшается. Это не артефакт — проверял дважды.
Резкий рост времени на С# начинается с 800. Переход к 900 — нормальный рост. Переход к 1000 — опять всплеск.
— там тоже баловались сравнением скорости C++ и C#. И результаты были как у тебя — начиная с определенного размера GC стал сдавать. Так что Америку ты не открыл.
— там тоже баловались сравнением скорости C++ и C#. И результаты были как у тебя — начиная с определенного размера GC стал сдавать. Так что Америку ты не открыл.
Т.е. в проделываемом тесте на каждой итерации матрица создается заново? Но это же безобразие.
— там тоже баловались сравнением скорости C++ и C#. И результаты были как у тебя — начиная с определенного размера GC стал сдавать. Так что Америку ты не открыл.
Mab>Т.е. в проделываемом тесте на каждой итерации матрица создается заново? Но это же безобразие.
Т.е. автору теста стоит ознакомиться с текстом, возможно тот натокнет его на некие выводы. А что уж там у него создается — я не знаю.
— там тоже баловались сравнением скорости C++ и C#. И результаты были как у тебя — начиная с определенного размера GC стал сдавать. Так что Америку ты не открыл.
Да я и не претендую на лавры Колумба. Хотя и не понимаю — почему здесь GC вообще вмешивается. Я-то здесь никакие объекты не создаю и не освобождаю.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Что-то странно он промахивается.
Скорее всего это перенос из популяций в популяцию. Просмотреть можно через Performance. Там выбрать как "Performance object" — NET CRL Memory, Counters — %Time In GC и допустим #Gen n Collections и можно еще кучу counterов подключить. Они могут показать сколько времени занимает GC, и сколько сборок мусора делает.
Здравствуйте, GlebZ, Вы писали:
GZ>Скорее всего это перенос из популяций в популяцию. Просмотреть можно через Performance. Там выбрать как "Performance object" — NET CRL Memory, Counters — %Time In GC и допустим #Gen n Collections и можно еще кучу counterов подключить. Они могут показать сколько времени занимает GC, и сколько сборок мусора делает.
Нет. ЖЦ тут вообще ни на что не влияет. Там объектов то копейки и занимаются они все до перемножения. Так что время действтилеьно уходит на промахи в кэше и может еще на райт-барьер.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>то есть нармальная квадратичная зависимость.
У меня PIV(2Г) — тоже самое, квадратичная последовательность. А вообще, именно перемножением матриц меряют эффективность сопроцессора.
Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, VladD2, Вы писали:
VD>>то есть нармальная квадратичная зависимость. GZ>У меня PIV(2Г) — тоже самое, НЕ квадратичная последовательность. А вообще, именно перемножением матриц меряют эффективность сопроцессора.
Одно слово забыл, а смысл обратный.
Просто варьирует на 1000 от 2 минут до 3. Стабильного времени алгоритма нет.
С уважением, Gleb.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Вот такие дела...
VD>Назовите модель своего процессора сэр. А народ должен знать чего лучше никогда не покупать.
VD>Попробую угадать его марку Цэ-лерон или какой-нить Симпсон. Короче то у чего кэш успевает закончиться даже не начавшись.
VD>ЗЫ
VD>У меня: VD>
Time 100 = 0,005173283
Time 200 = 0,04024897
Time 300 = 0,1676054
Time 400 = 0,6383289
Time 500 = 1,538195
Time 600 = 2,267745
Time 700 = 4,143095
Time 800 = 7,288717
Time 900 = 11,97331
Time 1000 = 18,38258
.NET 1.1.4322 SP1
Time 100 = 0,004150248
Time 200 = 0,0351419
Time 300 = 0,1544269
Time 400 = 0,6232547
Time 500 = 1,514088
Time 600 = 2,23681
Time 700 = 4,097188
Time 800 = 7,187719
Time 900 = 11,99186
Time 1000 = 18,31991
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Вот такие дела...
VD>Назовите модель своего процессора сэр. А народ должен знать чего лучше никогда не покупать.
Извольте, сэр! А покупать его не удастся — машине 3 года, увы
VD>Попробую угадать его марку Цэ-лерон или какой-нить Симпсон. Короче то у чего кэш успевает закончиться даже не начавшись.
Pentium IV 1600 MHz.
А может, попробовать Size 2000 — 3000 ? Интересно, что будет. Дело не в размере ведь...
И еще вопрос. А С++ на твоей машине для этих же размеров что дает ?
Здравствуйте, GlebZ, Вы писали:
GZ>>У меня PIV(2Г) — тоже самое, НЕ квадратичная последовательность. А вообще, именно перемножением матриц меряют эффективность сопроцессора.
Во времена оные классическим тестом считалось 50-кратное обращение матрицы.
GZ>Одно слово забыл, а смысл обратный. GZ>Просто варьирует на 1000 от 2 минут до 3. Стабильного времени алгоритма нет. GZ>С уважением, Gleb.
Вообще-то интересный эффект. На моих 1600 и твоих 2000 — примерно одна и та же картина, резко отличающаяся от того, что у VladD2 и Alexey Axyonov (он, правда, не сказал, какой у него процессор). А между тем С++ дает нормальные результаты.
Может, .Net специально на старых процессорах помедленнеее работает ? Чтобы апгрейдили их побыстрее ?
Пропустил я сейчас эти 2 теста для nSize = 1000 на других машинах
Pentium IV, 1.8 GHz, 736 Mb
С++ 16 сек.
C# 140 сек
Pentium IV, 2.8 GHz, 1 Gb
C++ 10 сек
C# 18 сек.
Таким образом, для машин с частотой <= 2GHz имеет место то, о чем я писал в исходном сообщении. Для машин с частотой порядка 3 GHz — то, о чем писал VladD2 и др.
Попробовал для nSize = 3000, на Pentium IV, 2.8 GHz, 1 Gb
С++ 296 сек.
С# 887 сек.
Помолился я богу и поставил nSize = 5000. Делать мне сегодня нечего, у нас олимпиада проходит, до конца ее еще 1.5 часа, мое вмешательство не требуется, все автоматизировано
С++ 2346 сек.
Для С# было ясно, что результатов я не дождусь. Поэтому изменил самый внешний цикл, поставив там 50 вместо 5000. Время для этого теста 124 сек. Так что на полный тест ориентировочное время 12400 сек.
Так что впечатление, что дело здесь не в процессоре. Просто на более мощном процессоре эффект проявляется тот же, только при больших размерах матрицы. На моей слабой машине тоже ведь разнийы практически не было при размерах до 300.
>> обычный write barier. Да и по поведению в 1.1 vs 2.0 очень похоже.
TK>вообще, write barier актуален только для reference полей (т.к. при изменении reference поля возможно изменение графа зависимостей объектов). Если же в поле хранится не reference тип то, при записи в данное поле никакой write barier не нужет т.к. такие поля не влияют на сборку мусора. Не знаю, как надо написать тест с матрицами что-бы write barier стал актуальным...
Я и сам бошку ломаю но
Но при доступе через [][] может быть придоступе ко второму массиву который может записываться во временную переменню.
А как там в GC реально M$ его знает
При последовательном проходе временная переменная один раз на весь цикл и этого эффекта не наблюдается.
Химия где то там. в 2.0 этого эффекта нет. Вообще в 1.1 write barier встречается часто там где его не должно быть. .В 2.0 многие места оптимизированы еще в альфе.
и солнце б утром не вставало, когда бы не было меня
There is a minor limitation in the current JIT compiler regarding the graceful elimination of bound checks on rectangular arrays, hence accessing a relatively small two-dimensional jagged array sequentially (row-by-row) might be quicker than accessing a two-dimensional rectangular array on some machines. The same will not be true for larger array sizes as jagged arrays will lose more time in fetching random elements from different locations in memory. You can approximate that the performance of a jagged array is inversely proportional to the number of elements accessed when not walking linearly through each row.
Jagged arrays perform miserably in cases when elements are accessed diagonally or randomly because of their poor locality. Rectangular arrays, on the other hand, seem to perform four to five times better than jagged arrays in such scenarios.
Здравствуйте, GlebZ, Вы писали:
GZ>У меня PIV(2Г) — тоже самое, квадратичная последовательность. А вообще, именно перемножением матриц меряют эффективность сопроцессора.
Какой еще в 21 веке сопроцессор? Если ты о плавающей точке, то в этом тесте ее вообще не используется. Так что это скорее тест на кэш процессора.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вообще-то интересный эффект. На моих 1600 и твоих 2000 — примерно одна и та же картина, резко отличающаяся от того, что у VladD2 и Alexey Axyonov (он, правда, не сказал, какой у него процессор). А между тем С++ дает нормальные результаты.
Ребятки у вас старые Пни 4. У них маленький кэш (256 КБ скорее всего, а может и с 128). У меня же процессор с 512 кэшем. Причем мой кэш L2 работает на частоте ядра. Вот и вся разница. Просто нетовские массивы на 8 байт больше чем С++-ные. Вот и вылетают видимо за пределы кэша.
PD>Может, .Net специально на старых процессорах помедленнеее работает ? Чтобы апгрейдили их побыстрее ?
Возможно оптимизация под AMD64 сделана чуть лучше. Но думаю, основное влияние оказывает размер кэша.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вообще-то интересный эффект. На моих 1600 и твоих 2000 — примерно одна и та же картина, резко отличающаяся от того, что у VladD2 и Alexey Axyonov (он, правда, не сказал, какой у него процессор). А между тем С++ дает нормальные результаты.
PD>Может, .Net специально на старых процессорах помедленнеее работает ? Чтобы апгрейдили их побыстрее ?
Испытал этот тест на значительно более медленном процессор PM 1.7 Ггц.
Результат получился 11 секунд у догтнетного теста и 9 у С++-ного.
Единственное что есть у это "более медленного" процессора — это 2 метровый кэш L2.
Так что теперь я почти уверен, что дело именно в размере кэша.
На всякий случай ниже я привел полное описание обоих процессоров сделанное Сандрой 2005 лайт.
AMD64 3400:
SiSoftware Sandra
Processor
Model : AMD Athlon(tm) 64 Processor 3500+
Speed : 2.25GHz
Model Number : 3500 (estimated)
Performance Rating : PR3371 (estimated)
Type : Standard
Package : FC µPGA939
Multiplier : 11/1x
Minimum/Maximum Multiplier : 11/1x / 11/1x
Generation : G8
Name : MF Athlon 64 (K8 ClawHammer) 90nm ?GHz+ ?V
Revision/Stepping : F / 0 (10D)
Stepping Mask : DH7-CG
Microcode : MU0FF03A
Core Voltage Rating : 1.500V
Min/Max Core Voltage : 1.500V / 1.550V
Maximum Physical / Virtual Addressing : 40-bit / 48-bit
Native Page Size : 4kB
Co-Processor (FPU)
Type : Built-in
Revision/Stepping : F / 0 (10D)
Processor Cache(s)
Internal Data Cache : 64kB Synchronous, Write-Back, 2-way set, 64 byte line size
Internal Instruction Cache : 64kB Synchronous, Write-Back, 2-way set, 64 byte line size
L2 On-board Cache : 512kB ECC Synchronous, Write-Back, 16-way set, 64 byte line size
L2 Cache Multiplier : 1/1x (2247MHz)
Upgradeability
Socket/Slot : Socket 939
Upgrade Interface : Unknown
Supported Speed(s) : 3.00GHz+
Features
FPU - Co-Processor Built-in : Yes
VME - Virtual Mode Extensions : Yes
DE - Debugging Extension : Yes
PSE - Page Size Extension : Yes
TSC - Time Stamp Counter : Yes
MSR - Model Specific Registers : Yes
PAE - Physical Address Extension : Yes
MCE - Machine Check Exception : Yes
CX8 - Compare & Exchange Instruction : Yes
APIC - Local APIC Built-in : Yes
SEP - Fast System Call : Yes
MTRR - Memory Type Range Registers : Yes
PGE - Page Global Enable : Yes
MCA - Machine Check Architecture : Yes
PAT - Page Attribute Table : Yes
PSE36 - 36-bit Page Size Extension : Yes
PSN - Unique Serial Number : No
CLF - Cache Line Flush Support : Yes
DS - Debug Trace & EMON Store : No
ACPI - Software Clock Control : No
(W)MMX Technology : Yes
FXSR - Fast Float Save & Restore : Yes
SSE Technology : Yes
SSE2 Technology : Yes
SS - Self Snoop : No
HTT - Hyper-Threading Technology : No
TM - Thermal Monitor : No
PBE - Pending Break Enable : No
IA64 Technology : No
SSE3 Technology : No
MON - Monitor/MWait : No
DSCPL - CPL qualified Debug Store : No
EST - Enhanced SpeedStep Technology : No
TM2 - Thermal Monitor 2 : No
CID - Context ID : No
xTPR - Send Task Priority Messages : No
DAZ - Denormals Are Zero : Yes
Extended Features
SYCR - Extended Fast System Call : Yes
EMMX - Extended MMX Technology : Yes
FXSR - Fast Float Save & Restore : Yes
FXSR - Instructions Optimisation : No
3DNow! Technology : Yes
Extended 3DNow! Technology : Yes
DEP/NX - No-execute Page Protection : Yes
AMD64/EM64T Technology : Yes
LAHF/SAHF - Support in Long Mode : No
CMP - Multi-Core Legacy Mode : No
Power Management Features
STC - Software Thermal Control : No
TM - Thermal Monitor : No
TTP - Thermal Trip : Yes
VID - Voltage Control : Yes
FID - Frequency Control : Yes
TS - Thermal Sensor Built-in : Yes
Advanced Settings
System Ack Limit : 1 request(s)
System Victim Limit : 0 request(s)
Extended MTRR Types : Yes
I/O Type Range Registers : Yes
Top of Memory : 40000000 (1024MB)
Machine Check Architecture Settings
Number of Reporting Banks : 5 bank(s)
Exception Reporting Control Support : Yes
Variable Range MTRR Settings
MTRR 0 : 00000000-3FFFFFFF (0MB-1024MB) WB
MTRR 1 : E0000000-E7FFFFFF (3584MB-3712MB) WC
Variable Range IORR Settings
IORR 1 : E0000000-E7FFFFFF (3584MB-3712MB) rdMem wrMem
Fixed Range MTRR Settings
MTRR 0 Range 0 : 00000000-0000FFFF (0kB-64kB) WB rdIO wrIO
MTRR 0 Range 1 : 00010000-0001FFFF (64kB-128kB) WB rdIO wrIO
MTRR 0 Range 2 : 00020000-0002FFFF (128kB-192kB) WB rdIO wrIO
MTRR 0 Range 3 : 00030000-0003FFFF (192kB-256kB) WB rdIO wrIO
MTRR 0 Range 4 : 00040000-0004FFFF (256kB-320kB) WB rdIO wrIO
MTRR 0 Range 5 : 00050000-0005FFFF (320kB-384kB) WB rdIO wrIO
MTRR 0 Range 6 : 00060000-0006FFFF (384kB-448kB) WB rdIO wrIO
MTRR 0 Range 7 : 00070000-0007FFFF (448kB-512kB) WB rdIO wrIO
MTRR 1 Range 0 : 00080000-00083FFF (512kB-528kB) WB rdIO wrIO
MTRR 1 Range 1 : 00084000-00087FFF (528kB-544kB) WB rdIO wrIO
MTRR 1 Range 2 : 00088000-0008BFFF (544kB-560kB) WB rdIO wrIO
MTRR 1 Range 3 : 0008C000-0008FFFF (560kB-576kB) WB rdIO wrIO
MTRR 1 Range 4 : 00090000-00093FFF (576kB-592kB) WB rdIO wrIO
MTRR 1 Range 5 : 00094000-00097FFF (592kB-608kB) WB rdIO wrIO
MTRR 1 Range 6 : 00098000-0009BFFF (608kB-624kB) WB rdIO wrIO
MTRR 1 Range 7 : 0009C000-0009FFFF (624kB-640kB) WB rdIO wrIO
MTRR 2 Range 0 : 000A0000-000A3FFF (640kB-656kB) UC rdIO wrIO
MTRR 2 Range 1 : 000A4000-000A7FFF (656kB-672kB) UC rdIO wrIO
MTRR 2 Range 2 : 000A8000-000ABFFF (672kB-688kB) UC rdIO wrIO
MTRR 2 Range 3 : 000AC000-000AFFFF (688kB-704kB) UC rdIO wrIO
MTRR 2 Range 4 : 000B0000-000B3FFF (704kB-720kB) UC rdIO wrIO
MTRR 2 Range 5 : 000B4000-000B7FFF (720kB-736kB) UC rdIO wrIO
MTRR 2 Range 6 : 000B8000-000BBFFF (736kB-752kB) UC rdIO wrIO
MTRR 2 Range 7 : 000BC000-000BFFFF (752kB-768kB) UC rdIO wrIO
MTRR 3 Range 0 : 000C0000-000C0FFF (768kB-772kB) WP rdIO wrIO
MTRR 3 Range 1 : 000C1000-000C1FFF (772kB-776kB) WP rdIO wrIO
MTRR 3 Range 2 : 000C2000-000C2FFF (776kB-780kB) WP rdIO wrIO
MTRR 3 Range 3 : 000C3000-000C3FFF (780kB-784kB) WP rdIO wrIO
MTRR 3 Range 4 : 000C4000-000C4FFF (784kB-788kB) WP rdIO wrIO
MTRR 3 Range 5 : 000C5000-000C5FFF (788kB-792kB) WP rdIO wrIO
MTRR 3 Range 6 : 000C6000-000C6FFF (792kB-796kB) WP rdIO wrIO
MTRR 3 Range 7 : 000C7000-000C7FFF (796kB-800kB) WP rdIO wrIO
MTRR 4 Range 0 : 000C8000-000C8FFF (800kB-804kB) UC rdIO wrIO
MTRR 4 Range 1 : 000C9000-000C9FFF (804kB-808kB) UC rdIO wrIO
MTRR 4 Range 2 : 000CA000-000CAFFF (808kB-812kB) UC rdIO wrIO
MTRR 4 Range 3 : 000CB000-000CBFFF (812kB-816kB) UC rdIO wrIO
MTRR 4 Range 4 : 000CC000-000CCFFF (816kB-820kB) UC rdIO wrIO
MTRR 4 Range 5 : 000CD000-000CDFFF (820kB-824kB) UC rdIO wrIO
MTRR 4 Range 6 : 000CE000-000CEFFF (824kB-828kB) UC rdIO wrIO
MTRR 4 Range 7 : 000CF000-000CFFFF (828kB-832kB) UC rdIO wrIO
MTRR 5 Range 0 : 000D0000-000D0FFF (832kB-836kB) WB rdIO wrIO
MTRR 5 Range 1 : 000D1000-000D1FFF (836kB-840kB) WB rdIO wrIO
MTRR 5 Range 2 : 000D2000-000D2FFF (840kB-844kB) WB rdIO wrIO
MTRR 5 Range 3 : 000D3000-000D3FFF (844kB-848kB) WB rdIO wrIO
MTRR 5 Range 4 : 000D4000-000D4FFF (848kB-852kB) WB rdIO wrIO
MTRR 5 Range 5 : 000D5000-000D5FFF (852kB-856kB) WB rdIO wrIO
MTRR 5 Range 6 : 000D6000-000D6FFF (856kB-860kB) WB rdIO wrIO
MTRR 5 Range 7 : 000D7000-000D7FFF (860kB-864kB) WB rdIO wrIO
MTRR 6 Range 0 : 000D8000-000D8FFF (864kB-868kB) UC rdIO wrIO
MTRR 6 Range 1 : 000D9000-000D9FFF (868kB-872kB) UC rdIO wrIO
MTRR 6 Range 2 : 000DA000-000DAFFF (872kB-876kB) UC rdIO wrIO
MTRR 6 Range 3 : 000DB000-000DBFFF (876kB-880kB) UC rdIO wrIO
MTRR 6 Range 4 : 000DC000-000DCFFF (880kB-884kB) UC rdIO wrIO
MTRR 6 Range 5 : 000DD000-000DDFFF (884kB-888kB) UC rdIO wrIO
MTRR 6 Range 6 : 000DE000-000DEFFF (888kB-892kB) UC rdIO wrIO
MTRR 6 Range 7 : 000DF000-000DFFFF (892kB-896kB) UC rdIO wrIO
MTRR 7 Range 0 : 000E0000-000E0FFF (896kB-900kB) UC rdIO wrIO
MTRR 7 Range 1 : 000E1000-000E1FFF (900kB-904kB) UC rdIO wrIO
MTRR 7 Range 2 : 000E2000-000E2FFF (904kB-908kB) UC rdIO wrIO
MTRR 7 Range 3 : 000E3000-000E3FFF (908kB-912kB) UC rdIO wrIO
MTRR 7 Range 4 : 000E4000-000E4FFF (912kB-916kB) UC rdIO wrIO
MTRR 7 Range 5 : 000E5000-000E5FFF (916kB-920kB) UC rdIO wrIO
MTRR 7 Range 6 : 000E6000-000E6FFF (920kB-924kB) UC rdIO wrIO
MTRR 7 Range 7 : 000E7000-000E7FFF (924kB-928kB) UC rdIO wrIO
MTRR 8 Range 0 : 000E8000-000E8FFF (928kB-932kB) UC rdIO wrIO
MTRR 8 Range 1 : 000E9000-000E9FFF (932kB-936kB) UC rdIO wrIO
MTRR 8 Range 2 : 000EA000-000EAFFF (936kB-940kB) UC rdIO wrIO
MTRR 8 Range 3 : 000EB000-000EBFFF (940kB-944kB) UC rdIO wrIO
MTRR 8 Range 4 : 000EC000-000ECFFF (944kB-948kB) UC rdIO wrIO
MTRR 8 Range 5 : 000ED000-000EDFFF (948kB-952kB) UC rdIO wrIO
MTRR 8 Range 6 : 000EE000-000EEFFF (952kB-956kB) UC rdIO wrIO
MTRR 8 Range 7 : 000EF000-000EFFFF (956kB-960kB) UC rdIO wrIO
MTRR 9 Range 0 : 000F0000-000F0FFF (960kB-964kB) UC rdIO wrIO
MTRR 9 Range 1 : 000F1000-000F1FFF (964kB-968kB) UC rdIO wrIO
MTRR 9 Range 2 : 000F2000-000F2FFF (968kB-972kB) UC rdIO wrIO
MTRR 9 Range 3 : 000F3000-000F3FFF (972kB-976kB) UC rdIO wrIO
MTRR 9 Range 4 : 000F4000-000F4FFF (976kB-980kB) UC rdIO wrIO
MTRR 9 Range 5 : 000F5000-000F5FFF (980kB-984kB) UC rdIO wrIO
MTRR 9 Range 6 : 000F6000-000F6FFF (984kB-988kB) UC rdIO wrIO
MTRR 9 Range 7 : 000F7000-000F7FFF (988kB-992kB) UC rdIO wrIO
MTRR 10 Range 0 : 000F8000-000F8FFF (992kB-996kB) UC rdIO wrIO
MTRR 10 Range 1 : 000F9000-000F9FFF (996kB-1000kB) UC rdIO wrIO
MTRR 10 Range 2 : 000FA000-000FAFFF (1000kB-1004kB) UC rdIO wrIO
MTRR 10 Range 3 : 000FB000-000FBFFF (1004kB-1008kB) UC rdIO wrIO
MTRR 10 Range 4 : 000FC000-000FCFFF (1008kB-1012kB) UC rdIO wrIO
MTRR 10 Range 5 : 000FD000-000FDFFF (1012kB-1016kB) UC rdIO wrIO
MTRR 10 Range 6 : 000FE000-000FEFFF (1016kB-1020kB) UC rdIO wrIO
MTRR 10 Range 7 : 000FF000-000FFFFF (1020kB-1024kB) UC rdIO wrIO
PAT Settings
PAT 0 : WB
PAT 1 : WC
PAT 2 : UC-
PAT 3 : UC
PAT 4 : WB
PAT 5 : WC
PAT 6 : UC-
PAT 7 : UC
Performance Tips
Tip 210 : Mainboard supports faster CPUs, so the CPU can be upgraded when needed.
Notice 224 : SMBIOS/DMI information may be inaccurate.
Tip 2 : Double-click tip or press Enter while a tip is selected for more information about the tip.
PM 1.7:
SiSoftware Sandra
Processor
Model : Intel(R) Pentium(R) M processor 1.70GHz
Speed : 1.70GHz
Performance Rating : PR2040 (estimated)
Type : Mobile
Package : FC µPGA479M
Rated Speed/FSB : 1700MHz / 4x 100MHz
Multiplier : 17/1x
Minimum/Maximum Multiplier : 6/1x / 17/1x
Generation : G6
Name : P3D (Dothan) Pentium M 90nm 1.7+GHz 0.9-1.5V
Revision/Stepping : D / 6 (16)
Stepping Mask : B1
Microcode : MU06D617
Core Voltage Rating : 1.340V
Maximum Physical / Virtual Addressing : 32-bit / 32-bit
Native Page Size : 4kB
Part Number : To Be Filled By O.E.M.
Asset Tag : To Be Filled By O.E.M.
Serial Number : To Be Filled By O.E.M.
Co-Processor (FPU)
Type : Built-in
Revision/Stepping : D / 6 (16)
Processor Cache(s)
Internal Data Cache : 32kB Synchronous, Write-Back, 8-way set, 64 byte line size
Internal Instruction Cache : 32kB Synchronous, Write-Back, 8-way set, 64 byte line size
L2 On-board Cache : 2MB ECC Synchronous, ATC, 8-way set, 64 byte line size
L2 Cache Multiplier : 1/1x (1700MHz)
Upgradeability
Socket/Slot : CPU 1
Upgrade Interface : Other
Supported Speed(s) : 1.70GHz+
Processor Power Management
Processor Throttling Enabled : Yes
Throttle Range : 13% - 100%
Features
FPU - Co-Processor Built-in : Yes
VME - Virtual Mode Extensions : Yes
DE - Debugging Extension : Yes
PSE - Page Size Extension : Yes
TSC - Time Stamp Counter : Yes
MSR - Model Specific Registers : Yes
PAE - Physical Address Extension : No
MCE - Machine Check Exception : Yes
CX8 - Compare & Exchange Instruction : Yes
APIC - Local APIC Built-in : Yes
SEP - Fast System Call : Yes
MTRR - Memory Type Range Registers : Yes
PGE - Page Global Enable : Yes
MCA - Machine Check Architecture : Yes
PAT - Page Attribute Table : Yes
PSE36 - 36-bit Page Size Extension : No
PSN - Unique Serial Number : No
CLF - Cache Line Flush Support : Yes
DS - Debug Trace & EMON Store : Yes
ACPI - Software Clock Control : Yes
(W)MMX Technology : Yes
FXSR - Fast Float Save & Restore : Yes
SSE Technology : Yes
SSE2 Technology : Yes
SS - Self Snoop : Yes
HTT - Hyper-Threading Technology : No
TM - Thermal Monitor : Yes
PBE - Pending Break Enable : Yes
SSE3 Technology : No
MON - Monitor/MWait : No
DSCPL - CPL qualified Debug Store : No
EST - Enhanced SpeedStep Technology : Yes
TM2 - Thermal Monitor 2 : Yes
DAZ - Denormals Are Zero : Yes
Advanced Settings
L2 Cacheable Range : 4GB
Data Error Checking : No
IO Queue Depth : 8 request(s)
EST - Enhanced SpeedStep Technology : Yes
TM - Thermal Monitor : Yes
TM2 - Thermal Monitor 2 : No
Machine Check Architecture Settings
Number of Reporting Banks : 5 bank(s)
Variable Range MTRR Settings
MTRR 0 : 00000000-3FFFFFFF (0MB-1024MB) WB
Fixed Range MTRR Settings
MTRR 0 Range 0 : 00000000-0000FFFF (0kB-64kB) WB
MTRR 0 Range 1 : 00010000-0001FFFF (64kB-128kB) WB
MTRR 0 Range 2 : 00020000-0002FFFF (128kB-192kB) WB
MTRR 0 Range 3 : 00030000-0003FFFF (192kB-256kB) WB
MTRR 0 Range 4 : 00040000-0004FFFF (256kB-320kB) WB
MTRR 0 Range 5 : 00050000-0005FFFF (320kB-384kB) WB
MTRR 0 Range 6 : 00060000-0006FFFF (384kB-448kB) WB
MTRR 0 Range 7 : 00070000-0007FFFF (448kB-512kB) WB
MTRR 1 Range 0 : 00080000-00083FFF (512kB-528kB) WB
MTRR 1 Range 1 : 00084000-00087FFF (528kB-544kB) WB
MTRR 1 Range 2 : 00088000-0008BFFF (544kB-560kB) WB
MTRR 1 Range 3 : 0008C000-0008FFFF (560kB-576kB) WB
MTRR 1 Range 4 : 00090000-00093FFF (576kB-592kB) WB
MTRR 1 Range 5 : 00094000-00097FFF (592kB-608kB) WB
MTRR 1 Range 6 : 00098000-0009BFFF (608kB-624kB) WB
MTRR 1 Range 7 : 0009C000-0009FFFF (624kB-640kB) WB
MTRR 2 Range 0 : 000A0000-000A3FFF (640kB-656kB) UC
MTRR 2 Range 1 : 000A4000-000A7FFF (656kB-672kB) UC
MTRR 2 Range 2 : 000A8000-000ABFFF (672kB-688kB) UC
MTRR 2 Range 3 : 000AC000-000AFFFF (688kB-704kB) UC
MTRR 2 Range 4 : 000B0000-000B3FFF (704kB-720kB) UC
MTRR 2 Range 5 : 000B4000-000B7FFF (720kB-736kB) UC
MTRR 2 Range 6 : 000B8000-000BBFFF (736kB-752kB) UC
MTRR 2 Range 7 : 000BC000-000BFFFF (752kB-768kB) UC
MTRR 3 Range 0 : 000C0000-000C0FFF (768kB-772kB) UC
MTRR 3 Range 1 : 000C1000-000C1FFF (772kB-776kB) UC
MTRR 3 Range 2 : 000C2000-000C2FFF (776kB-780kB) UC
MTRR 3 Range 3 : 000C3000-000C3FFF (780kB-784kB) UC
MTRR 3 Range 4 : 000C4000-000C4FFF (784kB-788kB) UC
MTRR 3 Range 5 : 000C5000-000C5FFF (788kB-792kB) UC
MTRR 3 Range 6 : 000C6000-000C6FFF (792kB-796kB) UC
MTRR 3 Range 7 : 000C7000-000C7FFF (796kB-800kB) UC
MTRR 4 Range 0 : 000C8000-000C8FFF (800kB-804kB) UC
MTRR 4 Range 1 : 000C9000-000C9FFF (804kB-808kB) UC
MTRR 4 Range 2 : 000CA000-000CAFFF (808kB-812kB) UC
MTRR 4 Range 3 : 000CB000-000CBFFF (812kB-816kB) UC
MTRR 4 Range 4 : 000CC000-000CCFFF (816kB-820kB) UC
MTRR 4 Range 5 : 000CD000-000CDFFF (820kB-824kB) UC
MTRR 4 Range 6 : 000CE000-000CEFFF (824kB-828kB) UC
MTRR 4 Range 7 : 000CF000-000CFFFF (828kB-832kB) UC
MTRR 5 Range 0 : 000D0000-000D0FFF (832kB-836kB) UC
MTRR 5 Range 1 : 000D1000-000D1FFF (836kB-840kB) UC
MTRR 5 Range 2 : 000D2000-000D2FFF (840kB-844kB) UC
MTRR 5 Range 3 : 000D3000-000D3FFF (844kB-848kB) UC
MTRR 5 Range 4 : 000D4000-000D4FFF (848kB-852kB) UC
MTRR 5 Range 5 : 000D5000-000D5FFF (852kB-856kB) UC
MTRR 5 Range 6 : 000D6000-000D6FFF (856kB-860kB) UC
MTRR 5 Range 7 : 000D7000-000D7FFF (860kB-864kB) UC
MTRR 6 Range 0 : 000D8000-000D8FFF (864kB-868kB) UC
MTRR 6 Range 1 : 000D9000-000D9FFF (868kB-872kB) UC
MTRR 6 Range 2 : 000DA000-000DAFFF (872kB-876kB) UC
MTRR 6 Range 3 : 000DB000-000DBFFF (876kB-880kB) UC
MTRR 6 Range 4 : 000DC000-000DCFFF (880kB-884kB) UC
MTRR 6 Range 5 : 000DD000-000DDFFF (884kB-888kB) UC
MTRR 6 Range 6 : 000DE000-000DEFFF (888kB-892kB) UC
MTRR 6 Range 7 : 000DF000-000DFFFF (892kB-896kB) UC
MTRR 7 Range 0 : 000E0000-000E0FFF (896kB-900kB) WT
MTRR 7 Range 1 : 000E1000-000E1FFF (900kB-904kB) WT
MTRR 7 Range 2 : 000E2000-000E2FFF (904kB-908kB) WT
MTRR 7 Range 3 : 000E3000-000E3FFF (908kB-912kB) WT
MTRR 7 Range 4 : 000E4000-000E4FFF (912kB-916kB) WT
MTRR 7 Range 5 : 000E5000-000E5FFF (916kB-920kB) WT
MTRR 7 Range 6 : 000E6000-000E6FFF (920kB-924kB) WT
MTRR 7 Range 7 : 000E7000-000E7FFF (924kB-928kB) WT
MTRR 8 Range 0 : 000E8000-000E8FFF (928kB-932kB) WT
MTRR 8 Range 1 : 000E9000-000E9FFF (932kB-936kB) WT
MTRR 8 Range 2 : 000EA000-000EAFFF (936kB-940kB) WT
MTRR 8 Range 3 : 000EB000-000EBFFF (940kB-944kB) WT
MTRR 8 Range 4 : 000EC000-000ECFFF (944kB-948kB) WT
MTRR 8 Range 5 : 000ED000-000EDFFF (948kB-952kB) WT
MTRR 8 Range 6 : 000EE000-000EEFFF (952kB-956kB) WT
MTRR 8 Range 7 : 000EF000-000EFFFF (956kB-960kB) WT
MTRR 9 Range 0 : 000F0000-000F0FFF (960kB-964kB) WP
MTRR 9 Range 1 : 000F1000-000F1FFF (964kB-968kB) WP
MTRR 9 Range 2 : 000F2000-000F2FFF (968kB-972kB) WP
MTRR 9 Range 3 : 000F3000-000F3FFF (972kB-976kB) WP
MTRR 9 Range 4 : 000F4000-000F4FFF (976kB-980kB) WP
MTRR 9 Range 5 : 000F5000-000F5FFF (980kB-984kB) WP
MTRR 9 Range 6 : 000F6000-000F6FFF (984kB-988kB) WP
MTRR 9 Range 7 : 000F7000-000F7FFF (988kB-992kB) WP
MTRR 10 Range 0 : 000F8000-000F8FFF (992kB-996kB) WP
MTRR 10 Range 1 : 000F9000-000F9FFF (996kB-1000kB) WP
MTRR 10 Range 2 : 000FA000-000FAFFF (1000kB-1004kB) WP
MTRR 10 Range 3 : 000FB000-000FBFFF (1004kB-1008kB) WP
MTRR 10 Range 4 : 000FC000-000FCFFF (1008kB-1012kB) WP
MTRR 10 Range 5 : 000FD000-000FDFFF (1012kB-1016kB) WP
MTRR 10 Range 6 : 000FE000-000FEFFF (1016kB-1020kB) WP
MTRR 10 Range 7 : 000FF000-000FFFFF (1020kB-1024kB) WP
PAT Settings
PAT 0 : WB
PAT 1 : WC
PAT 2 : UC-
PAT 3 : UC
PAT 4 : WB
PAT 5 : WC
PAT 6 : UC-
PAT 7 : UC
Performance Tips
Notice 224 : SMBIOS/DMI information may be inaccurate.
Tip 2 : Double-click tip or press Enter while a tip is selected for more information about the tip.
Так что "кэш" (наличные значитси) решит все ваши проблемы .
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Pentium IV 1600 MHz.
Какого размера кэш? Если не знашь, то зайди сюда http://www.sisoftware.net/ и скачай Сандру. В ней есть подробнейшая информация о процессоре.
PD>А может, попробовать Size 2000 — 3000 ? Интересно, что будет. Дело не в размере ведь...
Боюсь время увеличится просто из-за квадратичного алгоритма.
Ладно... попробуем... Итак на 2000 под дотнетом на AMD64 время составило:
Size: 2000 Time: 00:03:22.9137771
C++^
Size: 2000 Time: 137
то есть 2.28 минуты. Данную разницу уже можно скорее списать на проверки выхода за границы массивов, так как это приблизительно те же самые 25%.
Тоже самое но на PM 1.7 Ггц C#:
Size: 2000 Time: 00:01:40.1815673
C++:
Size: 2000 Time: 74
то есть 1.23 минуты.
PD>И еще вопрос. А С++ на твоей машине для этих же размеров что дает ?
А что он еще даст если даже на 1000 разница не велика?
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, GlebZ, Вы писали:
GZ>>У меня PIV(2Г) — тоже самое, квадратичная последовательность. А вообще, именно перемножением матриц меряют эффективность сопроцессора.
VD>Какой еще в 21 веке сопроцессор? Если ты о плавающей точке, то в этом тесте ее вообще не используется. Так что это скорее тест на кэш процессора.
Ну да правда? Посмотри дизассемблер через cordbg с оптимизацией. У меня на Net 2.0 и movq встречаются.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Пропустил я сейчас эти 2 теста для nSize = 1000 на других машинах
PD>Pentium IV, 1.8 GHz, 736 Mb PD>С++ 16 сек. PD>C# 140 сек
Что-то больно сказочный результат. 16 секунд дохлятина вроде P4 1.8 выжать не должна. У меня на 3-х гигогерцовом процессоре результат был 13 секунд.
PD>Pentium IV, 2.8 GHz, 1 Gb
PD>C++ 10 сек PD>C# 18 сек.
PD>Таким образом, для машин с частотой <= 2GHz имеет место то, о чем я писал в исходном сообщении. Для машин с частотой порядка 3 GHz — то, о чем писал VladD2 и др.
Гигогерцы тут не причем. Влияние оказывает исключительно кэш и его характеристики. На моем PM 1.7 (напомню, что по сути это Пентиум 3 у которого 2 метра кэша) получается 11 и 9 секунд соотвественно.
PD>Попробовал для nSize = 3000, на Pentium IV, 2.8 GHz, 1 Gb
PD>С++ 296 сек. PD>С# 887 сек.
А это уже совсем сказочный результат. Тут данные уже должны были по любому выйти за кэш.
PD>Помолился я богу и поставил nSize = 5000. Делать мне сегодня нечего, у нас олимпиада проходит, до конца ее еще 1.5 часа, мое вмешательство не требуется, все автоматизировано
PD>С++ 2346 сек.
PD>Для С# было ясно, что результатов я не дождусь. Поэтому изменил самый внешний цикл, поставив там 50 вместо 5000. Время для этого теста 124 сек. Так что на полный тест ориентировочное время 12400 сек.
Совершенно бещссмысленные рассуждения. На 5000 оба теста вылетят из кэша и подение производительности будет приблизительно одинаковое. Разница должна составить процентов 20. У меня уже за 1000 на П4 наблюдается совершенно одинаковый прогресс.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, GlebZ, Вы писали:
VD>>Какой еще в 21 веке сопроцессор? Если ты о плавающей точке, то в этом тесте ее вообще не используется. Так что это скорее тест на кэш процессора. GZ>Ну да правда?
Сопроцессоры начиная с 486 DX встрены в процессор и являются его неотемлемой частью.
GZ>Посмотри дизассемблер через cordbg с оптимизацией. У меня на Net 2.0 и movq встречаются.
movq — это, если мне не изменяет память, команда ММХ. Причем совершенно целочисленная — пересылка данных между регистрами и памятью.
Еще раз повторяю. Тест не содержит плавающей точки в принципе.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Испытал этот тест на значительно более медленном процессор PM 1.7 Ггц. VD>Результат получился 11 секунд у догтнетного теста и 9 у С++-ного.
VD>Единственное что есть у это "более медленного" процессора — это 2 метровый кэш L2.
VD>Так что теперь я почти уверен, что дело именно в размере кэша.
А почему тогда этот маленький кэш не влияет на C++ ?
PD>>Pentium IV, 1.8 GHz, 736 Mb PD>>С++ 16 сек. PD>>C# 140 сек
VD>Что-то больно сказочный результат. 16 секунд дохлятина вроде P4 1.8 выжать не должна. У меня на 3-х гигогерцовом процессоре результат был 13 секунд.
Так ведь такой же результат был и на моем P4 1.6. Дает. Сказочный или нет, а дает.
PD>>Попробовал для nSize = 3000, на Pentium IV, 2.8 GHz, 1 Gb
PD>>С++ 296 сек. PD>>С# 887 сек.
VD>А это уже совсем сказочный результат. Тут данные уже должны были по любому выйти за кэш.
Влад, я пишу то, что вижу. Сказочный или нет — не знаю.
VD>Совершенно бещссмысленные рассуждения. На 5000 оба теста вылетят из кэша и подение производительности будет приблизительно одинаковое. Разница должна составить процентов 20. У меня уже за 1000 на П4 наблюдается совершенно одинаковый прогресс.
Чем рассуждать о бессмысленности рассуждений, приведи лучше данные, какие у тебя получились на 5000. Для C++ и C#. Чтобы ты не говорил, что я предлагаю тебе четырехчасовой тест, сделай как и я — внешний цикл до 50, внутренние до 5000 и результат умножь на 100.
Здравствуйте, GlebZ, Вы писали:
GZ>[q] GZ>There is a minor limitation in the current JIT compiler regarding the graceful elimination of bound checks on rectangular arrays, hence accessing a relatively small two-dimensional jagged array sequentially (row-by-row) might be quicker than accessing a two-dimensional rectangular array on some machines.
Это так и есть. Если массив b расположить по столбцам, то в итоге быстрее, чем для двумерных массивов.
GZ>Jagged arrays perform miserably in cases when elements are accessed diagonally or randomly because of their poor locality.
А это к моему случаю не относится. Я не прохожу элементы diagonally or randomly.
Здравствуйте, VladD2, Вы писали:
VD>Сопроцессоры начиная с 486 DX встрены в процессор и являются его неотемлемой частью.
Кто бы возражал. Но инструкции сопроцессора ведь остались.
GZ>>Посмотри дизассемблер через cordbg с оптимизацией. У меня на Net 2.0 и movq встречаются.
VD>movq — это, если мне не изменяет память, команда ММХ. Причем совершенно целочисленная — пересылка данных между регистрами и памятью.
Это я так, для примера Просто не ожидал встретить MMX.
VD>Еще раз повторяю. Тест не содержит плавающей точки в принципе.
Это еще почему. Как тебе такое:
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, GlebZ, Вы писали:
PD>А это к моему случаю не относится. Я не прохожу элементы diagonally or randomly.
Какая разница как это называется. Ты обращаешься к разным массивам. Значения распределены по месту и непоследовательны. Можно считать что диагональ обладает такими же свойствами.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Alexey Axyonov, Вы писали:
AA>>Time 1000 = 18,20987 AA>>Time 2000 = 214,3378
PD>Не понял. Это C++ или C# ? И все же, просьба — проверь на 5000. На обоих языках. Внешний цикл до 50, внутренние до 5000 и результат умножь на 100.
Это был C#. Сегодня попробую запустить на AthlonXP 2500+ 512k cache.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Я что-то плохо понимаю. Там же матрицы из float. Как же умножение их элементов идет, эмуляцией, что ли, как в добрые DOS-овскме времена ?
Ой, это я что-то напутал. Что-то в друг вголову засело, что массивы бвли целочисленные. Конечно массивы float... В общем фигню говорю.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Ну, вот и смотри зависимость. Самый быстрый оказался Pentium M 1.7 Ггц. Частота у него самая дохлая, но кэш метровый.
Воторой к финишу пришел AMD64 с реальной частотой 2.2 Ггц. Частота у него выше, но кэш полуметровый, т.е. в два раза меньший. Третьим к финишу пришел Pentium 4 3.0 Ггц. Частота у него заоблочная, а кэш четверть метра. При этом именно Pentium 4 очень боится сбросов кэша и конвеера команд, так как имеет очень длинный конвеер и его перезаполнение дико дорого. Видимо после какого-то раммера массива кэш и конвеер начинает сбрасываться и приходит приплызд.
По хорошему нужно бы поиграться с настройками компилятора С++. Задать ему генерацию кода под SSE/MMX и потом наоборот для Pentium (1). Ну, чтобы поглядеть какие при этом изменения в производительности происходят.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, VladD2, Вы писали:
VD>>то есть нармальная квадратичная зависимость.
PD>Да здравствует Net Framework, который для кубического алгоритма обеспечивает квадратичную зависимость!
Не да здравсвтвует Интел который умудрился сделать процессор который хуже чем предыдущие поколения.
PD>P.S. А нельзя ли с его помощью NP-полные задачи свести к полиномиальным ?
Пробуй. Как известно терпение и труд все перепрут.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Pavel Dvorkin, Вы писали:
VD>>Что-то больно сказочный результат. 16 секунд дохлятина вроде P4 1.8 выжать не должна. У меня на 3-х гигогерцовом процессоре результат был 13 секунд.
PD>Так ведь такой же результат был и на моем P4 1.6. Дает. Сказочный или нет, а дает.
Ага. А еще почти такой же на моем P4 3.0. Не кажется странным?
VD>>А это уже совсем сказочный результат. Тут данные уже должны были по любому выйти за кэш.
PD>Влад, я пишу то, что вижу. Сказочный или нет — не знаю.
Ну, значит кроме сброса кэша есть еще какая-то причина. Но чтобы ее осмыслить нужно уже совсем на разбор отдельных инструкций переходить.
Если интересно можно дизасемблировать код генерируемый джитом для разных процессоров и сравнить его с С++-ным. Но это уже очень серьезная задачка. К тому же я в новых инструкциях не очень секу. Да и вообще ассемблер недолюбливаю.
PD>Чем рассуждать о бессмысленности рассуждений, приведи лучше данные, какие у тебя получились на 5000. Для C++ и C#. Чтобы ты не говорил, что я предлагаю тебе четырехчасовой тест, сделай как и я — внешний цикл до 50, внутренние до 5000 и результат умножь на 100.
Да, мне пофигу что компьютеры делают когда меня нет. Ладно, запустил тут на P4 (на других процессорах разница в процентах от увеличения матрицы, после 800, не изменяется).
Итак 5000 на P4 C#:
7:33:45 (короче 7 с половиной часов :)) ).
С++:
04:12:45 (то есть 15165 сек).
То есть разница менее чем в два раза. Так что не знаю что там, у тебя получается. Конечно 2 раза это не 20 процентов, но и не 14 раз все же.
... << RSDN@Home 1.2.0 alpha rev. 618>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
PD>>Чем рассуждать о бессмысленности рассуждений, приведи лучше данные, какие у тебя получились на 5000. Для C++ и C#. Чтобы ты не говорил, что я предлагаю тебе четырехчасовой тест, сделай как и я — внешний цикл до 50, внутренние до 5000 и результат умножь на 100.
VD>Да, мне пофигу что компьютеры делают когда меня нет. Ладно, запустил тут на P4 (на других процессорах разница в процентах от увеличения матрицы, после 800, не изменяется). VD>Итак 5000 на P4
