AMD или Intel а так-же бренд memory - страница 11

 
Mathemat >>:
Спасибо, four2one. Короче, число ядер для МТ4 не играет абсолютно никакой рояли :)

Полностью согласен, важнее кол-во памяти да и то не для скорости.

 
four2one >>:

Полностью согласен, важнее кол-во памяти да и то не для скорости.

важнее не количество памяти, хотя оно и не последнее, а скорость шины проца и памяти..

селерон хорошие результаты выдал, т.к. шина у него 800MHz

 
keekkenen >>:

важнее не количество памяти, хотя оно и не последнее, а скорость шины проца и памяти..

селерон хорошие результаты выдал, т.к. шина у него 800MHz


Я вообще не уверен, что он с памятью в процессе выполнения скрипта общался. Весь нативный (машинный) код мог влезть в кэш. Потому про советник и толкую. ПСС в случае оптимизации советника будет критична. А так ... это доказывает то, что я уже говорил: выч. ядро, что у i7, что у Pentium практчески одно и то же.

 
Svinozavr >>:

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

прикольно.. сомневаюсь что терминал работает на прямую с кешем проца в обход памяти, где сам вместе со скриптом и прописался..

 
keekkenen >>:

прикольно.. сомневаюсь что терминал работает на прямую с кешем проца в обход памяти, где сам вместе со скриптом и прописался..

А чего тут прикольного? Процессор подгружает код (машинные команды) в свой кэш. Для этого он, собственно, и нужен. Хоть из памяти, хоть откуда. Если влез весь код, то больше камень с памятью не общается, а берет инструкции из кэша и рубит их в ядре. Если бы он брал инструкции из памяти, то это было б на порядок медленнее.

Потому, чем больше кэш, тем быстрее обычно выполняются проги. А такие проги, как тест-скрипт, вернее сгенерированный из байт кода МТ4 нативный код вполне может влезть в мои сраные 1 мб кэша.

 
я про то что с памятью не общается.. поскольку под выполнением понимаю не только отработку скрипта, но и его загрузку и возвращение результата..
 
keekkenen >>:
я про то что с памятью не общается.. поскольку под выполнением понимаю не только отработку скрипта, но и его загрузку и возвращение результата..

А я вот исключительно про процесс выполнения!

Т.к. ни загрузка скрипта в кэш, ни вывод результата в нашем случае на скорость не влияет. Загрузить код в кэш из памяти разом - очень быстрая операция. А вот выбирать из нее команды поодиночке - медленная. На этом идея кэша и основана. Про вывод данных я вообще молчу. Какой тут вывод?

Потому - еще раз!!! - этот тест не репрезентативен! Нужно, чтоб камень общался с памятью. История котировок, например, в кэш влезать не обязана.

 
Svinozavr >>:

А я вот исключительно про процесс выполнения!

Т.к. ни загрузка скрипта в кэш, ни вывод результата в нашем случае на скорость не влияет. Загрузить код в кэш из памяти разом - очень быстрая операция. А вот выбирать из нее команды поодиночке - медленная. На этом идея кэша и основана. Про вывод данных я вообще молчу. Какой тут вывод?

Потому - еще раз!!! - этот тест не репрезентативен! Нужно, чтоб камень общался с памятью. История котировок, например, в кэш влезать не обязана.

Ну дык, вводим: одна из операций теста присвоение переменной clos'ом по циклу

попутно можно поделить на аск например... ;)

start=GetTickCount();
for(i=0; i<1000000; i++) {tt=iOpen[i];} 
test2=GetTickCount()-start; 


 

или нет, не клосом а локальным временем!

start=GetTickCount();
for(i=0; i<1000000; i++) {tt=TimeLocal();} 
test2=GetTickCount()-start; 
Понятное дело что в течении секунды нескольких оно мало изменится, но обращение то будет. ?
 
kombat >>:

Ну дык, вводим: одна из операций теста присвоение переменной clos'ом по циклу

попутно можно поделить на аск например... ;)

Ну... можно. Только зачем? Слушайте, а в чем проблема взять стандартный советник из МТ4? Нас ведь оптимизация интересует, а не абстрактные скрипты. Сохранить историю в архив и выложить ее вместе с тест-советником, чтоб все тестили на одном и том же. Довориться об оптимизуремых параметрах в советнике и их диапазонах. И все...

Причина обращения: