| 1.1, ixrws (?), 20:51, 23/03/2009 [ответить]
| +/– |
Ну вообще-то это боком относится к производительности или вообще к ней не относится проще говоря. А то что проект развивается не только с точки зрения полупаронидальной "семть раз отмерь", но и развивается в общем, это прекрасно. Пожалуй один из немногих проектов, разработчики которого делают свою работу молча и хорошо, за что им низкий поклон. Будь они такие же выпендрёжники как и прочие, могли бы на заборе писать - секурность, секурность и секурность и секурность подражая балмеру, а так нет, работают и знают своё дело. Пожалуй почти уже вымирающий вид:)
| | |
| |
| 2.2, PereresusNeVlezaetBuggy (ok), 21:03, 23/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
 Очень даже относится: каждое переключение процесса приводит с сбросу кэшей процессора, и если процессы распределить про (пардон) процессорам, то можно выиграть в случае словарных операций (первое пришедший в голову пример — кодирование-декодирование данных) довольно заметно.
Главный ступор производительности (впрочем, тоже не слишком сильный) в OpenBSD сейчас — то, что ядро в любом случае выполняется только на одном процессоре. Но тут изменений в ближайшее время ждать не стоит, объём работы, которую необходимо проделать, AFAIK, слишком велик — уж лучше заняться чем-то ещё. Хотя если люди начнут активнее помогать проекту, что-нибудь наверняка изменится. ;) Только что, например, Owain Ainsworth, работющими над такими частями ОС, как поддержка DRI/DRM, кэш файловой системы, NFS, обработка прерываний и так далее, потребовалась[*] пара DVI+VGA мониторов для исправления проблем с многомониторными конфигурациями драйверов для Radeon: если кто-нибудь из местных завсегдатаев в ближайшее время собирается в Англию, может, получится собрать и передать посылочку? ;)
* http://marc.info/?l=openbsd-misc&m=123782840024567&w=2
| | |
| |
| 3.4, ixrws (?), 21:36, 23/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Очень даже относится: каждое переключение процесса приводит с сбросу кэшей процессора, и
>если процессы распределить про (пардон) процессорам, то можно выиграть в случае
>словарных операций (первое пришедший в голову пример — кодирование-декодирование данных) довольно
>заметно.
Пардон, об этом даже не подумал, конечно:) Спасибо что разъяснили.
Это кстати ещё проблема если энергосберегающий режим и ядра отключаются, тогда что называется - кранты энергосбережению:)
| | |
| |
| 4.6, Andrew Kolchoogin (?), 10:26, 24/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
Что касается энергосбережения, то тут вообще дело не такое простое: внутри ядра Юниксов есть переменная, обновляемая по системному таймеру. Соответственно, даже если все процессы будут в состоянии "sleep", ядро все равно будет жрать энергию на изменение этой переменной.
Сейчас Солярисники решили сделать ядро полностью асинхронным, т.е. похоронить lbolt и lbolt64, ну не знаю, насколько быстро у них это получится.
| | |
| |
| 5.7, PereresusNeVlezaetBuggy (ok), 11:41, 24/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Что касается энергосбережения, то тут вообще дело не такое простое: внутри ядра
>Юниксов есть переменная, обновляемая по системному таймеру. Соответственно, даже если все
>процессы будут в состоянии "sleep", ядро все равно будет жрать энергию
>на изменение этой переменной.
Ну, если только одно из многих (по крайней мере в случае SMP нет необходимости держать по экземпляру сей переменной на CPU), то не так страшно… Опять же, таймер имеет свою точность, и в рамках времени между «тиками» процессор вполне может отдохнуть. Впрочем, тут я не сильно компетентен, так что если кто уточнит/опровергнет, — буду благодарен. :)
>Сейчас Солярисники решили сделать ядро полностью асинхронным, т.е. похоронить lbolt и lbolt64,
>ну не знаю, насколько быстро у них это получится. | | |
| 5.8, cvsup (ok), 09:38, 25/03/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Сейчас Солярисники решили сделать ядро полностью асинхронным, т.е. похоронить lbolt и lbolt64, ну не знаю, насколько быстро у них это получится.
Не знаю посчет их тенденций, но пока что телодвижений не видно, и обе щедро используются в солярисном шедулере.
Чего не скажешь о коде FreeBSD, вот уж где вынесли последние упоминания lbolt, еще одну частицу оригинальной BSD ;)
SVN rev 181921 on 2008-08-20 12:20:22Z by ed
Remove the now unused 'lbolt' variable from the kernel.
We used to have a single wait channel inside the kernel which could be
used by threads that just wanted to sleep for some time (the next
second). The old TTY layer was the only piece of code that still used
lbolt, because I already removed the use of lbolt from the NFS clients
and the VFS syncer.
| | |
|
|
| 3.5, Ivan (??), 01:34, 24/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
>далее, потребовалась[*] пара DVI+VGA мониторов для исправления проблем с многомониторными конфигурациями
>драйверов для Radeon: если кто-нибудь из местных завсегдатаев в ближайшее время
>собирается в Англию, может, получится собрать и передать посылочку? ;)
Не совсем без оснований полагаю что в Англии уже и жк-монитор (если не full-hd-панель (хотя, тут, может быть, и горячусь)) с DVI можно слегка обшарпаный найти на помойке (особенно университетской), не говоря уже купить за полфига на барахолке.
| | |
|
| 2.3, Arti (??), 21:07, 23/03/2009 [^] [^^] [^^^] [ответить]
| +/– |
Миграция процесса с ядра имет свою цену. Именно поэтому однопоточные приложения часто выполняются значительно быстрее(если у него нет конкурентов), если в системе отключить все ядра процессора кроме одного.
| | |
|
|
