На небольших 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.
