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





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
вот почему 10.11.03 12:41  Число просмотров: 1503
Автор: mentat[bugtraq.ru] <Александр> Статус: Elderman
<"чистая" ссылка>
> > > А почему собственно humor?
> При тестировании на машине были запущены одновременно сто
> тысяч потоков, и как утверждают в OSDL, раньше тестовая
> задача выполнялась 15 минут, а теперь только две секунды.
>
> ну просто супер производительность ;-))

наверное я тупой, но так и не понял где лопата?
имхо зачетную бету наваяли раз увеличили производительность в 450раз. чем плохо?
<humor>
Вышла бета-версия ядра Linux 2.6 10.11.03 10:22  
Автор: ZaDNiCa <indeed ZaDNiCa> Статус: Elderman
<"чистая" ссылка>
читаем,

я чуть не заплакал...
Вышла бета-версия ядра Linux 2.6 10.11.03 10:43  
Автор: choor Статус: Elderman
<"чистая" ссылка>
А почему собственно humor?
Вышла бета-версия ядра Linux 2.6 10.11.03 10:59  
Автор: Sandy <Alexander Stepanov> Статус: Elderman
<"чистая" ссылка>
> А почему собственно humor?

Видимо, из-за этого:
"Консорциум Open Source Development Labs (OSDL), в составе которого трудится создатель ядра Linux Линус Торвальдс"
вот почему 10.11.03 11:37  
Автор: ZaDNiCa <indeed ZaDNiCa> Статус: Elderman
<"чистая" ссылка>
> > А почему собственно humor?
При тестировании на машине были запущены одновременно сто тысяч потоков, и как утверждают в OSDL, раньше тестовая задача выполнялась 15 минут, а теперь только две секунды.

ну просто супер производительность ;-))
ну, уменьшили оверхед 10.11.03 13:21  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
Это, правда, говорит не столько об эффективности новой реализации, сколько о неэффективности старой :)
а вот еще одна очень интересная заметка 11.11.03 14:23  
Автор: ZaDNiCa <indeed ZaDNiCa> Статус: Elderman
<"чистая" ссылка>
взято отюсда http://www.mycomp.com.ua/article.php?id=6043
"Введен новый системный вызов exit_group (), который совместно с O(1) sheluder позволяет за две секунды закрыть процесс с сотней тысяч нитей — для сравнения, в ядре 2.4 на это уходило 15 минут, так что почувствуйте разницу."

Если сложить это с вышесказанным, выходит что сама задача как на новом так и на старом ядре при большом количестве потоков решалась всего за несколько секунд, но в ядре 2.4.x все оставшейся время (15 минут!) уходило просто на закрытие потоков... С другой стороны возникает вопрос - а оправдано ли было для решения этой задачи рожать 100000 потоков? Или это и была сама задача - просто родить потоки и умереть?
а вот еще одна очень интересная заметка 11.11.03 14:39  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
> взято отюсда http://www.mycomp.com.ua/article.php?id=6043
> "Введен новый системный вызов exit_group (), который
> совместно с O(1) sheluder позволяет за две секунды закрыть
> процесс с сотней тысяч нитей — для сравнения, в ядре 2.4 на
> это уходило 15 минут, так что почувствуйте разницу."
>
> Если сложить это с вышесказанным, выходит что сама задача
> как на новом так и на старом ядре при большом количестве
> потоков решалась всего за несколько секунд, но в ядре 2.4.x
> все оставшейся время (15 минут!) уходило просто на закрытие
> потоков... С другой стороны возникает вопрос - а оправдано
> ли было для решения этой задачи рожать 100000 потоков? Или
> это и была сама задача - просто родить потоки и умереть?

Скорее всего, да. Но если вся оптимизация заключалась в возможности разом прибить сто тыщ потоков, то на практике в ней пользы мало.
а вот еще одна очень интересная заметка 11.11.03 16:03  
Автор: Ktirf <Æ Rusakov> Статус: Elderman
<"чистая" ссылка>
> Но если вся оптимизация заключалась в
> возможности разом прибить сто тыщ потоков, то на практике в
> ней пользы мало.
Ну как сказать. Если в памяти Апач расположился с n-ным количеством предзапущенных потоков, перезапуск оного может стать довольно длительных процессом.
а вот еще одна очень интересная заметка 17.11.03 05:11  
Автор: Favorit Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> > Но если вся оптимизация заключалась в
> > возможности разом прибить сто тыщ потоков, то на
> практике в
> > ней пользы мало.
> Ну как сказать. Если в памяти Апач расположился с n-ным
> количеством предзапущенных потоков, перезапуск оного может
> стать довольно длительных процессом.
Окромя апача есть еще куда мультитредовых приложений.
Мы разрабатываем софт, который в процессе работы под нормальной загруской у клиента может использовать до 50-60 тысяч тредов легко...
я разделяю мнение друга, который сказал... 10.11.03 16:48  
Автор: ZaDNiCa <indeed ZaDNiCa> Статус: Elderman
<"чистая" ссылка>
... что при каком бы то ни было изменении в системе (если ее можно отнести к разряду нормальных систем, а линукс ИмХО можно отнести), не найдется теста, время выполнения которого бы уменьшилось бы в 450 раз

