Написать тест для воспроизведения абсолютно неконтролируемого со стороны явления?

Это сообщение отредактировал(а) w1nd - 18.6.2008, 14:25

Какие дикие фантазии  

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

Ваши - протестировать влияние работы менеджера памяти ОС на скорость итерирования списка ;)


Ну вот вам черновик:


Что я упустил?

Я такого не писал, а если кто-то там такое узрел, это его личное воображение подсобило 



Зачем вообще нужно 2 массива? Тут уже одновременно идут 2 итерации, 2 последовательных или 1 последовательная и 1 непоследовательная.

у меня получилась разница во времени 4 раза.

Вы предложили написать тест в ответ на реплику про релокацию памяти. 


По вашей логике в моём тесте в вариант с последовательным итерированием должен работать всегда быстрее.


На моей рабочей машинке разница составляет 2 (P4); на домашней (CORE2; 64-битная jvm) разницы нет вообще. Имеете ещё что-то рассказать про кэш процессора?

Это сообщение отредактировал(а) w1nd - 19.6.2008, 15:06

Ну, чтож интересно, потестим, итак:




Машинка:
Intel P4 - 2.8ГГц 
RAM 1Гб

Celeron 2GHz RAM 1Gb

Вот ничего себе! интересный факт.

Добавлено через 38 секунд
размер 8 мегабайт

Эта фраза была сказана к дискуссии о кэше вообще, она даже специально отделена. Ну а кто как воспринял... 



Так у меня и быстрее: 63 миллисекунды против 1406 (я уменьшил размер до 20 000 000). Я неправильно тест запускаю? 



Пора проводить исследование на тему: "Влияние скепсиса на CPU, на примере Sun JRE" 

Погонял тест на Celeron M 900 MHz (до этого был P4 3.0 GHz) получил:
Мой тест:


Тест w1nd

Как пить дать  


Пора уже понять, что прогнозировать такие вещи, как поведение кэша, бессмысленно и бесполезно. Кстати, на 32-битной JRE на домашнем CORE2 в моём тесте (где не меряется заодно скорость JIT и вероятность перекомпиляции "горячего" метода) результаты аналогичны полученным на 64-битной (98 +- 10 ms).

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

А у нас в квартире газ. Содержательный разговор, не правда ли? Ваша ссылка вообще к чему?

Pentium 4 3ГГц

Sequential time: 1453 ms
Random time:     4047 ms
отношение 2.78

Sequential time: 1469 ms
Random time:     4219 ms
отношение 2.87

Sequential time: 1469 ms
Random time:     4469 ms
отношение 3.04

среднее отношение 2.9

Паралельно закрывал/открывал netbeans
Sequential time: 2468 ms
Random time:     6125 ms
отношение 2.48

Sequential time: 2438 ms
Random time:     6078 ms
отношение 2.49

среднее отношение 2.49

===============

Elapsed time: 343 ms
Elapsed time: 344 ms
Elapsed time: 343 ms
Среднее: 343 ms

Паралельно закрывал/открывал netbeans
Elapsed time: 656 ms
Elapsed time: 656 ms
Elapsed time: 750 ms
Elapsed time: 719 ms
Среднее: 695 ms

отношение 2.02

Random^

Elapsed time: 11000 ms
Elapsed time: 11015 ms
Elapsed time: 11016 ms
Среднее: 11015 ms (Пусть!)

Паралельно закрывал/открывал netbeans
Elapsed time: 12672 ms
Elapsed time: 11110 ms
Elapsed time: 13375 ms
Elapsed time: 12641 ms
Среднее: 12450 ms

отношение 1.13

К тому, что эти ребята пишут компилятор который оптимизирует код с учетом поведения процессора (в том числе и кэша). И при этом они не считают свою работу бессмысленной и бесполезной. Вот я и посоветовал пойти и просветить их

Не путайте <непроизносимое> с пальцем. Я где-нибудь говорил, что этот совет предназначен разработчикам КОМПИЛЯТОРОВ? Нет, не говорил. А что вы тут пытаетесь доказать?

Эти ребята (а также многие другие) сами скажут, что прогнозировать работу кэшей и блоков предсказания ветвлений не нужно и не полезно. Потому что это делает КОМПИЛЯТОР, если умеет. А всевозможные заточки непосредственно в коде в своё время очень плохо послужили пользователям процессоров P4, когда те вышли, ибо часть софта работала медленее не просто по причине отсутствия оптимизации под P4, а ещё и по причине оптимизации под P3.