И чем-же лучше ? :001.03.06 16:42 Число просмотров: 2620 Автор: leo <Леонид Юрьев> Статус: Elderman Отредактировано 01.03.06 16:42 Количество правок: 1
[NT] Великий All, подскажите, pls, невозможность работы в ядре с FPU/MMX/SSE это анахронизм 9x виндов, в технологии NT всё работает? Заранее всем спасибо за ответы.28.02.06 19:25 Автор: HandleX <Александр М.> Статус: The Elderman
Если этого не делать, то происходит примерно так:
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 и битик этот тоже не юзает а > делает все вручную > > опять же билли пишет - по соображениям производительности Вручную, но битик используется. Явно устанавливается/снимается когда нужно. Это единственное переносимое (на разные 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
Действительно, использовать 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
> Согласно фразе "оборачивать в Save/Restore FPU state (лучше > каждый оператор)"? > Я это имел в виду :)...
ну это имелось ввиду конечное не буквально каждый, а что между операторами нельзя
втыкать всякие KeWait-ы/Stall-ы/Yield-ы и вообще точно ведь неизвестно какие апи
можно юзать а какие нет между save/restore, все это суть русская рулетка
кому улыбнулось а кому потом и в синьку на..бнулось
Ага, тоже улыбнуло, но комментировать не стал... :)02.03.06 09:33 Автор: HandleX <Александр М.> Статус: The Elderman