|
2.3, коксюзер (?), 01:14, 10/04/2011 [^] [^^] [^^^] [ответить]
| +2 +/– |
Штука перспективная. Наибольший прирост будет в рантаймах с green threads.
| |
2.11, Zenittur (?), 02:05, 10/04/2011 [^] [^^] [^^^] [ответить]
| +/– |
Я так думаю что уже да, судя по тексту новости, что это (будет) новый механизм в ядре Linux.
| |
2.20, anonymous (??), 09:15, 10/04/2011 [^] [^^] [^^^] [ответить]
| +3 +/– |
> вопрос знатокам: перспективная штука?
неизвестно. пока есть только заявления в стиле «ура, мы сделали велосипед с реактивным двигателем!»
> Линус уже одобрил или нет?
show me the code!
| |
|
|
4.58, www2 (??), 07:28, 11/04/2011 [^] [^^] [^^^] [ответить]
| +6 +/– |
Для благодарностей есть кнопочка с плюсом. Она позволяет снизить количество неинформативных комментариев.
| |
|
5.59, emg81 (ok), 08:36, 11/04/2011 [^] [^^] [^^^] [ответить]
| –5 +/– |
> Для благодарностей есть кнопочка с плюсом. Она позволяет снизить количество неинформативных
> комментариев.
спасибо.
:-D
| |
|
|
|
|
1.2, Аноним (-), 00:51, 10/04/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
>Только лишь за счет внедрения технологии в ядро, без каких либо модификаций приложений, им удалось достичь прироста производительности Apache на 116%, MySQL - на 40% и BIND - на 105%
Ждемс, пока будут доступны сырцы, ибо пока сомнительно что-то. Ну и комментарии Линуса были бы кстати
| |
1.5, Живот (?), 01:29, 10/04/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Хм.. Кто знает, как устроен Windows? Какой механизм системных вызовов там?
| |
|
2.18, Аноним (-), 08:55, 10/04/2011 [^] [^^] [^^^] [ответить]
| +/– |
>Хм.. Кто знает, как устроен Windows? Какой механизм системных вызовов там?
это сложный вопрос. в теории они параллельны. те любой тред может инициировать системный вызов независимо от другого. но:
1. есть глобальные блокировки в самом ядре. например, работа с каталогом объектов, кучами и тд.
2. при обращении к разделяемым ресурсам порядок обработки запросов решает не ядро, а драйвер устр-ва.
| |
|
3.72, letsmac (ok), 12:46, 12/04/2011 [^] [^^] [^^^] [ответить]
| +/– |
Марка Руссиновича почитай. Чем больше узнаешь *nix тем более понимаешь насколько качественнее архитектура у Windows/VMS.
| |
|
4.73, anonymous (??), 13:14, 12/04/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Марка Руссиновича почитай. Чем больше узнаешь *nix тем более понимаешь насколько качественнее
> архитектура у Windows/VMS.
то-то они за столько лет даже fork() не смогли сделать, а создание процесса тормозит неимоверно.
| |
|
5.76, letsmac (ok), 17:25, 14/04/2011 [^] [^^] [^^^] [ответить]
| +/– |
> то-то они за столько лет даже fork() не смогли сделать, а создание
> процесса тормозит неимоверно.
Зато время переключения между процессами на 15% меньше, в 7-ке между волокнами вообще в 3-4 раза - а это решающий фактор производительности. Паттерн пул потоков криворуким в помощь. За столько лет nix никак IRP адекватным обзавестись не может.
Fork() - хромой динозавр из прошлого.
| |
|
6.78, anonymous (??), 17:33, 14/04/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Зато время переключения между процессами на 15% меньше
ORLY? proof or GTFO.
> между волокнами
бугога. при чём тут green threads? это реализуется вообще без переключения контекстов.
> За столько лет nix никак IRP адекватным обзавестись не может.
«адекватное» — это тот ужас, который в виндовых драйверах? благодарю, не надо.
> Fork() — хромой динозавр из прошлого.
несколько кривовато сделаная, но очень удобная вещь. хотя вантузники никогда этого не поймут, потому что у них форка нет, а порождение процесса — вещь безумно дорогая.
так и быть, намекну: что будет, если поток загадит чужую память? а если рухнет всего один процесс из нескольких запущеных, и главный папа, заметив это, просто форканётся ещё раз?
| |
|
7.80, Аноним (-), 20:20, 14/04/2011 [^] [^^] [^^^] [ответить] | +/– | В гугл На intel в доки по их фрэймам Во во Ну кушай глобал локи Да да будем... большой текст свёрнут, показать | |
|
|
|
4.75, AdVv (ok), 15:57, 14/04/2011 [^] [^^] [^^^] [ответить]
| +/– |
Что конкретно советуете почитать ? Без сарказма, действительно интересно где у Руссиновича есть сравнение архитектур Windows и Unix.
| |
|
5.77, letsmac (ok), 17:27, 14/04/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Что конкретно советуете почитать ? Без сарказма, действительно интересно где у Руссиновича
> есть сравнение архитектур Windows и Unix.
У Руссиновича и нет. Кто утверждает обратное? Оттуда берется только архитектура винды. По сравнению подходов лучше наверно Таненбаум.
| |
|
6.79, AdVv (ok), 20:09, 14/04/2011 [^] [^^] [^^^] [ответить]
| +/– |
>> Что конкретно советуете почитать ? Без сарказма, действительно интересно где у Руссиновича
>> есть сравнение архитектур Windows и Unix.
> У Руссиновича и нет. Кто утверждает обратное? Оттуда берется только архитектура винды.
> По сравнению подходов лучше наверно Таненбаум.
Т.е. если я понял правильно это было ваше личное мнение, а не Руссиновича ? Интересно было бы услышать аргументы с примерами.
| |
|
7.82, anonymous (??), 20:29, 14/04/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Интересно было бы услышать аргументы с примерами.
это торололо, при попытке вытащить из него доказательства закукливается и периодически несёт бред.
| |
|
|
|
|
|
|
1.6, assss (?), 01:34, 10/04/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
просто каждый вызов сделали ассинхроным + забор батчами
до этого человечество шло 2000 лет ? )
| |
|
2.26, Aquarius (ok), 10:14, 10/04/2011 [^] [^^] [^^^] [ответить]
| –1 +/– |
> просто каждый вызов сделали ассинхроным + забор батчами
> до этого человечество шло 2000 лет ? )
2000 лет назад были операционные системы ? )
| |
|
3.28, anonymous (??), 10:25, 10/04/2011 [^] [^^] [^^^] [ответить]
| –10 +/– |
>> просто каждый вызов сделали ассинхроным + забор батчами
>> до этого человечество шло 2000 лет ? )
> 2000 лет назад были операционные системы ? )
даже андроиды были. одного на кресте выставляли демо-версией. но он потом поломался.
| |
|
4.64, Kodir (?), 12:03, 11/04/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
> даже андроиды были. одного на кресте выставляли демо-версией. но он потом поломался.
:)
"Он слишком много запрещал..."
| |
|
|
|
1.8, iZEN (ok), 01:39, 10/04/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
О, в Linux наконец-то изобрели образец проектирования Future.
| |
|
2.9, ананим (?), 01:41, 10/04/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
ты футурами тут не бросайся.
говори конкретно и с пруфами.
| |
|
3.10, iZEN (ok), 01:50, 10/04/2011 [^] [^^] [^^^] [ответить]
| –2 +/– |
> ты футурами тут не бросайся.
> говори конкретно и с пруфами.
Марк Гранд "Шаблоны проектирования в Java", Новое знание, 2004, ISBN: 5-94735-047-5
Глава 9. Шаблоны проектирования для конкурирующих операций.
Future (Будущее).
| |
|
4.14, ананим (?), 02:48, 10/04/2011 [^] [^^] [^^^] [ответить]
| –3 +/– |
с нетерпением жду ядра на жабе.
когда ожидается релиз?
зыж
и прочитайте уже про юзерспейс и кернелспейс, чтобы не путать их с конкурирующими операциями.
| |
|
5.15, Аноним (-), 03:21, 10/04/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
ты не прав, этот алогритм не зависит от ЯП, ява тут ни при чём.
И у меня есть сомнения в работоспособности этого механизма в случае когда каждый последующий вызов зависит от предыдущего, а это очень большой класс задач.
| |
|
6.17, ананим (?), 08:47, 10/04/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
при чём тут ЯП, если речь идёт о системных вызовах из одного кольца в другое?
>И у меня есть сомнения в работоспособности этого механизма в случае когда каждый последующий вызов зависит от предыдущего, а это очень большой класс задач.
как правило системный вызов - это обращение к тому или иному ресурсу.
а у всех уважающих себя ресурсов есть шедуллеры.
| |
|
7.46, Аноним (-), 17:44, 10/04/2011 [^] [^^] [^^^] [ответить]
| –1 +/– |
> при чём тут ЯП
именно об этом я и писал
> а у всех уважающих себя ресурсов есть шедуллеры.
и? Как это относится к оверхеду от системных вызовов?
| |
|
|
5.39, iZEN (ok), 14:54, 10/04/2011 [^] [^^] [^^^] [ответить]
| +4 +/– |
> с нетерпением жду ядра на жабе.
> когда ожидается релиз?
Причём тут Java? Из-за того, что в названии книги и иллюстрации кода используется этот язык?
Образцы проектирования выявили задолго до появления этого универсального языка.
А поддержка ядерной JVM уже была внедрена в Solaris в качестве экспериментального модуля.
> зыж
> и прочитайте уже про юзерспейс и кернелспейс, чтобы не путать их с
> конкурирующими операциями.
А я не путаю. Когда пачку операций, которые необходимо выполнить, переключая контекст выполнения "юзерспейс-ядро-юзерспейс" не по одной за раз, а собрав их все вместе, распределив последовательность и сделав одно переключение вместо нескольких, то это и есть "обязательство" по выполнению операции в БУДУЩЕМ с естественным (не нарушая семантики вызовов — пользователь ничего не знает о внутренней кухне) оповещением пользователя о результате.
| |
|
6.48, ssssa (?), 18:33, 10/04/2011 [^] [^^] [^^^] [ответить]
| –4 +/– |
>Причём тут Java?
"Марк Гранд Шаблоны проектирования в Java" - ты писал?
не?
| |
|
|
|
|
|
|
2.23, anonymous (??), 09:32, 10/04/2011 [^] [^^] [^^^] [ответить]
| +5 +/– |
> интересно для FreeBSD что нибудь такое появится?
iZEN напишет на java.
| |
|
|
2.27, deadless (ok), 10:20, 10/04/2011 [^] [^^] [^^^] [ответить]
| +/– |
есть красивая pdf-ка, а патчей нет. Код бы глянуть, что он там изобрёл, ато 116% это конечно круто, но что-то слабо верится.
| |
|
3.29, anonymous (??), 10:26, 10/04/2011 [^] [^^] [^^^] [ответить]
| +/– |
> есть красивая pdf-ка, а патчей нет. Код бы глянуть, что он там
> изобрёл, ато 116% это конечно круто, но что-то слабо верится.
что изобрёл — это понятно. намного интересней библиотека, которая группирует вызовы в кучки.
| |
3.30, yaleks (??), 10:39, 10/04/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
Их не будет.
На видео 22:35
- Did it work on linux? Did you tried upstream patcher for the kernel pushes?
- No.
- Did you planned it?
- No.
- Why?!
- Because it think is a lot of timing effort that I prefer to use in another ways.
| |
|
4.32, Гога (?), 11:03, 10/04/2011 [^] [^^] [^^^] [ответить]
| +2 +/– |
Вот злодей какой. Надо его засудить. :) Он нарушает нашу свободу, отказываясь предоставить патчи. :)
| |
4.35, deadless (ok), 13:06, 10/04/2011 [^] [^^] [^^^] [ответить]
| +/– |
нда, видео ночером смотрел без звука, поэтому этот момент пролетел мимо, тогда все понятно. Но я думаю если идея стоящая и она не вызывает регрессий в других местах (вот тут у меня как раз сомнения), то ее изобретут снова :)
| |
|
|
|
1.40, assss (?), 16:20, 10/04/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
думаю ядро не дураки делают
и уже думали о таком улучшении,
но вообще интересно мнение разработчиков ядра плюсы и минусы.
| |
|
2.42, Etch (?), 17:00, 10/04/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
> думаю ядро не дураки делают
Жираф большоооой, ему видней?
| |
|
1.43, Аноним (-), 17:17, 10/04/2011 [ответить] [﹢﹢﹢] [ · · · ] | +1 +/– | Тут и без Линуса все ясно Разработка носит скорее академический интерес а вот ... большой текст свёрнут, показать | |
|
2.44, Аноним (-), 17:32, 10/04/2011 [^] [^^] [^^^] [ответить] | +1 +/– | Another important metric for servicing Web requests besides throughput is latenc... большой текст свёрнут, показать | |
|
3.45, Аноним (-), 17:44, 10/04/2011 [^] [^^] [^^^] [ответить]
| +/– |
Диагонального просмотра хватило чтобы понять что в статье полно спорных моментов и мелких подтасовок. Так что поумерьте аппетит, навряд ли такое будет вообще принято. Хотя, какие-нибудь мелкие микрооптимизации может это и навеет, но речь там будет идти про проценты на определенном классе задач и ситуаций.
| |
|
4.49, deadless (ok), 19:56, 10/04/2011 [^] [^^] [^^^] [ответить]
| +/– |
на хорошо грузящих камень задачах, то есть если у вас идет кодирование видео в 4 потока на 4 ядрах, автор прямо говорит "don't use this", теоретический выигрыш может быть там где часто переключается контекст
| |
|
5.56, umbr (ok), 02:54, 11/04/2011 [^] [^^] [^^^] [ответить]
| +/– |
>там где часто переключается контекст
У быдлокодеров появится новая лазейка.
| |
|
|
|
2.60, zhnavigator (?), 09:41, 11/04/2011 [^] [^^] [^^^] [ответить]
| +/– |
Читать надо внимательно, а не сочинять на ходу... Речь идет о группировке вызовов разными потоками процесса! Как раз в апаче таким потоков может быть 200 и более...
| |
|
3.66, Аноним (-), 12:29, 11/04/2011 [^] [^^] [^^^] [ответить] | +2 +/– | Да я как раз таки прекрасно понял что это означает Это означает, дорогой мой, ч... большой текст свёрнут, показать | |
|
4.74, zhnavigator (?), 15:14, 13/04/2011 [^] [^^] [^^^] [ответить]
| +/– |
Никто никого не ждет, поступающие запросы сразу же выполняются внутренним потоком FlexSC, дорогой твой.
| |
|
|
2.65, Kodir (?), 12:12, 11/04/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Разработка носит скорее академический интерес
+1.
Выйгрыш будет на задачах, где системный вызов, условно говоря, ничего не значит. Например, запись в лог: write,write,close. Но я интуитивно чую, что таких мест в программах очень мало - алгоритм есть алгоритм, каждая строчка важна для последующих.
Мне кажется, "если хочешь избавиться от переключений контекста, выкинь этот контекст!". Т.е. всё исполнять в едином пространстве, а защиту осуществлять более глубоким контролем вызовов.
| |
|
3.69, vle (ok), 14:36, 11/04/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Мне кажется, "если хочешь избавиться от переключений контекста,
> выкинь этот контекст!".
> Т.е. всё исполнять в едином пространстве,
Очень светлая мысль. Именно так люди и делают
во всяких там Ерлангах и Го. Высокопроизводительные
сервера не надо писать на C и системных потоках,
которые нынче 1:1 практически везде.
> а защиту
> осуществлять более глубоким контролем вызовов.
А защита обеспечивается безопасностью языка программирования.
Другой вариант -- удешевить стоимость переключения контекста.
Вот интересная на мой взгляд статья.
http://www.osp.ru/os/2007/05/4259887/
Ну и последнее -- конечно остаются средства асинхронного I/O
типа kqueue или epoll. Здесь все нужно делать руками,
и это порой нелегко.
| |
|
4.70, тру йода (?), 16:28, 11/04/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
Да и вообще - если ваша задача генерит 100500 запросов к ядру и из-за этого тормозит то править надо консерваторию, я не ядро.
| |
|
|
|
1.51, Vitto74 (ok), 21:21, 10/04/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Если это действительно работает и эффективно работает, то будет очень весело наблюдать как производительность приложений под wine поднимается выше, чем под виндой, на одном и том же железе.
| |
1.53, pavlinux (ok), 23:27, 10/04/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Потом предлагаю впиндюрить
* Syscall scheduler
* Syscall Autogroup
* Syscall Branch Prediction
:)
| |
1.57, Игорь (??), 06:24, 11/04/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
все равно узким местом будут операции ввода/вывода на носители
прирост почувствуется только если прога на диск никуда не лезет
| |
1.61, zhnavigator (?), 09:45, 11/04/2011 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
90% комментаторов даже не въехали в суть... при этом на ходу придумывают какие-то мифические доводы, что это плохо...
| |
|
2.68, Аноним (-), 14:20, 11/04/2011 [^] [^^] [^^^] [ответить]
| +/– |
Единственный комментатор который въехал в суть. Поздравляю!
А остальные просто ее хорошо поняли ну или вникли в нее.
| |
|
|