информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Атака на InternetВсе любят мед
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Бэкдор в xz/liblzma, предназначенный... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / operating systems
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Это очень редкий случай, я бы даже сказал единичный, когда... 02.03.06 19:25  Число просмотров: 2760
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 02.03.06 19:26  Количество правок: 1
<"чистая" ссылка>
Это очень редкий случай, я бы даже сказал единичный, когда будет заметен эффект.
Точнее не заметен, поскольку даже при приросте в скорости вычисления (если ФПУ действительно взялся за ХОР арифметику) в два раза, конечная скорость будет незаметно выше хотя бы потому, что трансфер данных с диска на пару порядков медленнее любых вычислений.
Еще вариант - затачиваем под Интел Итаниум или Атлон-64 и скорость на ЦПУ вырастет в два раза. Причем на ФПУ неизменится. Разница в производительности на обычных процах не превышает двух раз от использования ФПУ.
<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
<"чистая" ссылка>
1  |  2 >>  »  




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach