ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 

  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА














     АРХИВ :: Apache-Talk
Apache-Talk mailing list archive (apache-talk@lists.lexa.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [apache-talk] mathopd ranges





On Mon, 17 Dec 2001, Slawa Olhovchenkov wrote:

> KV> Затем что, в отличие от тебя, я хочу получить результате от теста, а не
> KV> сотворить тест, показывающий желаемые результаты. Если ты ЗРАНЕЕ решил,
> KV> что время выборки у тебя 45нс и тест на основе этого знания построил, то,
>
> Я получил эту цифру из твоих данных.
>
Каких именно ?

> > KV>> Ну тогда может быть. Хотя проще уж просто взять две системы, где ВСЕ
> > KV>> компоненты отличаются по скорости на 33% ... Их не так много: память,
> >>
> >> Это случай тривиальный и неинтересный.
> >>
> KV> Чего ? Этот тест доказыает, что PC133 SDRAM на 33% (25% - с твоим
> KV> подходом; я сейчас не хочу спорить о том, с какой стороны разбивать яйцо)
> KV> быстрее PC100 SDRAM.
>
> Нет. Это тест показывает только то, что если все компоненты ускорить
> на 33%, то и система в целом ускорится на 33% процента. Это результат
> очевидный, ожидаемый и неинтересный. Насколько быстрее  PC133 SDRAM
> чем PC100 SDRAM -- вообще с моей точки зрения вопрос неопределенный.

На 33% . И спорить тут нечего - это все легко проверяется. Наскольку
ускорится от такого ускорения памяти система - вопрос уже другой.

> На каких-то операциях так, на других -- подругому... Оценивать надо
> влияние замены одного на другое. В системе.
>
Нет - "в системе" можно только оценить два (или более) решений и выбрать
себе лучшую. Если хочется что-то улучшить, то нужно понять - что из какого
компонента системы пришло и что с этим можно сделать. НЕЛЬЗЯ страдать
шаманством с названием "квалиметрия" - ни к чему хорошему оно в этом
случае не приводит.

> KV> Не зря. Но если мы хотим получить КОЛИЧЕСТВЕННЫЙ резлуьтат, этого
> KV> недостаточно. А качественный "система с PC133 будет быстрее системы
> KV> с PC100 где-нибудь на 3-5% на практических задачах" - тоже хороший
> KV> результат, но он СОВСЕМ из другой оперы.
>
> Зато из практической.
>
угу. Только вот ценность в задачах типа выбора между select'ом и poll'ом у
такого результата - нуль. Ибо неясно откуда он взялся и что с ним
произойдет при изменении программы тем или иным образом. Это как в спорте:
если ты - болельщик (или даже владелец команды), то результаты забегов - в
общем все, что тебя интересует, Но если ты тренер, то тебе нужно ЧЕТКО
знать - ЧТО ИМЕННО у твоего подопечного можно исправить и какой выигрыш
это тебе даст.

> >> Не знаю, что ты сравнивал, а я пытался донести ту мысль, что основной
> >> параметр, определяющий быстродействие подсистемы памяти -- это время
> >> основного цикла (при условии, что ширины шины хватает).
>
> KV> И ты ее не донес. Ибо это не так. Если бы это было так, что CL3 SDRAM,
> KV> которая имеет этот цикл на 50% длиннее, чем CL2 SDRAM была бы настолько же
>
> А можно привести данные из спецификаций, на основе которых ты делаешь
> такое заключение? Через сколько нс выдает результат первая и вторая память?
>
Oops. Это я с прямым углом перепутал :-/ CL2 дает ответ за 5 циклов (37нс),
CL3 через 6 (45нс). Но при этом разница в скорости системы отличается на
3-4% в случае SDR SDRAM (на DDR DRAM это влияет сильнее по понятным причинам).

> KV> медленнее. А она, опять-таки на практике, медленнее на 5-7%. В редких
> KV> задачах - на 10%. Больше разница - только в синтетическиз текстах.
>
> >> И оный параметр уже очень долго не может выпрыгнуть из 40нс.
> KV> С PC133 CL2 SDRAM он кажется все же вышел из 40нс. Правда ненамного (33нс,
> KV> как я понимаю).
>
> Можно привести цифры? И для остальных видов памяти тоже, если не
> сложно. Как я понимаю, ты в этих вещах уже хорошо ориентируешься.
>
Не настолько :-/ Про RDRAM я вообще мало что знаю. Про SDR SDRAM я понимаю
достаточно хорошо (хотя и перепутал что происходит с CL=2 и CL=3 - см.выше),
про DDR SDRAM - хуже, а про RDRAM - только общие принципы. Но если тебе так
интересно - сходи на http://developer.intel.com/technology/memory/ , почитай.
Там все подробно описано, хотя и тяжено для чтения.

> >> И скорсть трансфера в burst-mode становится о-малое.
> KV> ЧЕРТА С ДВА!!! o-малое - это то, чем можно пренебречь. А тут - в одном
> KV> месте 10-15%, в другом - еще 10-15%, в третьем. А врезультате - можно и
> KV> двукратную разницу получить.
>
> Ой, сомневаюсь...
>
Твое дело - это уже перешло в область гаданий на кофейной гуще. Все ведь,
в конечном итоге, зависит от приложений.

[skipped]

> Так, а теперь проводим эксперемент. Несколько некорректный,
> конечно... Но... time make buildworld (5.0-CURRENT сегодняшний).
>
Угу. Давай еще сравним время выполнения md5sum /dev/discs/disc0 ...
тут вообще можно было бы поставить 70нс SIMM'ы и получить тот же результат ...

>
> >> На L2 кэше? Тогда согласен. На замене памяти на более навороченную?
> KV> Система с DDR SDRAM обгоняет систему с SDR SDRAM именно на 15-20% в случае
> KV> с "жадным до шины" процессором типа Pentium 4.
>
> Ммм... Что понимается под его жадностью?
>
Маленький для такой частоты кеш (L1 - 8K, L2 - 256K) в основном плюс
довольно агрессивная предвыборка (Pentium4, как и Athlon XP выбирают
данные из памяти заранее, до того, как команда, их использующая
обращается к памяти; если скорость пакетного режима велика, то промах
ничем не страшен - ну придется читать из памяти не то, что казалось
нужным, а то что реально нужно - только и всего; а вот если скорость
пакетного чтения мала, то промах в этом деле куда тяжелее, потому как
приходится ждать пока вся строка в 16 байт считается, перед тем как
прочитать то, что все-таки на самом деле было нужно). Конечно все зависит
от задач: на Internet Content Creation систем с DDR SDRAM2700 всего на
10% быстрее SDR SDRAM133, а в DroneZ - почти на 50%. Является ли DroneZ
"практической задачей" ? Можно на эту тему долго спорить, но то, что
создавали эту игрушку отнюдь не для сравнения разных видов памяти - точно.

> KV> P.S. Здесь мы уже перешли в область практических тестов и вполне может
> KV> быть, что выигрыш - за счет того, что чипсет (SiS645 - который может
> KV> работать и с SDR SDRAM и с DDR SDRAM; или i845-D - но тут приходится уже
> KV> сравнивать две мамки: одну с i845 и другую - и i845-D, ибо на мамках с
> KV> i845-D часто разъемы под SDR SDRAM просто не ставят), например, больше
> KV> заточен под DDR SDRAM, чем под SDR SDRAM, но тут уж ничего не попишешь:
> KV> никакого способа оценить ПРАКТИЧЕСКУЮ пользу кроме как запустить
> KV> какой-нибудь Microsoft Word с кендомером и сравнить наука пока не
> KV> придумала. Можно усреднить результаты по разным чипсетам, но это тоже
> KV> полной гарантии не дает...
>
> А в биосе burst отключить можно? Я еще раз повторюсь -- по моему
> мнению влиение основное оказывает время первой выборки, наличие burst
> режима -- о-малое.

Хмм... А я еще раз повторяю: 50% (и даже 10%) - это НЕ o-малое. Что
касается времени первой выборки, то RDRAM в среднем (за счет 100нс выхода
из цикла) по этому показателю ХУЖЕ, чем SDR SDRAM. А вот работает она
быстрее, чем SDR SDRAM почти во всех практических задачах. В том же DroneZ
обгоняет на пару процентов DDR2700 ...

> DDR -- это, как я понял из твоих объяснений, другой  случай -- это
> просто удвоение ширины шины.

Не совсем, но по конечному результату сходно.

> Если процессору это не критично, то влияния не оказывает (если  поставить
> вдвое больше SDR DIMM).

Это если программе той памяти не хватает. Если на сервере нормальное
количестко памяти (512Mb для слабозагруженных серверов, 4-8Gb для
сильнозагруженных), то увеличения количества памяти во-первых технически
сложно сделать, а во-вторых не факт, что это поможет: если у системы ВООБЩЕ
есть что-то в swap'е активное регулярно (просыпающиеся раз в час демоны
и/или  программы, которые FreeBSD туда перегоняет "на всякий случай" - не
в счет), то это значит, что ей нужно больше памяти. Swap - система спасения
в нештатной ситуации, а не штатно используемая возможность.

=============================================================================
=               Apache-Talk@lists.lexa.ru mailing list                      =
Mail "unsubscribe apache-talk" to majordomo@lists.lexa.ru if you want to quit.
=       Archive avaliable at http://www.lexa.ru/apache-talk                 =



 




Copyright © Lexa Software, 1996-2009.