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

 
begemot61 >>:

Ну почему. Меня тоже очень интересует скорость расчетов серьезных вещей

Ну, теперь нас трое. Все равно не густо.

 
joo >>:

Вашу мысль я понял хорошо. Но считаю, что мы грузим тестер не так, как можно было бы его загрузить. А вот мою мысль, похоже, Вы не поняли. Но это не важно, по большому счету. Для ориентирования, так сказать, "на местности" сгодится и тот последний эксперт.

ок. Это не casus belli для достойных мужей, не так ли? ))) Меня тоже скорость выполнения именно кода интересует, т.к. мои индикаторы (вдруг, видели) даже в публичном исполнении довольно ресурсоемкие.

 

Я думаю и grasn бы не отказался от возможности считать побыстрее

 
joo >>:

Да нее. Просто все не видят ресусоёмких задач в МТ акромя работы оптимизатора. И даже если и видят, то не используют в своей повседневной работе. По крайней мере большинство. Ну да ладно. Буду ждать MT5. Там прирост скорости работы кода виден невооруженным взглядом. И есть ещё CUDA. Скачал с сайта nVidia тулсы, буду изучать. А перенести код в dll не проблема.

А что касается CUDA-я видел примеры ускорения расчетов в 10-100 раз. Для некоторых медицинских приложений. И CUDA программированию уже учат в универах. Но это очень муторное дело. Т.е. С подобный язык, но надо грамотно разбить задачу, учесть особенности GPU и целочисленность вычислений. Получается очень низкоуровневое программирование. И далеко не все задачи легко привести к такому виду, чтобы получить реальный выигрыш даже после полугода работы. Хотя, например, операции с целочисленными матрицами-почти идеально переводятся на CUDA.
 
begemot61 >>:
А что касается CUDA-я видел примеры ускорения расчетов в 10-100 раз. Для некоторых медицинских приложений. И CUDA программированию уже учат в универах. Но это очень муторное дело. Т.е. С подобный язык, но надо грамотно разбить задачу, учесть особенности GPU и целочисленность вычислений. Получается очень низкоуровневое программирование. И далеко не все задачи легко привести к такому виду, чтобы получить реальный выигрыш после полугода работы. Хотя, например, операции с целочисленными матрицами-почти идеально переводятся на CUDA.

Есть проект OpenCL - среда распределенных вычислений. В нем участвуют практически все, в т.ч. и AMD, и nVidia. Там более высокий уровень абстрагирования. В ссылке есть пример кода - как видите, это C (стандарт C99).

 

Изучил источники, днем отпишусь, сейчас спать пора.

С результатами более или менее понятно.

 

Попробую вкратце описать свои выводы.

При оптимизации эксперта тестер использует несколько десятков МБ памяти. fxt-файл за год с минутками по открытиям у меня например около 36 МБ. Эта история хранится в памяти и доступ к ней осуществляется в более или менее случайном порядке. В таком режиме память не обеспечивает достаточного быстродействия, для обеспечения процессора тем количеством данных, которое он мог бы обработать в "идеальном" случае. Здесь важную роль начинает играть кэш.

Вот здесь и начинается все самое интересное.

1) Очевидно, что в случаях кэш-промахов скорость и латентность доступа к памяти будут играть важную роль. Здесь процессоры можно поделить на 2 группы:

а) Atom и Core 2 - контроллер памяти находится в "северном мосту" (North Bridge - NB) чипсета.

б) все остальные с интегрированным (в процессор) контроллером памяти - ИКП.

Процессоры группы "а" в данном случае могут существенно проигрывать процессорам группы "б". При этом ИКП Core i7 гораздо эффективнее чем на процессорах AMD. Это одна из причин безоговорочной победы Core i7.

2) Для того чтобы кэш мог эффективно маскировать задержки он должен иметь как можно больший объем, ассоциативность (х-way на скриншотах CPU-Z) и меньшую собственную латентность.

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

- Самый медленный Celeron c 512 КБ кэша, (Atom я в расчет не принимаю - поскольку его архитектура рассчитана в первую очередь на экономичность, а не производительность);

- Athlon'ы - у них невысокий объем кэша меньше влияет из-за ИКП;

- Celeron 900 c 1 MB кэша;

- группа процессоров Core 2 с объемом кэша 3-6 МБ, модели с большим объемом кэша немного отрываются от других;

- Phenom II, здесь 6 МБ кэша (причем с максимальной ассоциативностью - аж 48-way!) сочетаются с ИКП;

- и самые быстрые - Core i7 - здесь сочетается все самое прогрессивное - 3-канальный (и вообще очень быстрый) ИКП и самый большой (при этом опять же очень быстрый) L3 кэш объемом 8 МБ.

Что касается того почему эффективность Phenom'а при разгоне падает, а Core i7 растет.

В обоих этих процессорах ИКП и L3 кэш тактуются отдельно (в то время как L1/L2 кэш всегда работает на частоте процессора).

Но метод разгона Belford'а подразумевает увеличение множителя процессора (у него процессор серии BE - Black Edition - со свободным множителем, обычно множитель сверху ограничен), без разгона L3 кэша.