> Это, правда, говорит не столько об эффективности новой
> реализации, сколько о неэффективности старой :)
Простейший пример 11.11.03 15:47  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> ... что при каком бы то ни было изменении в системе (если
> ее можно отнести к разряду нормальных систем, а линукс ИмХО
> можно отнести), не найдется теста, время выполнения
> которого бы уменьшилось бы в 450 раз
Линейный поиск заменить хеш-поиском. Даже в нормальной системе масшатабируемость некоторых вызовов может быть занесена в TODO, потому как есть более насущные проблемы. И вот дошли руки и до этого TODO.
см. выше - скорее всего дело в закрытии потоков 11.11.03 16:05  
Автор: ZaDNiCa <indeed ZaDNiCa> Статус: Elderman
<"чистая" ссылка>
Не столько оверхед, сколько масштабирумость (скалабилити) 10.11.03 15:19  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Это, правда, говорит не столько об эффективности новой
> реализации, сколько о неэффективности старой :)
Не факт, что 10 или 100 процессов будет отличаться тоже в 450 раз (если очень точно измерить). А OpenBSD в этом деле вообще мрачный

Я тут, кстати, статейку видел http://bulk.fefe.de/scalability/ ядро 2.6 по всем основным вещам (время fork-а, mmap-а, первого обращения к mmap-нутому файлу, socket()-а, реакции на сигналы, мож еще чего - не помню) имеет скорость O(const), так что запустили бы 200000 процессов на новом ядре время особо не изменилось бы, а на старом бы подскочило раза в 2.

Гы. Кстати, бенчмарки можно скачать с анонимного цвс-а, вот только поклонники фри возмущаются, а найти изъян (заточку под линух) не могут :-)

http://bulk.fefe.de/scalability/
я бы сказа, оверхед, приводящий к снижению скалабилити :) 11.11.03 14:43  
Автор: dl <Dmitry Leonov>
<"чистая" ссылка>
Поскольку в районе этой самой сотни тысяч график зависимости производительности от числа потоков наверняка ну очень нелинейный, маленький выигрыш может дать большую экономию. Хотя, судя по сегодняшнему комментарию, все, похоже, еще проще.
я бы сказа, оверхед, приводящий к снижению скалабилити :) 11.11.03 16:00  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Поскольку в районе этой самой сотни тысяч график
> зависимости производительности от числа потоков наверняка
> ну очень нелинейный, маленький выигрыш может дать большую
Насколько я помню для 2.4 как раз линейный O(N), а для 2.6 константный - O(1) вот эта разница и выливается в 15 минут

> экономию. Хотя, судя по сегодняшнему комментарию, все,
> похоже, еще проще.
Да ладно, у самой фри есть заточка, только не под тест, а просто под большие нагрузки :) 10.11.03 16:16  
Автор: Ktirf <Æ Rusakov> Статус: Elderman
<"чистая" ссылка>
Там на больших нагрузках в ряде тестов фря просто на раз берет в том числе и Linux 2.6 :) O(1) - это хорошо, но там уже начинает иметь значение, что это за O() :)
Возможно, однако ж бенчмарки 11.11.03 16:27  
Автор: amirul <Serge> Статус: The Elderman
<"чистая" ссылка>
> Там на больших нагрузках в ряде тестов фря просто на раз
> берет в том числе и Linux 2.6 :) O(1) - это хорошо, но там
> уже начинает иметь значение, что это за O() :)
Как раз при таких загрузках и не имеет значения 1000 тактов или 10000 на все про все. Кроме того, константное время для 2.6 линуха только в одном-двух случаях (точно не помню - сам эти бенчмарки давно смотрел) больше, чем у фри.
вот почему 10.11.03 12:41  
Автор: mentat[bugtraq.ru] <Александр> Статус: Elderman
<"чистая" ссылка>
> > > А почему собственно humor?
> При тестировании на машине были запущены одновременно сто
> тысяч потоков, и как утверждают в OSDL, раньше тестовая
> задача выполнялась 15 минут, а теперь только две секунды.
>
> ну просто супер производительность ;-))

наверное я тупой, но так и не понял где лопата?
имхо зачетную бету наваяли раз увеличили производительность в 450раз. чем плохо?
1





Рейтинг@Mail.ru


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