Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
|
Вышла бета-версия ядра Linux 2.6 10.11.03 10:43 Число просмотров: 1507
Автор: choor Статус: Elderman
|
|
А почему собственно humor?
|
|
<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раз. чем плохо?
|
|
|
подробно о проекте
Анализ криптографических сетевых...
