| |
| 2.20, anonymous (??), 09:15, 10/04/2011 [^] [^^] [^^^] [ответить] [↑] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +3 +/– |
 > вопрос знатокам: перспективная штука?
неизвестно. пока есть только заявления в стиле «ура, мы сделали велосипед с реактивным двигателем!»
> Линус уже одобрил или нет?
show me the code!
| | |
|
| 1.2, Аноним (-), 00:51, 10/04/2011 [ответить] [﹢﹢﹢] [ · · · ] [↑] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +4 +/– | |
>Только лишь за счет внедрения технологии в ядро, без каких либо модификаций приложений, им удалось достичь прироста производительности Apache на 116%, MySQL - на 40% и BIND - на 105%
Ждемс, пока будут доступны сырцы, ибо пока сомнительно что-то. Ну и комментарии Линуса были бы кстати
| | |
| |
| 2.18, Аноним (-), 08:55, 10/04/2011 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– | |
>Хм.. Кто знает, как устроен Windows? Какой механизм системных вызовов там?
это сложный вопрос. в теории они параллельны. те любой тред может инициировать системный вызов независимо от другого. но:
1. есть глобальные блокировки в самом ядре. например, работа с каталогом объектов, кучами и тд.
2. при обращении к разделяемым ресурсам порядок обработки запросов решает не ядро, а драйвер устр-ва.
| | |
| |
| |
| 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() — хромой динозавр из прошлого.
несколько кривовато сделаная, но очень удобная вещь. хотя вантузники никогда этого не поймут, потому что у них форка нет, а порождение процесса — вещь безумно дорогая.
так и быть, намекну: что будет, если поток загадит чужую память? а если рухнет всего один процесс из нескольких запущеных, и главный папа, заметив это, просто форканётся ещё раз?
| | |
|
|
| |
| 5.77, letsmac (ok), 17:27, 14/04/2011 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– |
> Что конкретно советуете почитать ? Без сарказма, действительно интересно где у Руссиновича
> есть сравнение архитектур Windows и Unix.
У Руссиновича и нет. Кто утверждает обратное? Оттуда берется только архитектура винды. По сравнению подходов лучше наверно Таненбаум.
| | |
| |
| 6.79, AdVv (ok), 20:09, 14/04/2011 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– |
 >> Что конкретно советуете почитать ? Без сарказма, действительно интересно где у Руссиновича
>> есть сравнение архитектур Windows и Unix.
> У Руссиновича и нет. Кто утверждает обратное? Оттуда берется только архитектура винды.
> По сравнению подходов лучше наверно Таненбаум.
Т.е. если я понял правильно это было ваше личное мнение, а не Руссиновича ? Интересно было бы услышать аргументы с примерами.
| | |
|
|
|
|
|
| |
| |
| 3.28, anonymous (??), 10:25, 10/04/2011 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| –10 +/– |
>> просто каждый вызов сделали ассинхроным + забор батчами
>> до этого человечество шло 2000 лет ? )
> 2000 лет назад были операционные системы ? )
даже андроиды были. одного на кресте выставляли демо-версией. но он потом поломался.
| | |
|
|
| |
| |
| 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 +/– |
при чём тут ЯП, если речь идёт о системных вызовах из одного кольца в другое?
>И у меня есть сомнения в работоспособности этого механизма в случае когда каждый последующий вызов зависит от предыдущего, а это очень большой класс задач.
как правило системный вызов - это обращение к тому или иному ресурсу.
а у всех уважающих себя ресурсов есть шедуллеры.
| | |
|
| 5.39, iZEN (ok), 14:54, 10/04/2011 [^] [^^] [^^^] [ответить] [↑] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +4 +/– |
> с нетерпением жду ядра на жабе.
> когда ожидается релиз?
Причём тут Java? Из-за того, что в названии книги и иллюстрации кода используется этот язык?
Образцы проектирования выявили задолго до появления этого универсального языка.
А поддержка ядерной JVM уже была внедрена в Solaris в качестве экспериментального модуля.
> зыж
> и прочитайте уже про юзерспейс и кернелспейс, чтобы не путать их с
> конкурирующими операциями.
А я не путаю. Когда пачку операций, которые необходимо выполнить, переключая контекст выполнения "юзерспейс-ядро-юзерспейс" не по одной за раз, а собрав их все вместе, распределив последовательность и сделав одно переключение вместо нескольких, то это и есть "обязательство" по выполнению операции в БУДУЩЕМ с естественным (не нарушая семантики вызовов — пользователь ничего не знает о внутренней кухне) оповещением пользователя о результате.
| | |
|
|
|
|
| |
| |
| 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.35, deadless (ok), 13:06, 10/04/2011 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– |
 нда, видео ночером смотрел без звука, поэтому этот момент пролетел мимо, тогда все понятно. Но я думаю если идея стоящая и она не вызывает регрессий в других местах (вот тут у меня как раз сомнения), то ее изобретут снова :)
| | |
|
|
|
| |
| |
| 3.45, Аноним (-), 17:44, 10/04/2011 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– |
Диагонального просмотра хватило чтобы понять что в статье полно спорных моментов и мелких подтасовок. Так что поумерьте аппетит, навряд ли такое будет вообще принято. Хотя, какие-нибудь мелкие микрооптимизации может это и навеет, но речь там будет идти про проценты на определенном классе задач и ситуаций.
| | |
| |
| 4.49, deadless (ok), 19:56, 10/04/2011 [^] [^^] [^^^] [ответить] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– |
на хорошо грузящих камень задачах, то есть если у вас идет кодирование видео в 4 потока на 4 ядрах, автор прямо говорит "don't use this", теоретический выигрыш может быть там где часто переключается контекст
| | |
|
|
| 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. Здесь все нужно делать руками,
и это порой нелегко.
| | |
|
|
| 1.51, Vitto74 (ok), 21:21, 10/04/2011 [ответить] [﹢﹢﹢] [ · · · ] [↓] [↑] [п╨ п╪п╬п╢п╣я─п╟я┌п╬я─я┐]
| +/– |
 Если это действительно работает и эффективно работает, то будет очень весело наблюдать как производительность приложений под wine поднимается выше, чем под виндой, на одном и том же железе.
| | |
|
