>> Если есть время и желание, в принципе >> можно провести серию экспериментов >> (вставляя в код замеры времени через rdtsc) >> и выяснить, за счёт чего >> возникает такая разница. Хорошая >> задачка - довольно трудоёмкая, но >> прямолинейная - в том смысле что понятна >> последовательность необходимых >> действий. >> > > уже сделано %)) > > как то торвальдс заметил что не все > ладно с ядрами серии 2.6 - > производительность скачет от релиза к > релизу - _сам_ сделал замеры > производительности (2.6.8 - то что в сарге - > оказалась процентов на 25 !!! медленнее > ядра 2.4.хх, остальные 2.6.х от почти такой > же производительности до -10 -15% ) > > в общем после этого введена в строй > автоматическая писькомерка на > кернел.орг которая делает бенчмарки > новых ядер на многих разных железках > чтобы было видно какое новшество в ядре > приводит к какому результату
Я имел в виду не обнаружение/подтверждение самого факта тормозов, а выяснение низкоуровневых причин таковых. Мне периодически приходится на работе выяснять, куда деваются микросекунды. Это весьма трудоёмко, но на x86 вполне осуществимо - вплоть до выяснения виновного кода и/или последовательнсти управляющих команд на железку. А в случае, когда доступен код, работающий быстро, и код, работающий медленно, результат подобной процедуры гарантирован, если только хватит времени/терпения/желания. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