В то время как разгон Core i7 (за исключением XE) возможен только путем увеличения базовой частоты (BCLK). При этом также разгоняются и ИКП с L3 кэшем (в Core ix это называется Uncore).

Таким образом у Phenom'а Belford'а скорость L3 всегда зафиксирована на частоте 2009.1 MHz. А у YuraZ он ускоряется от 2.13 GHz на номинале, до 3.2 GHz при разгоне процессора до 4 GHz. (Частота процессора BCLK x 20, Uncore BCLK x 16). А у Xeon при частоте процессора 3.33 GHz Uncore работает на частоте 2.66 GHz.

При этом даже на частоте 2.13 GHz L3 кэш Core i7 работает заметно быстрее чем L3 кэш Phenom'а на частоте 2 GHz. И естественно намного быстрее на частоте 3.2 GHz, что обеспечивает отличную масштабируемость Core i7 в этом тесте.

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

 
Docent >>:

Попробую вкратце описать свои выводы.

При оптимизации эксперта тестер использует несколько десятков МБ памяти. fxt-файл за год с минутками по открытиям у меня например около 36 МБ. Эта история хранится в памяти и доступ к ней осуществляется в более или менее случайном порядке. В таком режиме память не обеспечивает достаточного быстродействия, для обеспечения процессора тем количеством данных, которое он мог бы обработать в "идеальном" случае. Здесь важную роль начинает играть кэш.

Вот здесь и начинается все самое интересное.

1) Очевидно, что в случаях кэш-промахов скорость и латентность доступа к памяти будут играть важную роль. Здесь процессоры можно поделить на 2 группы:

а) Atom и Core 2 - контроллер памяти находится в "северном мосту" (North Bridge - NB) чипсета.

б) все остальные с интегрированным (в процессор) контроллером памяти - ИКП.

Процессоры группы "а" в данном случае могут существенно проигрывать процессорам группы "б". При этом ИКП Core i7 гораздо эффективнее чем на процессорах AMD. Это одна из причин безоговорочной победы Core i7.

2) Для того чтобы кэш мог эффективно маскировать задержки он должен иметь как можно больший объем, ассоциативность (х-way на скриншотах CPU-Z) и меньшую собственную латентность.

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

- Самый медленный Celeron c 512 КБ кэша, (Atom я в расчет не принимаю - поскольку его архитектура рассчитана в первую очередь на экономичность, а не производительность);

- Athlon'ы - у них невысокий объем кэша меньше влияет из-за ИКП;

- Celeron 900 c 1 MB кэша;

- группа процессоров Core 2 с объемом кэша 3-6 МБ, модели с большим объемом кэша немного отрываются от других;

- Phenom II, здесь 6 МБ кэша (причем с максимальной ассоциативностью - аж 48-way!) сочетаются с ИКП;

- и самые быстрые - Core i7 - здесь сочетается все самое пргрессивное - 3-канальный (и вообще очень быстрый) ИКП и самый большой (при этом опять же очень быстрый) L3 кэш объемом 8 МБ.

Что касается того почему эффективность Phenom'а при разгоне падает, а Core i7 растет.

В обоих этих процессорах ИКП и L3 кэш тактуются отдельно (в то время как L1/L2 кэш всегда работает на частоте процессора).

Но метод разгона Belford'а подразумевает увеличение множителя процессора (у него процессор серии BE - Black Edition - со свободным множителем, обычно множитель сверху ограничен), без разгона L3 кэша.

В то время как разгон Core i7 (за исключением XE) возможен только путем увеличения базовой частоты (BCLK). При этом также разгоняются и ИКП с L3 кэшем (в Core ix это называется Uncore).

Таким образом у Phenom'а скорость L3 всегда зафиксирована на частоте 2009.1 MHz. А у YuraZ он ускоряется от 2.13 GHz на номинале, до 3.2 GHz при разгоне процессора до 4 GHz. (Частота процессора BCLK x 20, Uncore BCLK x 16). А у Xeon при частоте процессора 3.33 GHz Uncore работает на частоте 2.66 GHz.

При этом даже на частоте 2.13 GHz L3 кэш Core i7 работает заметно быстрее чем L3 кэш Phenom'а на частоте 2 GHz. И естественно намного быстрее на частоте 3.2 GHz, что обеспечивает отличную масштабируемость Core i7 в этом тесте.

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

Спасибо. По моему очень убедительно. Согласен.

 
Docent >>: Но похоже, что скорость оптимизации сильно зависит от объема и быстродействия кэша, и несколько меньше от частоты процессора.

Небольшое уточнение. Будет ли правильно считать что скорость оптимизации сильнее зависит от объема и быстродействия кэша, чем от частоты процессора?

 
HideYourRichess писал(а) >>

Небольшое уточнение. Будет ли правильно считать что скорость оптимизации сильнее зависит от объема и быстродействия кэша, чем от частоты процессора?

Получается - да. Однако пока это все-таки предположение, и это я подчеркнул в своем посте!

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