Подумалось... Вот люди гоняются за быстрыми процами AMD, Intel ... Новоиспечённые юзвери кричат налево-направо что, мол у мены аж 3.нуль Гыгагэрц интел пень... Да только вот подумалось ... Ведь проц читает команды из оперативки так? Значит слабое место здесь не проц, а именно шина Оператива->Проц. Так как оператива работает медленне проца, тогда зачем 3.0 Ггц? Конечно, есть кеш, мелкие циклы в нём выполняются с огромной скоростью. Но в общем картина такая? Или меня прёт после утреннего кофе?
AMR Современная оператива (like DDR-3@1.5Ghz+), позволяет достигать очень неплохих результатов (гигабайты/сек). Тем более с оптимизированной под это дело архитектурой AMD64 (или решение Intel, на более высоких частотах). Более увеличивать частоту памяти пока нецелесообразно - тайминги начинают расти, а вот с латентностью еще борьбы непочатый край.
alpet Ок. Это я понимаю. Насчёт непохих резуьтатов. Дело вот в чём. Сразу оговорюсь, что все цифры взяты с дуба. Допустим у меня есть 3Ггц проц. Он в любом случае будет простаивать из-за оперативки(Так?). Так вот я думаю можно найти определённую тактовую частоту проца для конкретной оперативки, чтобы он не простаивал просто так. Ну, например, для указанной тобой 1.5Ггц - 2.0Ггц. Потери скорости из-за меньшей тактовой частоты во время раоты куска программы, находящейся в кеше будут минимальными или нет? То есть зачем платить больше за минимальный прирост в скорости.
AMR Ну и пусть 1.5Ггц. Как вообще DDR переводится - Double Data Rate. Это значит что надо все умножать хотя бы на два. Вообще рекомендую убедится в производительности оперативы своими что называется глазами. Лучше всего это наверно сделать с помощью AMD Code Analyst, благо на форуме есть темы касающиеся оптимизации работы с памятью. В результате станет ясным, большое количество ньюансов работы проца с памятью, среди которых частота последней просто теряется.
alpet Да меня в общем-то интересовал вопрос стоит ли проц в ожидании очередной команды с шины или нет
AMR Сталл может возникнуть, если у тебя скажем линейно выполняется 10Мб простого кода (который хорошо параллелится) - в таком случае IC будет неуспевать подгружать из памяти код. Но вероятность этого весьма мала, как правило наибольшее количество кода, подгружаемое в кэш, выполняется достаточно много раз.
alpet Это уже умноженная на два будет 1,5 ГЦ. Я рассматриваю систему построенную на чипсете 8XX. Линия составляет 64 Бита (8 Байт). Для 32 разрядной системы полагаем 4 Байта на такт. Следовательно на 3ГЦ проца частота FSB должна быть 1.5 Гц , но шина позволяет обрабатывать два канала. Следовательно, частота памяти равна DDR 750 МГц(2х366МГЦ). Обычно программа читает из памяти не каждый такт. Поэтому хватит и DDR400(2х200МГЦ). Про современных компьютеры(чипсет 9xx) сказать не могу, нужно смотреть архитектуру. Для 64 разрядных компьютеров за так требуется 64бита. Следовательно память им нужна c большей частатой. Для много ядерных умножаем на число ядер.
Code Analyst показывает результаты исходя из того, что команды уже в кеше команд. Однако пока они туда считаются, много времени пройдёт. И учитывая мизерный размер кэша, проблема имеет место быть. А гоняются за высокими тактовыми частотами - так это результат промывки мозгов двигателем прогресса Если же кто не верит в тормоза вызванные шиной и захочет потребовать конкретные цифры - предлагаю сначала подумать, почему скорость не слишком синтетических тестов растёт совсем не пропорционально частоте ядра... Ну или отключите кэш проца в биосе Современные компы обычно совсем не загружаются, а старинные пни работали прямо как тройки =)
S_T_A_S_ Code Analyst может показать разницу в выполнении кода, с страницы на которой кэширование запрещено, и на которой разрешено. Просто огромную разницу. Очень интересные вещи мне показывает кстати SandraLite - скорость чтения из кэша, аж 12Гбайт/сек. Тогда как латентность его (обычно от 40 до 160 пикосек, т.е. 1 такт или более тактов) имеет большее значение. Так же и латентность загрузки странички (линейки) кода в IC, имеет большее значение, чем собственно скорость загрузки.
Интересно, а как учитывает CodeAnalyst влияние сброса кешей TLB, страничной адресации и прочих вещей вроде переключения контекстов? Ну а SandraLite может ведь и просто с ума сходить иногда Все эти синтетические тесты не очень реальную картину показывают, если вспомнить манипулирование 3DMark'ом со стороны драйверописателей nVidia.
S_T_A_S_ Может он учитывает и не идеально, но для симулятора вполне сносно. Во всяком случае наглядности хватает, чтобы суть уяснить. Что же до Sandra, то да во многих отношениях она шарлатанство - например мощность ядра моего ЦП оценивает всегда в 55-56W (неразогнаного), независимо от нагруженности ЦП. Тем не менее тесты некоторые имеют приближенность к реальности. Я оценивал идеальную производительность чтения кэша L1-DC повыше правда - порядка 16 гб/с (2ггц частота кэша * 64бита).
