Здравствуйте, dimgel, Вы писали:
D>Здравствуйте, uncommon, Вы писали:
U>>А софтверный параллелизм к сожалению себя ещё нигде не проявил.
D>В вебе?
Самая наиболее переспективная технология в вебе сегодня, nodejs, является однопоточной.
> Причём при нормальной архитектуре он там обеспечивается автоматически.
Здравствуйте, uncommon, Вы писали:
U>А софтверный параллелизм к сожалению себя ещё нигде не проявил.
Ну енто передергивание, поскольку есть так называемый data level parallelism, о котором
Торвальдс и говорит. А есть task level parallelism, который вполне себе нормальный.
Здравствуйте, uncommon, Вы писали:
U>И он прав. Разговоры про большое значение multi core и парралелизм были ещё в 2005 году на моей памяти. Саттеровские "free lunch is over" and shit предсказывали, что через 10 лет мы все будем сидеть толстой задницей на 256 корах. Нифига этого не случилось. А что случилось? Как раз таки что Линус говорит:
Смотря где не случилось. В видеокартах, например, параллелизм охрененный. И если посмотреть на картинку современной игрушки — хренеешь от прогресса. При этом даже на технике 10 летней давности, но с параллелизмом, картинка выдается просто охрененная (пример — PS3 и игрушка The last of us). В серверах тоже параллелизм охрененный, и все ядра прекрасно задействуются (гугл же не тормозит !). Научные расчеты, там тоже все неплохо параллелится. Кодеки фильмов, архиваторы — тоже параллелятся неплохо. В формоклепательстве да, от параллелизма смысла мало. В клепании бизнес логики тоже выгоды мало будет. Но мощи даже бюджетных процессоров уже давно более чем достаточно для офисных приложений, браузера и т.д.
И параллелизм не исчерпывается процессорными ядрами. Всякие датацентры — там тоже параллелизм черти как. RAID — тоже параллелизм. SIMD инструкции — тоже параллелизм. На уровне просто выполнения процессорных команд — тоже давно идет параллелизм. И это совсем не ново, если что. Параллелизм активно юзался и 20 лет назад, и 30 в суперкомпьютерах. Он относительно нов только в бытовых ПК.
Соответственно параллелизм есть, он охрененный, но он локализован внутри библиотек, движков и т.д. А в обычный быдлокод и формоклепательства я не уверен что он вообще когда либо придет.
Здравствуйте, 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, каждый из которых имеет доступ к своему кусочку памяти. Всё это общается через шину с перенастраиваемой на лету топологией. Это уже чем-то начинает напоминать биологический мозг — в нём тоже множество отделов, которые общаются через специальные шины.
ARK>Ну ясно. Короче, будет задница. Впрочем, чудес не бывает, это очевидно.
Никакой задницы, транзакции не выходят за пределы L1 кеша см. выше. Это все уже сейчас юзается, уже есть поддержка со стороны Intel TBB и других библиотек. В принципе, можно без последствий заменить все мьютексы в программе на мьютексы использующие lock elision и получить прирост производительности без негативных последствий.
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.
Можно смело сказать, что и далее улучшение производительности будет происходить путём утолщения кэшей и улучшения эффективности внеочередного выполнения операций процессором для более быстрого выполнения однопоточных программ. Т.е. все улучшения опять же на хардверном уровне. А софтверный параллелизм к сожалению себя ещё нигде не проявил.
Здравствуйте, smeeld, Вы писали:
S>Здравствуйте, Sharov, Вы писали:
S>>Ну енто передергивание, поскольку есть так называемый data level parallelism, о котором S>>Торвальдс и говорит. А есть task level parallelism, который вполне себе нормальный.
S>Ваш "task level parallelism" никакого профита не предоставит, если эти таски будут S>драться за один и тот же data ресурс.
Это уже будет data level parallelism. Смысл Вашего комментария не ясен.
Он прав — паралельное программирование в тупике это сейчас типа даже все уже очевидно. Лет пять назад я вот лично гворил, такое ( после 5 лет до этого находясь в плотной разработке паралельных программ) мне говорили, что я типа что-то не то говорю.
Проблема в паралельном программировании лежит в нескольких плоскостях
1) Нет достаточно умных людей (в достаточном количестве) которые бы могли делать архитектуру для того чтобы паралельное программирование работало.
2) Тренд за последнее время в разработке средств разработки шел в сторону упрошения этого процессе — ну типа чтобы "не гении могли делать код".
3) Даже сейчас мало кто понимает, что даже если распаралелить цикл, на 10 ядер, это не даст прироста в скорости решения задачи.
Тут либо настанет опять такое время когда в стоимости программиста будет первостепенную роль играть ум, а не знание библиотек и умение быстро разрабатывать.
Такое время было от 70-ых годов до появления персоналок.
А теперь ссылки на то, как эти бредни скинтистов воплощены в конкретных компиляторах, желательно, в
GCC или LLVM, чтоб ссылки были на файлы с исходниками, а то в теориях, знаете ли, и что такое вселенная
известно, в каждой по своему, а в CS так вообще насочиняли бреда, которое к реальному железу отношения не
имеет, а для воплощения в программной реализации оно слишком отдалено от конретных задач, для каждой из который
правильней будет придумывать схемы и алгоритмы для каждой задачи самостоятельно, (что и делатется всеми практикующими
разработчиками) а не рыться в тоннах бреда, насочинённого скинтистами.
ARK>Контроль правильности использования контрактов каналов в Singularity — это контроль логики исполнения? ARK>А как насчет Typestates?
Не нужно википедий, там сочиняют все кому не лень, приведите ссылки на спеки существующих интерфейсов периферийных
устройств, CPU, в которых были бы прописаны реализованные механизмы контроля логики исполнения транзакционной модели
на их уровне, а не на уровне алгоритма прикладной программы.
Здравствуйте, 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'ы читает курс на курсере про устройство процессоров. Но Вы это наверняка знаете
Кстати, нет. Хотя архитекторов мы знаем
Здравствуйте, 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>Можно смело сказать, что и далее улучшение производительности будет происходить путём утолщения кэшей и улучшения эффективности внеочередного выполнения операций процессором для более быстрого выполнения однопоточных программ. Т.е. все улучшения опять же на хардверном уровне. А софтверный параллелизм к сожалению себя ещё нигде не проявил.
А у меня есть решение.. Причем прерывания можно обрабатывать не прерывая выполняющуюся программу.. Кое-что, правда, надо изменить.. Но, это отдельная тема для разговора с интересующимися..
Здравствуйте, AlexRK, Вы писали:
C>>Если это запись в специальные PCI-регистры, то CPU это отловит. Но в большинстве случаев с точки зрения процессора прикладной IO ничем не отличается от обычной транзакционной записи в память. ARK>Ну ясно. Короче, будет задница. Впрочем, чудес не бывает, это очевидно.
То есть? С точки зрения CPU нет никакого IO.
Здравствуйте, Cyberax, Вы писали:
C>>>Если это запись в специальные PCI-регистры, то CPU это отловит. Но в большинстве случаев с точки зрения процессора прикладной IO ничем не отличается от обычной транзакционной записи в память. ARK>>Ну ясно. Короче, будет задница. Впрочем, чудес не бывает, это очевидно. C>То есть? С точки зрения CPU нет никакого IO.
Но есть некорректное поведение программы, которая выводит три раза лист на принтер, вместо одного.
Здравствуйте, AlexRK, Вы писали:
ARK>>>Ну ясно. Короче, будет задница. Впрочем, чудес не бывает, это очевидно. C>>То есть? С точки зрения CPU нет никакого IO. ARK>Но есть некорректное поведение программы, которая выводит три раза лист на принтер, вместо одного.
А ты подумай, КАК ты выводишь данные на принтер?
В x86 это сводится, в итоге, к копированию данных в нужный участок памяти (на который отображаются нужные регистры устройств).
Так что всё ОК — устройство "увидит" данные ровно тогда, когда будет закоммичена транзакция. На практике, с текущей реализацией транзакция вообще сразу же откатится, как только заденет некэшируемую память.
S>Это как? Это же становиться ясно только во время вычисления. Сейчас вроде branch prediction уже на уровне что-то S>около 97% угадываний. Так что не совсем понятно, что кому-то выбирать реальную ветку.
Это как, простите? А если вероятность каждой ветки 50% — он тоже с точностью 97% предскажет?
ARK>>А если там внутри ИО? Тогда сам себе злобный буратино? C>Если это запись в специальные PCI-регистры, то CPU это отловит. Но в большинстве случаев с точки зрения процессора прикладной IO ничем не отличается от обычной транзакционной записи в память.
Не совсем так, транзакция просто откатится и будет выполняться под обычным локом (если речь идет о lock elision). Если такая транзакция перепишет слишком много памяти то произойдет тоже самое.
Здравствуйте, chaotic-good, Вы писали:
S>>Это как? Это же становиться ясно только во время вычисления. Сейчас вроде branch prediction уже на уровне что-то S>>около 97% угадываний. Так что не совсем понятно, что кому-то выбирать реальную ветку.
CG>Это как, простите? А если вероятность каждой ветки 50% — он тоже с точностью 97% предскажет?
Ога, особенно в циклах. Можно в гугл -- "branch prediction accuracy". Можно в нашу вики (первый абзац),
можно сюда (3-й слайд).
S>Ога, особенно в циклах. Можно в гугл -- "branch prediction accuracy". Можно в нашу вики (первый абзац), S>можно сюда (3-й слайд).
Ну так это средняя температура по палате, можно запросто написать такой код, который будет ошибаться в 50% случаев, ну т.е. точность предсказания будет как у подбрасываемой монетки или как если бы мы все время выбирали один и тот же бранч. Вооот, и я бы не стал утверждать, что такой код не встречается в реальной жизни. Просто большинство ветвлений легко предсказывется, это ветвление в цикле на переменной цикла и проверки всяких кодов ошибок. Это вовсе не говорит о том, что любой бранч может быть предсказан с такой точность, как и не говорит о том, что приложение не может тратить значительную часть процессорного времени на branch misspredictions.
Здравствуйте, chaotic-good, Вы писали:
S>>Ога, особенно в циклах. Можно в гугл -- "branch prediction accuracy". Можно в нашу вики (первый абзац), S>>можно сюда (3-й слайд).
CG>Ну так это средняя температура по палате, можно запросто написать такой код, который будет ошибаться в 50% случаев, ну т.е. точность предсказания будет как у подбрасываемой монетки или как если бы мы все время выбирали один и тот же бранч. Вооот, и я бы не стал утверждать, что такой код не встречается в реальной жизни. Просто большинство ветвлений легко предсказывется, это ветвление в цикле на переменной цикла и проверки всяких кодов ошибок. Это вовсе не говорит о том, что любой бранч может быть предсказан с такой точность, как и не говорит о том, что приложение не может тратить значительную часть процессорного времени на branch misspredictions.
Специально написать можно, но даже и в этом случае вроде бы сущ. алгоритмы, которые могут предсказывать
лучше чем 50%. Я когда брал принстонский курс на курсере по архитектуре компьютера-процессора, то там были
ссылки(лень искать) на какой-то мега крутой алгоритм предсказания, что чуть ли там не ML и прочие новомодные штукенции используются.
Другой вопрос, насколько это сложно и реально имплементировать в железе.
Т.е. Ваша позиция верна, но средний градус таков, что таки предсказания могут верны в 98% случаев уже сейчас.
S>Специально написать можно, но даже и в этом случае вроде бы сущ. алгоритмы, которые могут предсказывать S>лучше чем 50%. Я когда брал принстонский курс на курсере по архитектуре компьютера-процессора, то там были S>ссылки(лень искать) на какой-то мега крутой алгоритм предсказания, что чуть ли там не ML и прочие новомодные штукенции используются. S>Другой вопрос, насколько это сложно и реально имплементировать в железе.
FCM predictors (и прочие, что там используются) на ml немного не тянут, не стоит преувеличивать
S>Т.е. Ваша позиция верна, но средний градус таков, что таки предсказания могут верны в 98% случаев уже сейчас.
В среднем, ну тоесть как средняя температура в году на земле
Что имеет значение, так это то, что не все может быть точно предсказано и об этом все равно приходится думать (о том, какими будут данные, например) и иногда даже подсказывать компилятору с помощью __builtin_expect а можно даже использовать возможности спекулятивного исполнения и предсказания ветвлений для оптимизации загруок из памяти, но для этого, опять же, следует понимать что может быть предсказано а что нет.
Здравствуйте, chaotic-good, Вы писали:
S>>Специально написать можно, но даже и в этом случае вроде бы сущ. алгоритмы, которые могут предсказывать S>>лучше чем 50%. Я когда брал принстонский курс на курсере по архитектуре компьютера-процессора, то там были S>>ссылки(лень искать) на какой-то мега крутой алгоритм предсказания, что чуть ли там не ML и прочие новомодные штукенции используются. S>>Другой вопрос, насколько это сложно и реально имплементировать в железе.
CG>FCM predictors (и прочие, что там используются) на ml немного не тянут, не стоит преувеличивать
Честно не помню, но шума на форуме статейка наделала. Про ml может и загнул.
S>>Т.е. Ваша позиция верна, но средний градус таков, что таки предсказания могут верны в 98% случаев уже сейчас. CG>В среднем, ну тоесть как средняя температура в году на земле
В том то и дело, что нет.
CG>Что имеет значение, так это то, что не все может быть точно предсказано и об этом все равно приходится думать
О чем и речь, что можно переходы генерировать каким-нибудь мега генератором псевдослучайных чисел и
профита будет мало. А на большинстве кода результаты вполне себе.
S>О чем и речь, что можно переходы генерировать каким-нибудь мега генератором псевдослучайных чисел и S>профита будет мало. А на большинстве кода результаты вполне себе.
Ну элементарный пример — идешь по массиву указателей, зовешь виртуальный метод у каждого объекта, объекты разных типов, получаешь низкую точность предсказания ветвлений (и простой конвеера пока происходит загрузка адреса метода из памяти по указателю на объект). Сортируешь массив по типу объектов — работает сильно быстрее. Для точности конечно нужно вначале кеши прогреть, ес-но.
Здравствуйте, chaotic-good, Вы писали:
S>>О чем и речь, что можно переходы генерировать каким-нибудь мега генератором псевдослучайных чисел и S>>профита будет мало. А на большинстве кода результаты вполне себе.
CG>Ну элементарный пример — идешь по массиву указателей, зовешь виртуальный метод у каждого объекта, объекты разных типов, получаешь низкую точность предсказания ветвлений (и простой конвеера пока происходит загрузка адреса метода из памяти по указателю на объект). Сортируешь массив по типу объектов — работает сильно быстрее. Для точности конечно нужно вначале кеши прогреть, ес-но.
Спор ни о чем, я указал их теор. возможности "предсказывателей", Вы показали их реальную эффективность.
Согласен. Но еще один немаловажный фактор, это то, что такого "сложного" кода все-таки меньше чем более-менее "простого" кода.
Мне почему-то так думается. Т.е. даже в одном приложении, скажем ядро, действительно может быть сложное в любом плане --
архитектурном, алгоритмическом и т.п, но не мало и обычного простого кода, которого всегда больше.
Здравствуйте, Cyberax, Вы писали:
C>А ты подумай, КАК ты выводишь данные на принтер? C>В x86 это сводится, в итоге, к копированию данных в нужный участок памяти (на который отображаются нужные регистры устройств). C>Так что всё ОК — устройство "увидит" данные ровно тогда, когда будет закоммичена транзакция. На практике, с текущей реализацией транзакция вообще сразу же откатится, как только заденет некэшируемую память.
Понял, спасибо. Да, действительно.
Но как же быть, если от вывода зависит, например, ввод в той же транзакции? Скажем, сперва что-то выводим на экран, а потом ждем реакции юзера — все в одной транзакции. Получается, такой сценарий работать не будет.
Выходит, некие ограничения с ИО все же присутствуют. Насколько можно их формализовать — непонятно.
U>И он прав. Разговоры про большое значение multi core и парралелизм были ещё в 2005 году на моей памяти. Саттеровские "free lunch is over" and shit предсказывали, что через 10 лет мы все будем сидеть толстой задницей на 256 корах. Нифига этого не случилось.
А кто виноват? Да вот те же Линус сотоварищи, винда и прочие МакОСи. Даже если тот же Линукс будет сидеть на 256 ядрах, это ничего никому не даст. Весь инструментарий, все библиотеки, все языки программирования, весь GUI как был, так и остается однопоточными. А те из языков, что не однопоточные, имеют прекрасные GIL или мьютексы, что тоже хорошему параллельному коду не способствуют.
Что выливается в то, что никто не умеет и не собирается писать что-либо хоть мало-мальски параллельное и распределяемое.
U>А софтверный параллелизм к сожалению себя ещё нигде не проявил.
Тут выше уже написали. Он прекрасно себя проявляет. Но в большинстве случаев этот параллелизм должен продираться через тонны преград, насаждаемых ОСями, — вплоть до реализации своих потоков, кэшей и прочая и прочая.
Здравствуйте, AlexRK, Вы писали:
ARK>Но как же быть, если от вывода зависит, например, ввод в той же транзакции? Скажем, сперва что-то выводим на экран, а потом ждем реакции юзера — все в одной транзакции. Получается, такой сценарий работать не будет.
Зачем всё усложнять? Выводятся данные обычным MOV в коде драйвера в шинные адреса, отмапенные в виртуальные адреса
адресного пространства ядра. Ввод чтением оттуда же под аккординги прерываний.
ARK>Выходит, некие ограничения с ИО все же присутствуют. Насколько можно их формализовать — непонятно.
А это уже нужно реализовать в связке юзерспасовый демон плюс драйвер. В драйвере должен быть расширенный набор
режимов работы с устройством, предоставляя наружу некоторый интерфейс, для переключения между режимами
из юзерспайсовых демонов, например, через ioctl каллбек в Unix-ах. Юзерспайсовый демон будет управлять
режимами общения с устройством, и в демоне же будет реализовываться некоторая логика работы с устройством,
воплощающая транзакционную модель управления им. На уровне же самого ввода/вывода будут упомянутые простейшие
операции MOVQ %%RAX, (%%RBX)
Здравствуйте, smeeld, Вы писали:
ARK>>Но как же быть, если от вывода зависит, например, ввод в той же транзакции? Скажем, сперва что-то выводим на экран, а потом ждем реакции юзера — все в одной транзакции. Получается, такой сценарий работать не будет. S>Зачем всё усложнять? Выводятся данные обычным MOV в коде драйвера в шинные адреса, отмапенные в виртуальные адреса S>адресного пространства ядра. Ввод чтением оттуда же под аккординги прерываний.
Когда данные выводятся таким образом, произойдут ли необратимые побочные эффекты (печать на экране, принтере)?
S>А это уже нужно реализовать в связке юзерспасовый демон плюс драйвер. В драйвере должен быть расширенный набор S>режимов работы с устройством, предоставляя наружу некоторый интерфейс, для переключения между режимами S>из юзерспайсовых демонов, например, через ioctl каллбек в Unix-ах. Юзерспайсовый демон будет управлять S>режимами общения с устройством, и в демоне же будет реализовываться некоторая логика работы с устройством, S>воплощающая транзакционную модель управления им. На уровне же самого ввода/вывода будут упомянутые простейшие S>операции MOVQ %%RAX, (%%RBX)
Как это поможет конечному программисту? Откуда он узнает, что в некотором месте программы откат возможен, а в другом — нет (т.к. где-то в середине функции стоит вызов другой функции, в глубине которого находится неоткатываемая операция)? Опять будет все в лучших традициях ненадежного программирования — "головой нужно думать", "криворуким тут не место" и т.п.? Лично мне интересен формальный контроль (компилятором).
Здравствуйте, AlexRK, Вы писали:
ARK>Как это поможет конечному программисту? Откуда он узнает, что в некотором месте программы откат возможен, а в другом — нет (т.к. где-то в середине функции стоит вызов другой функции, в глубине которого находится неоткатываемая операция)? Опять будет все в лучших традициях ненадежного программирования — "головой нужно думать", "криворуким тут не место" и т.п.? Лично мне интересен формальный контроль (компилятором).
Вам не кажется, что слишком многого хотите от компилятора? Организация логики исполнения и контроль
соответствия ей во время исполнения-это прямая обязанность программиста, а не компилтора. На уровне CPU
есть только набор инструкций, и компилятор занимается только тем, что переводит текст проги в последовательность
этих инструкций. Ваше же требование заключается в том, чтоб компилятор, не много ни мало, придумывал логику исполнения.
PS и да "головой нужно думать", "криворуким тут не место". А как вы хотели? Когда появятся компиляторы, которые снимут
такое требование для прогеров-это будет уже, не много и ни мало, Artificial Intelligence.
Здравствуйте, smeeld, Вы писали:
S>Вам не кажется, что слишком многого хотите от компилятора? Организация логики исполнения и контроль S>соответствия ей во время исполнения-это прямая обязанность программиста, а не компилтора. На уровне CPU S>есть только набор инструкций, и компилятор занимается только тем, что переводит текст проги в последовательность S>этих инструкций. Ваше же требование заключается в том, чтоб компилятор, не много ни мало, придумывал логику исполнения.
Нет, требование совершенно не в том, чтобы компилятор придумывал логику исполнения.
И компилятор обычно занимается не только переводом кода из одного представления в другое. Он еще и запрещает реализацию логики исполнения, неправильной в каком-то смысле. Например, контроль типов — если передаваемый тип данных не соответствует требуемому, компилятор выдает ошибку.
Мое (гипотетическое) требование в том, чтобы компилятор запрещал компиляцию кода, содержащего неоткатываемые участки в границах некоторой транзакции. Из этого требования вытекает необходимость формализации терминов "транзакция", "откатываемый код", "неоткатываемый код" и т.п.
Вот видите, а вы говорите — все просто. MOV сделал и вуаля.
Здравствуйте, AlexRK, Вы писали:
ARK> Он еще и запрещает реализацию логики исполнения, неправильной в каком-то смысле. Например, контроль типов — если передаваемый тип данных не соответствует требуемому, компилятор выдает ошибку.
Это не контроль корректности логики исполнения, а контроль соответсвия стандарту ЯП. Две вообще разные сущности.
ARK>Мое (гипотетическое) требование в том, чтобы компилятор запрещал компиляцию кода, содержащего неоткатываемые участки в границах некоторой транзакции. Из этого требования вытекает необходимость формализации терминов "транзакция", "откатываемый код", "неоткатываемый код" и т.п.
Это нужно добавлять специальное подмножество в ЯП. Приблизительно то же саоме, что и параллелизация с OpenMP,
директивами # pragma omp... Что то вроде-#pragma transaction..... что будет заставлять компилятор генерить некоторый
шаблонную схему обмена данными, соответсвующей логике транзакций.
ARK>Вот видите, а вы говорите — все просто. MOV сделал и вуаля.
Прочитайте лучше, чо писал выше, MOV есть сама перекидка данных в/из устройства, этой операции должно будет
предшествовать множество иных операций в рамках процесса определения необходимости/возможности совершения
операции MOV, и являющееся частью реализации логики транзакционной модели взаимодействия с устройстовом.
Здравствуйте, AlexRK, Вы писали:
ARK>Но как же быть, если от вывода зависит, например, ввод в той же транзакции? Скажем, сперва что-то выводим на экран, а потом ждем реакции юзера — все в одной транзакции. Получается, такой сценарий работать не будет.
Ввод или форсирование записи (в виде барьерной инструкции) в данный момент тоже будет вызывать откат транзакции.
Ну и общая идея в том, чтобы транзакции таки не были слишком длинными.
ARK>Выходит, некие ограничения с ИО все же присутствуют. Насколько можно их формализовать — непонятно.
Не надо ничего делать — всё уже сделано. Даже сейчас для гарантированного инициирования IO нужно поставить инструкцию mfence, чтобы гарантировать правильный глобальный порядок записи. В случае с транзакциями инструкции mfence вызывают откат.
Здравствуйте, Mamut, Вы писали:
M>А кто виноват? Да вот те же Линус сотоварищи, винда и прочие МакОСи. Даже если тот же Линукс будет сидеть на 256 ядрах, это ничего никому не даст. Весь инструментарий, все библиотеки, все языки программирования, весь GUI как был, так и остается однопоточными. А те из языков, что не однопоточные, имеют прекрасные GIL или мьютексы, что тоже хорошему параллельному коду не способствуют.
Не надо вот так нормальные среды пинать. Zing JVM спокойно работает на тысяче процессоров и их GC масштабируется без проблем и на бóльшие объёмы. Естественно, полностью параллельно и конкурентно.
Здравствуйте, smeeld, Вы писали:
S>Это не контроль корректности логики исполнения, а контроль соответсвия стандарту ЯП. Две вообще разные сущности.
Это то же самое, но с другой точки зрения. В любом случае первичен контроль логики исполнения.
Мало того, существуют компиляторы, которые производят кучу дополнительных проверок, помимо "стандарта языка".
S>Это нужно добавлять специальное подмножество в ЯП. Приблизительно то же саоме, что и параллелизация с OpenMP, S>директивами # pragma omp... Что то вроде-#pragma transaction..... что будет заставлять компилятор генерить некоторый S>шаблонную схему обмена данными, соответсвующей логике транзакций.
Да, я как раз об этом и говорил ранее, когда начался разговор о границах транзакций.
Здравствуйте, AlexRK, Вы писали:
ARK>Это то же самое, но с другой точки зрения. В любом случае первичен контроль логики исполнения. ARK>Мало того, существуют компиляторы, которые производят кучу дополнительных проверок, помимо "стандарта языка".
Повторюсь, что у компилятора нет никаких способов контролировать логику исполнения определяемую алгоритмом.
Он следит только за ЯП, плюс дополнительные проверки, связанные с безопасностью или производительностью в форме
контроля за набором параметров, множество которых расписано разрабами компилятора. Это сущности,
связанные с свойствами генерации кода и его исполнения, и не имеющие никакого отношения к алгоритмам,
которые реализует конечный код. Логика исполнения же-это сущность относящаяся к алгоритмам. Последнее полностью
в зоне ответственности прикладного прогера, и не получится внедрить в компилятор механизмы проверки корректности
любого возможного алгоритма, который только может придумать прикладной прогер, это, повторюсь, будет уже Artificial Intelligence.
Контроль может быть только на уровне контроля за корректностью проведения некоторых операций в данном участке кода, в составе
реализации алгоритма, при явном задании для компилятора необходимости проводить такую проверку. Но это уже явно категория
специализированных конструкций ЯП, типа #pragma ...
C>Не надо вот так нормальные среды пинать. Zing JVM спокойно работает на тысяче процессоров и их GC масштабируется без проблем и на бóльшие объёмы. Естественно, полностью параллельно и конкурентно.
C>Так что можно, если немножко захотеть.
Zing is priced on a subscription basis per server. With per-server pricing, you don’t need to worry about core counts, memory size, or number of instances deployed per server. The annualized subscription price for Zing per physical server ranges from $3500 (for several hundred servers) to $7500.
Дешевле Erlang тогда взять.
Ну из-за того, что есть один Zing JVM и одна Erlang VM, общая суть не меняется.
Здравствуйте, smeeld, Вы писали:
S>Повторюсь, что у компилятора нет никаких способов контролировать логику исполнения определяемую алгоритмом.
Это не так.
http://en.wikipedia.org/wiki/Program_analysis http://en.wikipedia.org/wiki/Correctness_%28computer_science%29
S>Он следит только за ЯП, плюс дополнительные проверки, связанные с безопасностью или производительностью в форме S>контроля за набором параметров, множество которых расписано разрабами компилятора. Это сущности, S>связанные с свойствами генерации кода и его исполнения, и не имеющие никакого отношения к алгоритмам, S>которые реализует конечный код. Логика исполнения же-это сущность относящаяся к алгоритмам. Последнее полностью S>в зоне ответственности прикладного прогера, и не получится внедрить в компилятор механизмы проверки корректности S>любого возможного алгоритма, который только может придумать прикладной прогер, это, повторюсь, будет уже Artificial Intelligence.
Контроль правильности использования контрактов каналов в Singularity — это контроль логики исполнения?
А как насчет Typestates?
Здравствуйте, smeeld, Вы писали:
S>А теперь ссылки на то, как эти бредни скинтистов воплощены в конкретных компиляторах, желательно, в S>GCC или LLVM, чтоб ссылки были на файлы с исходниками, а то в теориях, знаете ли, и что такое вселенная S>известно, в каждой по своему, а в CS так вообще насочиняли бреда, которое к реальному железу отношения не S>имеет, а для воплощения в программной реализации оно слишком отдалено от конретных задач, для каждой из который S>правильней будет придумывать схемы и алгоритмы для каждой задачи самостоятельно, (что и делатется всеми практикующими S>разработчиками) а не рыться в тоннах бреда, насочинённого скинтистами.
Demonstration of functional correctness
— Well-defined criteria
— Automated and/or model-based testing
— Formal techniques: model checking, theorem proving
Satisfaction of non-functional requirements
— No crashes due to runtime errors (division by zero, invalid pointer accesses, overflow and rounding errors)
— Resource usage
--- Timing requirements (e.g. WCET, WCRT)
--- Memory requirements (e.g. no stack overflow)
На сайте есть примеры реальных проектов (авиационное ПО).
S>Не нужно википедий, там сочиняют все кому не лень, приведите ссылки на спеки существующих интерфейсов периферийных S>устройств, CPU, в которых были бы прописаны реализованные механизмы контроля логики исполнения транзакционной модели S>на их уровне, а не на уровне алгоритма прикладной программы.
Я не знаю, есть ли что-то подобное для контроля логики транзакций. Именно поэтому я и спросил в начале разговора про сценарий с IO.
Как я понял из ответов, того, о чем я спрашивал, нет.
Интерфейсы периферийных устройств меня не интересуют, меня интересует корректное программирование.
Здравствуйте, AlexRK, Вы писали:
ARK>Ну вот пример реализации того, что вы называете "бреднями скинтистов" (с) ARK>http://www.astree.ens.fr/
Мне не нужны буклеты презентаций, мне нужны исходники, потому что всё вот это
Programm_analysis, Correctness(computer science) etc.
и прочее подобное, красиво звучащее и описываемое в теоретических сочинениях, в конкретных реализация, насколько знаю по просмотрам,
исходников GCC и LLVM, сводится к упомянутому
проверки, связанные с безопасностью или производительностью в форме контроля за набором параметров,
множество которых расписано разрабами компилятора.
Контроль может быть только на уровне контроля за корректностью проведения некоторых операций в данном участке кода, в составе
реализации алгоритма, при явном задании для компилятора необходимости проводить такую проверку.
Прикол в том, что строгой математической теоретической базы под Programm_analysis, Correctness(computer science) etc.
не существует, они представляю собой пространные рассуждения, коих насочинять можно сколько угодно. И в конкретных реализациях
всё сводится к самым что ни на есть
проверки и соответствия, связанные с безопасностью или производительностью в форме контроля за набором параметров, взаимосвязаных (графы или какие иерархические построения)или нет, множество которых расписано разрабами компилятора.
Здравствуйте, smeeld, Вы писали:
S>Мне не нужны буклеты презентаций, мне нужны исходники, потому что всё вот это
Ну, исходники доступны не для всего. Где исходники Windows 7, Oracle DBMS? Это не значит, что их не существует.
Вот есть опенсорсный анализатор, можете глянуть, если интересно: http://frama-c.com/download.html
Но там все на ML. И мне неизвестно, выполнялись ли на нем какие-то реальные проекты.
Вот еще индустриальный компилятор с исходниками: http://libre.adacore.com/download/
Надо мыло вводить, я сам не пробовал.
S>и прочее подобное, красиво звучащее и описываемое в теоретических сочинениях, в конкретных реализация, насколько знаю по просмотрам, S>исходников GCC и LLVM, сводится к упомянутому
GCC и LLVM, насколько мне известно, обладают весьма скудными возможностями статического анализа.
SPARK, ссылку на который я выше привел, анализирует гораздо больше. Но там язык Ada, а не C/C++.
А вообще все это уже очень далеко от параллелизма. Я, в принципе, получил ответ на свой изначальный вопрос. Будем ждать дальше, пока не появится что-то более вменяемое, чем существующие механизмы работы с транзакциями (на высоком уровне).
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 корах. Нифига этого не случилось. А что случилось? Как раз таки что Линус говорит:
дедуля просто не в курсе как это заставить работать.
у нас, например, на работе десктопы испольются по своему правильному назаначению — как терминалы доступы к "нормальным машинам"
Здравствуйте, Mamut, Вы писали:
M>Дешевле Erlang тогда взять. M>Ну из-за того, что есть один Zing JVM и одна Erlang VM, общая суть не меняется.
Меняется. Мы видим, что такая масштабируемость вполне доступна. Причём её делают легкодоступной вполне себе прикладным программистам.
M>>Дешевле Erlang тогда взять. M>>Ну из-за того, что есть один Zing JVM и одна Erlang VM, общая суть не меняется. C>Меняется. Мы видим, что такая масштабируемость вполне доступна. Причём её делают легкодоступной вполне себе прикладным программистам.
Слишком медленно Отсюда и разочарование у некоторых Ну а для того, чтобы ОСи к этому подтянулись — ууу...
Здравствуйте, __kot2, Вы писали:
__>дедуля просто не в курсе как это заставить работать. __>у нас, например, на работе десктопы испольются по своему правильному назаначению — как терминалы доступы к "нормальным машинам"
А до внучеков не доходит, что дедуле и его свите по барабану десктопы, и всегда так было, что дедуля всегда развивал
масштабную движуху в среде разрабов в направлении развития Linux для того, чтоб вывести Linux, по показателям,
в ОС номер один для запуска прежде всего этих самых "нормальных машин". То, что "родные Unix" и прочие z/OS были потеснены
Linux-ом на этом фронте, известно, и дедуля желает вообще вышвырнуть родные благородные ОСя c "нормальных машин" и утвердить
на них Linux целиком и полностью, как это уже сделано на "почти нормальных машинах" aka midrange servers.
ЗЫ Внучеки, такие внучеки, думают что их песочница с песчаными пирамидками-вершина hi-tech-а, а, летающие вокруг на сверхзвуке ракеты,
так, отживающие кряхтения старых глупых дедуль.
Здравствуйте, smeeld, Вы писали: S>ЗЫ Внучеки, такие внучеки, думают что их песочница с песчаными пирамидками-вершина hi-tech-а, а, летающие вокруг на сверхзвуке ракеты, S>так, отживающие кряхтения старых глупых дедуль.
я ниче не понял если честно
мне вообще глубоко по барабану какая операционка стоит. у них у всех есть недостатки.
летания на ракете это про сайтики, чтоли? конечно, там все в io упирается. там вообще процессор не нужен
Здравствуйте, __kot2, Вы писали:
__>мне вообще глубоко по барабану какая операционка стоит. у них у всех есть недостатки. __>летания на ракете это про сайтики, чтоли? конечно, там все в io упирается. там вообще процессор не нужен
И ещё все внучеки как один уверены что Linux нигде кроме веб серваков не используется.
Для примера напомню, что БАК (тот, который коллайдер) на Linux целиком и полностью.
И про top500 промолчу, ибо уже аскомина, но внучеки то, похоже, и не знают.
Здравствуйте, smeeld, Вы писали: S>И ещё все внучеки как один уверены что Linux нигде кроме веб серваков не используется. S>Для примера напомню, что БАК (тот, который коллайдер) на Linux целиком и полностью. S>И про top500 промолчу, ибо уже аскомина, но внучеки то, похоже, и не знают.
а я и не про Линукс, я про то, где все упирается в размер кэша и io. просто хранение-пересылка данных.
Здравствуйте, Andrew.W Worobow, Вы писали:
AWW>Он прав — паралельное программирование в тупике это сейчас типа даже все уже очевидно. Лет пять назад я вот лично гворил, такое ( после 5 лет до этого находясь в плотной разработке паралельных программ) мне говорили, что я типа что-то не то говорю.
За это плюс не поставил, не вполне согласен. Но тут уже без меня достаточно сказали. Если коротко — где в тупике, а где и нет. Обширное это понятие — параллельное исполнение кода.
AWW>Проблема в паралельном программировании лежит в нескольких плоскостях AWW>1) Нет достаточно умных людей (в достаточном количестве) которые бы могли делать архитектуру для того чтобы паралельное программирование работало. AWW>2) Тренд за последнее время в разработке средств разработки шел в сторону упрошения этого процессе — ну типа чтобы "не гении могли делать код". AWW>3) Даже сейчас мало кто понимает, что даже если распаралелить цикл, на 10 ядер, это не даст прироста в скорости решения задачи. AWW>Тут либо настанет опять такое время когда в стоимости программиста будет первостепенную роль играть ум, а не знание библиотек и умение быстро разрабатывать.
А вот за это +100. Мне с самого начала показалось подозрительным, когда появились всякие пакеты/фреймворки, в которых "легким движением руки превращаются" последовательные алгоритмы в параллельные. Скажи волшебное слово AsParralel — и готово. Не получится так. Тут думать надо. И хорошо думать.
!). Научные расчеты, там тоже все неплохо параллелится. Кодеки фильмов, архиваторы — тоже параллелятся неплохо. В формоклепательстве да, от параллелизма смысла мало. В клепании бизнес логики тоже выгоды мало будет. Но мощи даже бюджетных процессоров уже давно более чем достаточно для офисных приложений, браузера и т.д.
