|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 12 Jan 2006 11:51:42
To : Slawa Olhovchenkov
Subject : Re: А в это время в замке шефа...
--------------------------------------------------------------------------------
>>> Slawa Olhovchenkov wrote:
SO> И то и то, насколько я понял.
SO> gettimeofday довольно медленный вызов, когда он отрабатывается честно, с
SO> лазанием к железным часам. Этой настройкой его ускоряют. А в бенчмарки этот
SO> вызов дергают ну очень часто. Hу а при dummy еще и часы встают.
Кстати, на похожую проблему плакался Дядя Вова Бутенко. В итоге он у
себя сделал нить которая каждые 1/4 секунды кладёт в глобальную
переменную значение time(), а остальные просто его читают. Hо это на
уровне софта.
Метод имени Ламберта тоже хорош, но надо решать концептуально -
насколько важна точность не только в смысле "сколько цифр после
запятой", но и в плане допустимой абсолютной погрешности. Дяде Вове
достаточно 1/4 секунды, mysql'ю - не знаю, но если везде у него
time(), то при сохранении монотонности - наверно, тоже сгодится. В
погоне за точностью (вон уже struct timespec в современных
интерфейсах, т.е. до наносекунд) забыли про цену этой точности. Hадо
сделать заказ измерений с указанием необходимых точности и
погрешности...:)
SO> Кстати, отсюда и ответ EG почему при отрубании ACPI на VIA EPIA ускоряется
SO> сборка ядра. Видимо там kern.timecounter.hardware по умолчанию выбирается
SO> довольно медленный. И вероятно если поставить другой -- все будет быстрее.
Кстати ты наверно видел как я наехал на HPET. Кроме этого оно ещё и
гарантированно медленнее ACPI-fast...
-netch-
--- ifmail v.2.15dev5.3
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
