Добрый день.

Вот буквально только что открыл для себя существования этого ядра в Windows 2000/XP
Может кто знает что это за зверь такой? и чем оно отличается от стандартного? может кто использует его?
Есть ли приемущества или недостатки?

Здравствуйте, _f_b_i_, Вы писали:

___>Добрый день.

___>Вот буквально только что открыл для себя существования этого ядра в Windows 2000/XP
___>Может кто знает что это за зверь такой? и чем оно отличается от стандартного? может кто использует его?
___>Есть ли приемущества или недостатки?

А можно для тех, кто пока не открыл, объяснить поподробнее? Интересно же.

Были такие процессоры — i486 работали на частотах в диапазоне порядка 25...133МГц. А C — это наверно от compatibe.

Здравствуйте, SergH, Вы писали:

SH>Здравствуйте, _f_b_i_, Вы писали:

___>>Добрый день.

___>>Вот буквально только что открыл для себя существования этого ядра в Windows 2000/XP
___>>Может кто знает что это за зверь такой? и чем оно отличается от стандартного? может кто использует его?
___>>Есть ли приемущества или недостатки?

SH>А можно для тех, кто пока не открыл, объяснить поподробнее? Интересно же.

Во время начала устновки Windows давим F5 пару раз и немножко ждем.
Дальше появляется небольшая менюшка бывора ядра
'Standart PC with C-Step i486'
'Other'

Здравствуйте, _f_b_i_, Вы писали:

___>Вот буквально только что открыл для себя существования этого ядра в Windows 2000/XP

поиск рулит http://www.insidepro.com/kk/030/030r.shtml

Здравствуйте, _f_b_i_, Вы писали:

[skip]
___>Вот буквально только что открыл для себя существования этого ядра в Windows 2000/XP
___>Может кто знает что это за зверь такой? и чем оно отличается от стандартного? может кто использует его?
___>Есть ли приемущества или недостатки?

Не могу сказать что конктено, потому как не помню что потеряется. Но если буду знать какой из HAL будет устанавливатся в итоге, то можно все узнать.
1. Есть ли в нем поддержка APIC — если нет то прерываний всего 15
2. Есть ли в нем поддержка ACPI — если нет распределение ресурсов компьютера будет происходить самостоятельно ядром и взаимодействие с устройствами будет идти напрямую.
если есть то ядро всецело будет полагатся на ACPI контроллер.
Недостаток ACPI только в одном что обычно все PCI устройства на одно прерывание.

Есть статья здесь все описанно. Да и у Руссиновича тоже все это описанно.

Здравствуйте, Злость, Вы писали:

З>Здравствуйте, _f_b_i_, Вы писали:

З>[skip]
___>>Вот буквально только что открыл для себя существования этого ядра в Windows 2000/XP
___>>Может кто знает что это за зверь такой? и чем оно отличается от стандартного? может кто использует его?
___>>Есть ли приемущества или недостатки?

З>Не могу сказать что конктено, потому как не помню что потеряется. Но если буду знать какой из HAL будет устанавливатся в итоге, то можно все узнать.
З>1. Есть ли в нем поддержка APIC — если нет то прерываний всего 15
З>2. Есть ли в нем поддержка ACPI — если нет распределение ресурсов компьютера будет происходить самостоятельно ядром и взаимодействие с устройствами будет идти напрямую.
З> если есть то ядро всецело будет полагатся на ACPI контроллер.
З> Недостаток ACPI только в одном что обычно все PCI устройства на одно прерывание.

З>Есть статья здесь все описанно. Да и у Руссиновича тоже все это описанно.

Прочитал статейку, ну на эту тему в инете их было куча. Когда первый раз прочитал эту новость года 2 назад, на работе даже тестировали. Делали тест не какой то там мифический на кол-во переключенй в секунду, а нас интересовала именно скорость компиляции, остальное побарабану. Так вот, увеличения производительности НЕТ. Ну хорошо, увеличили кол-во переключений в секунду и что из этого. Нужно же смотреть сколько процессорного времени тратится на ядро винды(всякое переключение потоком, менеджер памяти и т.д.)в процентном соотношении к полезной работе.

З>>Есть статья здесь все описанно. Да и у Руссиновича тоже все это описанно.

D>Прочитал статейку, ну на эту тему в инете их было куча. Когда первый раз прочитал эту новость года 2 назад, на работе даже тестировали. Делали тест не какой то там мифический на кол-во переключенй в секунду, а нас интересовала именно скорость компиляции, остальное побарабану. Так вот, увеличения производительности НЕТ. Ну хорошо, увеличили кол-во переключений в секунду и что из этого. Нужно же смотреть сколько процессорного времени тратится на ядро винды(всякое переключение потоком, менеджер памяти и т.д.)в процентном соотношении к полезной работе.

