Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | |
Надежностью и производительностью. 02.03.06 03:17 Число просмотров: 2671
Автор: Zef <Alloo Zef> Статус: Elderman
|
|
|
|
<operating systems>
|
[NT] Великий All, подскажите, pls, невозможность работы в ядре с FPU/MMX/SSE это анахронизм 9x виндов, в технологии NT всё работает? Заранее всем спасибо за ответы. 28.02.06 19:25
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
|
|
KeSaveFloatingPointState() / KeRestoreFloatingPointState() 01.03.06 16:50
Автор: leo <Леонид Юрьев> Статус: Elderman
Отредактировано 01.03.06 16:51 Количество правок: 1
|
KeSaveFloatingPointState() / KeRestoreFloatingPointState()
Если этого не делать, то происходит примерно так:
1) В состоянии CPU есть битик индицирующий переключение задач, он взводится при каждом переключении;
2) Если бит установлен (было переключение) и попадается FPU/SIMD инструкция, то процессор генерирует исключение;
3) Обработчик исключения должен сохранить состояние FPU для предыдущей задачи и загрузить для новой;
4) В KernelMode исключения автоматически не обрабатываются, поэтому если в задаче до переключения на твой тред FPU использовался то будет BDOS;
5) KeSaveFloatingPointState() явно сохраняет FPU и очищает бит переключения;
|
| |
все так как ты пишешь и битик такой есть в состоянии CPU... 01.03.06 17:44
Автор: z0 <z0> Статус: Member
|
все так как ты пишешь и битик такой есть в состоянии CPU только микрософт
не юзает cpu-task-switching и битик этот тоже не юзает а делает все вручную
опять же билли пишет - по соображениям производительности
|
| | |
Вручную, но битик используется. Явно... 01.03.06 18:14
Автор: leo <Леонид Юрьев> Статус: Elderman
|
> все так как ты пишешь и битик такой есть в состоянии CPU
> только микрософт
> не юзает cpu-task-switching и битик этот тоже не юзает а
> делает все вручную
>
> опять же билли пишет - по соображениям производительности
Вручную, но битик используется. Явно устанавливается/снимается когда нужно. Это единственное переносимое (на разные CPUx86) аппаратное средство для сохранения/восстановления FPU по требованию.
|
|
1) использовать можно но не везде и не всегда (IRQL <=... 01.03.06 15:12
Автор: z0 <z0> Статус: Member
|
1) использовать можно но не везде и не всегда (IRQL <= DISPATCH_LEVEL и еще)
2) обязательно оборачивать в Save/Restore FPU state (лучше каждый оператор)
3) WDM дрова в 9х тоже так умеют титиретически, не пробовал
4) имхо лучше не использовать вообще
|
| |
4) - согласен. Все равно лучше другой подход, даже если БСОД удастся победить. 01.03.06 17:12
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 01.03.06 17:14 Количество правок: 3
|
> 4) имхо лучше не использовать вообще
Действительно, использовать FPU/MMX и тем более SSE в ядре... круто. Этим должны заниматься пользовательские проги, а не управляющая программа. В конце концов можно фиксированной точкой воспользоваться или библиотечку эмуляции зацепить.
|
| | |
Не согласен. К примеру, драйвер софтварного RAID. В ядре? В ядре. Над огромными массивами данных ему надо делать операцию XOR. SIMD-инструкции сделают это быстрее. 02.03.06 06:42
Автор: HandleX <Александр М.> Статус: The Elderman
Отредактировано 02.03.06 06:43 Количество правок: 1
|
|
|
| | | |
Это очень редкий случай, я бы даже сказал единичный, когда... 02.03.06 19:25
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 02.03.06 19:26 Количество правок: 1
|
Это очень редкий случай, я бы даже сказал единичный, когда будет заметен эффект.
Точнее не заметен, поскольку даже при приросте в скорости вычисления (если ФПУ действительно взялся за ХОР арифметику) в два раза, конечная скорость будет незаметно выше хотя бы потому, что трансфер данных с диска на пару порядков медленнее любых вычислений.
Еще вариант - затачиваем под Интел Итаниум или Атлон-64 и скорость на ЦПУ вырастет в два раза. Причем на ФПУ неизменится. Разница в производительности на обычных процах не превышает двух раз от использования ФПУ.
|
| | | | |
Драйвер — не сферический конь в вакууме. Ещё множество потоков помимо него могут хотеть свой квант времени, а поскольку I/O к устройствам может быть асинхронным, то чем быстрее "отпустим" проц, тем лучше будет общая производительность. 03.03.06 06:07
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
|
| | |
ну так! ядро не для того сделано чтоб там логарифмы считать 01.03.06 17:49
Автор: z0 <z0> Статус: Member
|
а то тут уже девелоперы и COM-объекты туды просят затянуть и .NET
а не фиг
плоские си или лучше асм и никаких излишеств
|
| |
И чем-же лучше ? :0 01.03.06 16:42
Автор: leo <Леонид Юрьев> Статус: Elderman
Отредактировано 01.03.06 16:42 Количество правок: 1
|
|
|
| | |
Надежностью и производительностью. 02.03.06 03:17
Автор: Zef <Alloo Zef> Статус: Elderman
|
|
|
| | | |
Согласно фразе "оборачивать в Save/Restore FPU state (лучше... 02.03.06 07:51
Автор: leo <Леонид Юрьев> Статус: Elderman
|
Согласно фразе "оборачивать в Save/Restore FPU state (лучше каждый оператор)"?
Я это имел в виду :)...
|
| | | | |
цепляетесь к словам блин 02.03.06 14:59
Автор: z0 <z0> Статус: Member
|
> Согласно фразе "оборачивать в Save/Restore FPU state (лучше
> каждый оператор)"?
> Я это имел в виду :)...
ну это имелось ввиду конечное не буквально каждый, а что между операторами нельзя
втыкать всякие KeWait-ы/Stall-ы/Yield-ы и вообще точно ведь неизвестно какие апи
можно юзать а какие нет между save/restore, все это суть русская рулетка
кому улыбнулось а кому потом и в синьку на..бнулось
|
| | | | |
Ага, тоже улыбнуло, но комментировать не стал... :) 02.03.06 09:33
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
|
|
а в чем проблема? я вообще не понимаю, как можно запретить... 28.02.06 20:21
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
|
|
а в чем проблема? я вообще не понимаю, как можно запретить коду работающему на 0-м кольце вызывать FPU/MMX/SSE команды. Или я не понял вопроса?
|
| |
Запретить нельзя... Но такой драйвер вгонял систему в BSOD. 01.03.06 06:24
Автор: HandleX <Александр М.> Статус: The Elderman
|
|
|
| | |
ДЫк, может в консерватории что-то исправить? 01.03.06 14:57
Автор: NKritsky <Nickolay A. Kritsky> Статус: Elderman
|
|
no offense, но BSOD в драйвере - результат ошибки, за исключением малого количества бсодов.
|
| | | |
может, но в чьей? 01.03.06 15:15
Автор: z0 <z0> Статус: Member
|
ты что не знаешь что при переключении контекста не сохраняется FPU-state?
как сказал билли - по соображениям перформанса
так чта...
|
| | | | |
Ну билли тут не виноват :) В Linux, FreeBSD, QNX, etc... тоже самое. 01.03.06 18:19
Автор: leo <Леонид Юрьев> Статус: Elderman
|
|
|
|
|
подробно о проекте
Анализ криптографических сетевых...
