The whole "let's parallelize" thing is a huge waste of everybody's time. There's this huge body of "knowledge" that parallel is somehow more efficient, and that whole huge body is pure and utter garbage. Big caches are efficient. Parallel stupid small cores without caches are horrible unless you have a very specific load that is hugely regular (ie graphics).
И он прав. Разговоры про большое значение multi core и парралелизм были ещё в 2005 году на моей памяти. Саттеровские "free lunch is over" and shit предсказывали, что через 10 лет мы все будем сидеть толстой задницей на 256 корах. Нифига этого не случилось. А что случилось? Как раз таки что Линус говорит:
We know that we need fairly complex OoO CPU's anyway, because people want reasonable performance and it turns out OoO is actually more efficient than slow in-order.
Можно смело сказать, что и далее улучшение производительности будет происходить путём утолщения кэшей и улучшения эффективности внеочередного выполнения операций процессором для более быстрого выполнения однопоточных программ. Т.е. все улучшения опять же на хардверном уровне. А софтверный параллелизм к сожалению себя ещё нигде не проявил.
Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, uncommon, Вы писали:
U>>А софтверный параллелизм к сожалению себя ещё нигде не проявил.
D>В вебе?
Самая наиболее переспективная технология в вебе сегодня, nodejs, является однопоточной.
> Причём при нормальной архитектуре он там обеспечивается автоматически.
Здравствуйте, uncommon, Вы писали:
U>Товарищ Торвальдс опять вбросил: U>http://www.realworldtech.com/forum/?threadid=146066&curpostid=146227 U>И он прав. Разговоры про большое значение multi core и парралелизм были ещё в 2005 году на моей памяти. Саттеровские "free lunch is over" and shit предсказывали, что через 10 лет мы все будем сидеть толстой задницей на 256 корах. Нифига этого не случилось.
Тут некоторые противоречия есть:
1) OoO — это по сути дела и есть параллелизм, только на "микроуровне" и доступный лишь косвенно. В новых процессорах его постепенно делают доступным и явно для программиста (см. транзакционную память и спекулятивное исполнение на новых Intel'ах).
2) Сам Линукс постоянно делается всё более параллельным, так как: "у него не было другого выбора" (с) не помню. Сложность реализации местами уже зашкаливает (см.: https://lwn.net/Articles/609904/ ), но при этом набор доступных прикладному программисту параллельных примитивов становится всё шире.
3) Приходит понимание того, что хотя ранние наивные предсказания вида "скоро каждый for-each цикл будет параллельным" и не сбылись — распараллеливать системы всё равно придётся. Точнее даже не распараллеливать, а распределять.
4) Ни микроуровне память становится всё больше и есть желание отправить обработку как можно ближе к ней. В обработке голоса, например, один наш клиент использует процессоры Tilera — там на чипе порядка 72 маленьких CPU, каждый из которых имеет доступ к своему кусочку памяти. Всё это общается через шину с перенастраиваемой на лету топологией. Это уже чем-то начинает напоминать биологический мозг — в нём тоже множество отделов, которые общаются через специальные шины.
Здравствуйте, uncommon, Вы писали:
U>А софтверный параллелизм к сожалению себя ещё нигде не проявил.
Ну енто передергивание, поскольку есть так называемый data level parallelism, о котором
Торвальдс и говорит. А есть task level parallelism, который вполне себе нормальный.
Здравствуйте, Cyberax, Вы писали:
C>1) OoO — это по сути дела и есть параллелизм, только на "микроуровне" и доступный лишь косвенно. В новых процессорах его постепенно делают доступным и явно для программиста (см. транзакционную память и спекулятивное исполнение на новых Intel'ах).
А кому надо заморачиваться явно со спекулятивными вычислениями? Для этого есть компилятор.
C>4) Ни микроуровне память становится всё больше и есть желание отправить обработку как можно ближе к ней. В обработке голоса, например, один наш клиент использует процессоры Tilera — там на чипе порядка 72 маленьких CPU, каждый из которых имеет доступ к своему кусочку памяти. Всё это общается через шину с перенастраиваемой на лету топологией. Это уже чем-то начинает напоминать биологический мозг — в нём тоже множество отделов, которые общаются через специальные шины.
Кстати, один из архитекторов Tiler'ы читает курс на курсере про устройство процессоров. Но Вы это наверняка знаете
Здравствуйте, Sharov, Вы писали:
S>Ну енто передергивание, поскольку есть так называемый data level parallelism, о котором S>Торвальдс и говорит. А есть task level parallelism, который вполне себе нормальный.
Ваш "task level parallelism" никакого профита не предоставит, если эти таски будут
драться за один и тот же data ресурс. Все эти механизмы синхронизации являются не более
чем жаропонижающими. Для увеличения производительности параллелизмом, необходимо, прежде всего,
распараллеливать данные, то есть всё, в конечном итоге, сводится к упомянутому data level parallelism.
А для проследнего уже нужны большие кеши, и прочее, о чём Торвальдс и ворчит.
Здравствуйте, Sharov, Вы писали:
C>>1) OoO — это по сути дела и есть параллелизм, только на "микроуровне" и доступный лишь косвенно. В новых процессорах его постепенно делают доступным и явно для программиста (см. транзакционную память и спекулятивное исполнение на новых Intel'ах). S>А кому надо заморачиваться явно со спекулятивными вычислениями? Для этого есть компилятор.
У компилятора это не получится, нужно явно указывать точки, где нужно выбирать какую ветку выполнения считать реальностью.
S>Кстати, один из архитекторов Tiler'ы читает курс на курсере про устройство процессоров. Но Вы это наверняка знаете
Кстати, нет. Хотя архитекторов мы знаем
Здравствуйте, smeeld, Вы писали:
S>Здравствуйте, Sharov, Вы писали:
S>>Ну енто передергивание, поскольку есть так называемый data level parallelism, о котором S>>Торвальдс и говорит. А есть task level parallelism, который вполне себе нормальный.
S>Ваш "task level parallelism" никакого профита не предоставит, если эти таски будут S>драться за один и тот же data ресурс.
Это уже будет data level parallelism. Смысл Вашего комментария не ясен.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sharov, Вы писали:
C>>>1) OoO — это по сути дела и есть параллелизм, только на "микроуровне" и доступный лишь косвенно. В новых процессорах его постепенно делают доступным и явно для программиста (см. транзакционную память и спекулятивное исполнение на новых Intel'ах). S>>А кому надо заморачиваться явно со спекулятивными вычислениями? Для этого есть компилятор. C>У компилятора это не получится, нужно явно указывать точки, где нужно выбирать какую ветку выполнения считать реальностью.
Это как? Это же становиться ясно только во время вычисления. Сейчас вроде branch prediction уже на уровне что-то
около 97% угадываний. Так что не совсем понятно, что кому-то выбирать реальную ветку.
S>>Кстати, один из архитекторов Tiler'ы читает курс на курсере про устройство процессоров. Но Вы это наверняка знаете C>Кстати, нет. Хотя архитекторов мы знаем https://www.coursera.org/course/comparch
S>Это уже будет data level parallelism. Смысл Вашего комментария не ясен.
Эффективный task level parallelism невозможен без data level parallelism-а, иначе
таски будут пребывать в состоянии конкуренции и драться за data ресурс, если последний
не распараллелен, при любом из существующих механизмов синхронизации. В ядрах и linux, и
solaris, данные распараллелены в памяти по ядрам, насколько только оно возможно для каждого
из типа данных, для каждого ядра свой поток и свой набор данных для обработки, чтоб минимизировать
количество локов или RCU, например, просмотрите использование этого макроса.
Здравствуйте, Sharov, Вы писали:
C>>У компилятора это не получится, нужно явно указывать точки, где нужно выбирать какую ветку выполнения считать реальностью. S>Это как? Это же становиться ясно только во время вычисления. Сейчас вроде branch prediction уже на уровне что-то S>около 97% угадываний. Так что не совсем понятно, что кому-то выбирать реальную ветку.
Речь идёт о коде типа:
int a = 33; //Shared data
take_lock();
if (a == 33)
a+=1;
release_lock();
Новые Intel'ы начинают параллельно брать блокировку в take_lock() и выполнять дальнейший код. При этом изменения накапливаются в виде транзакции и атомарно коммитятся в методе release_lock(). Если какой-то другой поток меняет любую область памяти, которая участвует в транзакции — вся транзакция откатывается и выполнение снова перезапускается с метода take_lock().
Программист тут нужен для того, чтобы указывать границы транзакций.
S>Эффективный task level parallelism невозможен без data level parallelism-а, иначе S>таски будут пребывать в состоянии конкуренции и драться за data ресурс, если последний S>не распараллелен, при любом из существующих механизмов синхронизации. В ядрах и linux, и S>solaris, данные распараллелены в памяти по ядрам, насколько только оно возможно для каждого S>из типа данных, для каждого ядра свой поток и свой набор данных для обработки, чтоб минимизировать S>количество локов или RCU, например, просмотрите использование этого макроса.
У эффективного task level parallelism практически нет расшаренных данных.
U>Можно смело сказать, что и далее улучшение производительности будет происходить путём утолщения кэшей и улучшения эффективности внеочередного выполнения операций процессором для более быстрого выполнения однопоточных программ. Т.е. все улучшения опять же на хардверном уровне. А софтверный параллелизм к сожалению себя ещё нигде не проявил.
А nodejs — самая перспективная технология в вебе, ага, как же. Во первых, Линуса ты немного неверно понял, он говорил немного о другом. Во вторых, с софтверным параллелизмом как раз таки все ок, вокруг полно приложений использующих его успешно. Тот же хардварный парралелизм (instruction level parallelism, out of order execution) нужно уметь использовать, это немного сложнее чем распараллелить какую-нибудь inherently parallel задачу.
Здравствуйте, AlexRK, Вы писали:
C>>Речь идёт о коде типа: ARK>А если там внутри ИО? Тогда сам себе злобный буратино?
Если это запись в специальные PCI-регистры, то CPU это отловит. Но в большинстве случаев с точки зрения процессора прикладной IO ничем не отличается от обычной транзакционной записи в память.
Здравствуйте, Cyberax, Вы писали:
C>>>Речь идёт о коде типа: ARK>>А если там внутри ИО? Тогда сам себе злобный буратино? C>Если это запись в специальные PCI-регистры, то CPU это отловит. Но в большинстве случаев с точки зрения процессора прикладной IO ничем не отличается от обычной транзакционной записи в память.
Ну ясно. Короче, будет задница. Впрочем, чудес не бывает, это очевидно.
U>The whole "let's parallelize" thing is a huge waste of everybody's time. There's this huge body of "knowledge" that parallel is somehow more efficient, and that whole huge body is pure and utter garbage. Big caches are efficient. Parallel stupid small cores without caches are horrible unless you have a very specific load that is hugely regular (ie graphics).
U>И он прав. Разговоры про большое значение multi core и парралелизм были ещё в 2005 году на моей памяти. Саттеровские "free lunch is over" and shit предсказывали, что через 10 лет мы все будем сидеть толстой задницей на 256 корах. Нифига этого не случилось. А что случилось? Как раз таки что Линус говорит:
U>
U>We know that we need fairly complex OoO CPU's anyway, because people want reasonable performance and it turns out OoO is actually more efficient than slow in-order.
U>Можно смело сказать, что и далее улучшение производительности будет происходить путём утолщения кэшей и улучшения эффективности внеочередного выполнения операций процессором для более быстрого выполнения однопоточных программ. Т.е. все улучшения опять же на хардверном уровне. А софтверный параллелизм к сожалению себя ещё нигде не проявил.
Вот только его уже давно опередили те, которым он показывал факи — производители истинно-параллельных аппаратных комплексов-на-кристалле (Nvidia).
Здравствуйте, uncommon, Вы писали:
U>Можно смело сказать, что и далее улучшение производительности будет происходить путём утолщения кэшей и улучшения эффективности внеочередного выполнения операций процессором для более быстрого выполнения однопоточных программ. Т.е. все улучшения опять же на хардверном уровне. А софтверный параллелизм к сожалению себя ещё нигде не проявил.
А у меня есть решение.. Причем прерывания можно обрабатывать не прерывая выполняющуюся программу.. Кое-что, правда, надо изменить.. Но, это отдельная тема для разговора с интересующимися..