Смотря что считать полезной работой. Некоторые виды полезной работы невозможно сделать без переключения контекста, о чем и говорится в указанной статье. Ну а с учетом того, что в чистой производительности (т.е. без переключений) этих халы примерно равны, то единственный значительный минус 486с — отсутствие нормального pm. Впрочем, на NT4 эта проблема решалась, значит, наверняка и в XP тоже можно.
А то, что латентность у NT во многих задачах выше, чем у, например, тех же 95х (несмотря на то, что внутри они 16-ти битные), это ощущалось при переходе на вин2к c 9х вполне себе.
Вообще, конечно, отдельные hal это все хорошо, но в результате приводит к тому, что код обработки каких то тривиальных вещей размазан по всему ядру, что, собственно, ведет просто к диким провалам в производительности. Вообще, поражает стремление сделать сложнее там, где _надо_ делать проще. Да, хотели как лучше, разделяемые уровни ядра. Но в результате этого не получили, плюсом еще и совершенно лишние тормоза поимели. Супер. А ведь это при том, что современные аппаратные средства позволяют решать многие задачи прилично быстрее — вспомнить тот же SYSCALL, или HPET. Я вот не могу понять, почему бы в подобных целях не использовать технику модификации кода. Т.е. hal содержал бы "подставляемые" участки, которые при загрузке (либо установке) ядра вставлялись бы в нужные места. Частично, кстати, так было сделано в 9х, где ядро собиралось из "частей", а драйвера вместо вызовов системных сервисов содержали метки, настраиваемые при их загрузке. Аналогичным образом можно было бы сделать и user-mode библиотеки, позволяя подставлять короткие (или на выбор) функции непосредственно в код приложения (а ведь PE содержит первые шаги по пути к этому — редирект функций, собственно, который и позволяет избежать больших затрат при работе с критическими секциями, например). Больших проблем в реализации этого тоже нет, а вот увеличить модульность это помогло бы очень и очень сильно. Ведь тогда не нужны были самопальные (по-другому сказать просто сложно) реализации интринсик Interlocked* функций в последних CRT от m$ и многое-многе другое. Нет, я конечно понимаю, что для разработчиков на java или .net call стек из нескольких сотен вызовов — это нормально, но вот зачем это в ядре х86 или в user, мне слабо понятно.

Здравствуйте, Andrew S, Вы писали:

AS>А ведь это при том, что современные аппаратные средства позволяют решать многие задачи прилично быстрее — вспомнить тот же SYSCALL, или HPET.

Что такое HPET? в мануале интела не нашёл такой инструкции..

AS>Я вот не могу понять, почему бы в подобных целях не использовать технику модификации кода. Т.е. hal содержал бы "подставляемые" участки, которые при загрузке (либо установке) ядра вставлялись бы в нужные места. Частично, кстати, так было сделано в 9х, где ядро собиралось из "частей", а драйвера вместо вызовов системных сервисов содержали метки, настраиваемые при их загрузке. Аналогичным образом можно было бы сделать и user-mode библиотеки, позволяя подставлять короткие (или на выбор) функции непосредственно в код приложения (а ведь PE содержит первые шаги по пути к этому — редирект функций, собственно, который и позволяет избежать больших затрат при работе с критическими секциями, например).

Интересная идея.. Возможно просто в голову не пришла PE — имеется ввиду формат PE exe-файлов? А как он связан с критическими секциями?

Здравствуйте, SergH, Вы писали:

[skip]
AS>>А ведь это при том, что современные аппаратные средства позволяют решать многие задачи прилично быстрее — вспомнить тот же SYSCALL, или HPET.

SH>Что такое HPET? в мануале интела не нашёл такой инструкции..

Это не инструкция — это спецификация на таймеры с высоким разрешением. здесь

[skip]

AS>>А ведь это при том, что современные аппаратные средства позволяют решать многие задачи прилично быстрее — вспомнить тот же SYSCALL, или HPET.

SH>Что такое HPET? в мануале интела не нашёл такой инструкции..

AS>>Я вот не могу понять, почему бы в подобных целях не использовать технику модификации кода. Т.е. hal содержал бы "подставляемые" участки, которые при загрузке (либо установке) ядра вставлялись бы в нужные места. Частично, кстати, так было сделано в 9х, где ядро собиралось из "частей", а драйвера вместо вызовов системных сервисов содержали метки, настраиваемые при их загрузке. Аналогичным образом можно было бы сделать и user-mode библиотеки, позволяя подставлять короткие (или на выбор) функции непосредственно в код приложения (а ведь PE содержит первые шаги по пути к этому — редирект функций, собственно, который и позволяет избежать больших затрат при работе с критическими секциями, например).

SH>Интересная идея.. Возможно просто в голову не пришла PE — имеется ввиду формат PE exe-файлов? А как он связан с критическими секциями?

Ну как сказать. Реализация этого в нормальном виде не так уж и тривиальна — компилятор должен будет (а, точнее даже, линкер) обеспечивать независимость (реллоцируемость) кусков кода, которые вызывают подставляемые функции. Соответственно, процедура загрузки\настройки существенно усложняется. Другое дело, что это можно было бы искусственно ограничить, например, размерами подставляемой функции (дабы не иметь проблем со jmp short). В любом случае, этого уже не сделано, и вряд ли когда-либо будет.
Про редирект — см. http://gzip.rsdn.ru/Forum/Info.aspx?name=FAQ.dll.reexport

Автор: Alex Fedotov
Дата: 15.10.02

Те критичские секции, которые отдаются kernel32.dll, просто редиректы на соотв. функции в ntdll.dll. Т.о. один из уровней вложенности вызовов устраняется "бесплатно", за счет формата экспорта.
Кстати, интересно, что ядро винхр содержит вне зависимости от hal три переходника в kernel — для SYSCALL, SYSENTER и для обычного int2Eh. Ну, то, что надо поддерживать int2eh, это понятно, но вот почему в зависимости от типа процессора не патчить нужные куски кода (тем более, что их совсем немнго) — мне не понятно... Почитать про это дело можно http://www.codeguru.com/cpp/w-p/system/devicedriverdevelopment/article.php/c8223/, и остается просто удивляться идиотизму, который проявляет m$ при работе с такими вещами, где каждые несколько тактов могут иметь большой вес...