информационная безопасность
без паники и всерьез
 подробно о проекте
Страшный баг в WindowsГде водятся OGRыВсе любят мед
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Мощные индийские ключи 
 Срочные патчи для критических уязвимостей... 
 Очередной рекордный патч Microsoft 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / dnet
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
а что, разве dnetc на HT-процессоре не определяет 2 нитки... 06.12.03 06:35  Число просмотров: 2127
Автор: jammer <alex naumov> Статус: Elderman
<"чистая" ссылка>
> Я тут слышал, что если включить HT и поставить
> 2) Number of crunchers to run simultaneously ==> 2
> то OGR считается процентов на 30 быстрее... сам проверить
> не могу... проца подходящего нету.

а что, разве dnetc на HT-процессоре не определяет 2 нитки автоматически?
<dnet>
HyperThreading + OGR 23.11.03 02:18  
Автор: mss <Сергей> Статус: Member
<"чистая" ссылка>
Я тут слышал, что если включить HT и поставить

2) Number of crunchers to run simultaneously ==> 2

то OGR считается процентов на 30 быстрее... сам проверить не могу... проца подходящего нету.

Никто такие эксперименты не ставил? Может проверите?
Не ужели алгоритм так хреново реализован. 06.12.03 22:50  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
<"чистая" ссылка>
> Я тут слышал, что если включить HT и поставить
>
> 2) Number of crunchers to run simultaneously ==> 2
>
> то OGR считается процентов на 30 быстрее... сам проверить
> не могу... проца подходящего нету.

В смысле програмка не оптимизирована?!
Процессор один. Для двух активных задач будет использоваться переключение процессов/контекстов. Возможно только потеря скорости, связанная с разрушением конвеера (особенно на Пентиуме4).

> Никто такие эксперименты не ставил? Может проверите?

Самому интересно.
Ну как-бы при hyperthreading не только в алгоритме дело... 07.12.03 12:27  
Автор: HandleX <Александр М.> Статус: The Elderman
<"чистая" ссылка>
> В смысле програмка не оптимизирована?!
> Процессор один. Для двух активных задач будет
> использоваться переключение процессов/контекстов. Возможно
> только потеря скорости, связанная с разрушением конвеера
> (особенно на Пентиуме4).
>
> > Никто такие эксперименты не ставил? Может проверите?
>
> Самому интересно.

Там же они в процессоре продублировали некоторые подсистемы под hyperthreading... А cruncher не в отдельном процессе, а в потоке работает, поэтому будет будут перезагружаться только основные регистры, указатель стека, EIP и флаги... Так что выигрыш возможен...
[RC5] На Xeon-2GHz RC5-64 с HT тормозил страшно! 08.12.03 11:43  
Автор: Yurii <Юрий> Статус: Elderman
<"чистая" ссылка>
Ну так... 08.12.03 13:53  
Автор: mss <Сергей> Статус: Member
<"чистая" ссылка>
Клиент-то с тех пор изменился. Сильно причём.
Все Core переписаны, да и вообще - HT теперь не такая редкость, а потому был смысл под него оптимизацию устроить :)
а что, разве dnetc на HT-процессоре не определяет 2 нитки... 06.12.03 06:35  
Автор: jammer <alex naumov> Статус: Elderman
<"чистая" ссылка>
> Я тут слышал, что если включить HT и поставить
> 2) Number of crunchers to run simultaneously ==> 2
> то OGR считается процентов на 30 быстрее... сам проверить
> не могу... проца подходящего нету.

а что, разве dnetc на HT-процессоре не определяет 2 нитки автоматически?
Конечно, определяет 06.12.03 11:26  
Автор: Sandy <Alexander Stepanov> Статус: Elderman
<"чистая" ссылка>
1





Рейтинг@Mail.ru


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