Чо прицепился? =bits=, в формуле так и написано.



Вообще-то я говорил о потоковой скорости, коюю и приводят в документах.
Если говорить о полной(мгновенной), то надо прибавить тик на конвеерность доступа.



Ммм ... попробовал посмотреть ... нет, я пас! Повторно переваривать полгида pdf? ...
Мои цифры были "не с потолка", но доказывать ничего не хочу из принципа "Неуловимого Джо".

p.s.
Знаешь ... достала эта 'недокументированная теория'.
Нечто подобное я постоянно замечаю, но нет инструмента, чтоб сказать
что-то _конкретное_. Порой, даже чтение официальной документации вызывает
недоумение, а что уж о слухах в и-нете?
У меня в планах так и написано(этак недели 3 назад):
"Хотелось бы сделать:.... график memory latency для разного доступа"
Так что ... моя интуиция говорит не верю, а я редко ошибаюсь.


p.p.s.
Бойся стереотипов, они везде.

serj_

Дык есть же в CacheBurst!

Да есть, как есть и cachemem. Не то, чтоб я не доверял этим программам,
ни коем образом, ... проблема измерения времени доступа настолько сложна,
что я ставлю жирный знак ?? и пока не сделаю сам - ничего не смогу
сказать _конкретно_.
Даже такая тупая процедура, как измерение производительности памяти
(см. графики с статье) имеет скрытые нюансы от реализации MMX/SSE,
то latency ... все на попядок сложнее.

Вот тоже мучаюсь этим вопросом... Вобще давно таких информативных статей не читал. Так держать!

хм. немного критики. Основной плюс статьи - она большая! Но с другой стороны, выглядит оно как "посмотрите, как долго я могу работать над одной темой". Нет "глобальной идеи", что ли. Мне кажется, что на overclockers.ru статьи должны быть несколько другой тематики... А вот то, сколько времени (вероятно, судя по обьему) было потрачено - впечатляет. Сколько писал-то?

В первом приближении посмотрел latency для L1/L2/RAM
Цифры лучше привести в сравнении с CacheBurst и CacheMem:
programm: L1 L2 RAM
CacheBurst 3 20 371
CacheMem 4 20 380
my test (1) 4 13 373
my test (2) 2 17 399

тест выполнялся для одного запроса (1) или нескольки запросов
на чтение, время доступа к второму приведено в (2).
По L1 .... да, 4, с этим ничего не сделать...........
По L2 .... ну нет там 20! Кстати, увеличение время на второй запрос
так-же предсказуемо - надо передать первый блок (для L1 нет "блока")
По RAM ... аналогично L2, только она находится от процессора еще дальше
и тактов бОльше.
Интересное наблюдение - по RAM разница составляет 26 тактов, а в моем
процессоре частота FSB=110MHz, CPU=1.8G, что дает 4 тика на 1 тик обмена
шины --- 26/4=6.5 .... т.е. как раз время пердачи остальных 7 посылок в блоке.

p.s.
под измерением latency понимается время от выдачи команды на чтение байта
(word/dword/qword) до выполнения этой операции.

serj_
Ну что ж..
Будем знать, к кому по поводу памяти обращаться. Столько рутинной работы сделать... Wow!!!

serj_


Там 3, и автор кэшмема сам признаёт свой баг!



20 это в случае переполнения виктим-буфера. При "прореженных" запросах должно получаться 11 тактов. На Athlon XP (с аппаратным префетчером) латентность L2 иногда достигает 24.

Наверно, я очень туп (весенний авитаминоз, однако), но не могу понять....
Время выполнения команды mov eax,[edi] составляет 4 тика.
Цифра 3 получается вычитанием 1=mov из 4?
Если не так - желательно указать, где сие обсуждалось ... вряд-ли
стоит повторяться.



есть такое дело, именно 20 и получал.
Специально боролся с этим эффектом .... наверно, не совсем
корректно добиваться затыкания системы и говорить о времени доступа?
Или надо приводить 2 цифры - из незагруженной системы и 'потоковое'.
Я неправ?



За 13 отвечаю, '11' не видел ни разу. Где-то "не в'ехал" в технологию?



... и вообще, там черт голову сломит!



p.s.
Sorry, приведенные цифры в '3' и '11' получены измерением или из документации? Я не придираюсь, упаси Боже, просто интересно.

serj_

Извини, но оно равно 3!!! В кешбёрсте нет никаких компенсаций.



Обсуждалось в почте. Написано в официальных документах. И по тестам так получается.



Угу, "typical" и "worst"



Честно говоря, получить на работающем процессоре ненагруженное состояние не представляю возможным, потому мы и не стали это делать в CB32. Можно попробовать находить минимальное время из серии одиночных обращений. Но там вопрос с зачистками кэш... и опять появляется переполнение виктим-буфера
Он ведь всего на восемь строк.

PS
На каком процессоре получается 13? Это 11+2, т.е. попадает лишний L2 turnaround time.

PPS
serj_
http://www.amd.com/products/cpg/athlon/pdf/cache_wp.pdf

Позор на мою дурную голову! ....
Сработало органическое неприятие "White Papers" и пропустил эту информацию.... :?

Спасибо!

(чуть настораживает дата - 2000 .. ну да ладно! )

Видимо, обсуждение закончилось? ....

Ok, resume:

По 'latency':
- есть 2 параметра - полное время доступа из 'спокойного' состояния и 'потоковое',
первое показывают программы CacheMem,CacheBurst, другие;
второе - никто. (насколько я знаю) Тестовые программы сидят на одном
и том-же engine(наверно) и .... не думаю.
- влияние первого параметра на общую производительность системы ....
я бы оценил как нулевое, только второй параметр оказывает существенное
влияние. Как комментарий: на Irongate можно переключать bypass, что на 30%
уменьшает 'первый' latency, но никак не влияет на 'второй'. Реальные программы
и тесты(bench) показывают нулевую эффективность bypass.(не особенно долго тестил)
- latency доступа к RAM определяется занятостью буферов запросов и самим
контроллером, и для случая 'простоя' программы (когда она циклится в малом
наборе адресов без чтения/записи памяти) должна быть минимальна, ведь
запросов нет? ... а вот нет ли?.
УВЫ!
- .... по этому вопросу хватит
(хоть вторую часть статьи писать ... брррр .............)

По процессорам:
1) EV7 - это тот-же EV68 с крутым межпроцессорным интерфейсом
2) AMD процессоры не разрабатывает, это технологическая фирма
3) 64х регистры в K7 были, например регистр с номером 'A'
4) найдите 3 отличия в картинках:
http://testmem.nm.ru/a.jpg
http://testmem.nm.ru/b.jpg
http://testmem.nm.ru/c.jpg
с учетом разного об'ема L2, контроллера памяти и межпроцессорного интерфейса.

1+2+3+4 = расширенный Barton
Т.е. никакой это не "принципиально новый процессор".

p.s.
Бойтесь стереотипов, они везде.

-------------------------------------------------------------------------------------------
Best regards,
Serj

serj_
Я поражаюсь, как легко и непринуждённо вам удаётся запутать свои мысли до степени практически совершенной иррациональности



кэшмем и кэшбёрст меряют именно потоковое

Чтоб завершить обсуждение...
- пусть так, чтоб ответить твердо и конкретно надо потратить
время на написание серьезной тестовой программы.
Если BenchMem никому 'не нать', то тратить время на модуль измерения
latency просто глупость. ... эх!

serj_
Предлагаю обсуждение не завершать

Что значит "не нать"?