Здравствуйте, 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). Если такая транзакция перепишет слишком много памяти то произойдет тоже самое.

ARK>Ну ясно. Короче, будет задница. Впрочем, чудес не бывает, это очевидно.

Никакой задницы, транзакции не выходят за пределы L1 кеша см. выше. Это все уже сейчас юзается, уже есть поддержка со стороны Intel TBB и других библиотек. В принципе, можно без последствий заменить все мьютексы в программе на мьютексы использующие 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 а можно даже использовать возможности спекулятивного исполнения и предсказания ветвлений для оптимизации загруок из памяти, но для этого, опять же, следует понимать что может быть предсказано а что нет.

Здравствуйте, uncommon, Вы писали:

Он прав — паралельное программирование в тупике это сейчас типа даже все уже очевидно. Лет пять назад я вот лично гворил, такое ( после 5 лет до этого находясь в плотной разработке паралельных программ) мне говорили, что я типа что-то не то говорю.

Проблема в паралельном программировании лежит в нескольких плоскостях
1) Нет достаточно умных людей (в достаточном количестве) которые бы могли делать архитектуру для того чтобы паралельное программирование работало.
2) Тренд за последнее время в разработке средств разработки шел в сторону упрошения этого процессе — ну типа чтобы "не гении могли делать код".
3) Даже сейчас мало кто понимает, что даже если распаралелить цикл, на 10 ядер, это не даст прироста в скорости решения задачи.

Тут либо настанет опять такое время когда в стоимости программиста будет первостепенную роль играть ум, а не знание библиотек и умение быстро разрабатывать.

Такое время было от 70-ых годов до появления персоналок.

Распаралеливать надо не код, а задачу.

Здравствуйте, uncommon, Вы писали:

U>И он прав. Разговоры про большое значение multi core и парралелизм были ещё в 2005 году на моей памяти. Саттеровские "free lunch is over" and shit предсказывали, что через 10 лет мы все будем сидеть толстой задницей на 256 корах. Нифига этого не случилось. А что случилось? Как раз таки что Линус говорит:
Смотря где не случилось. В видеокартах, например, параллелизм охрененный. И если посмотреть на картинку современной игрушки — хренеешь от прогресса. При этом даже на технике 10 летней давности, но с параллелизмом, картинка выдается просто охрененная (пример — PS3 и игрушка The last of us). В серверах тоже параллелизм охрененный, и все ядра прекрасно задействуются (гугл же не тормозит !). Научные расчеты, там тоже все неплохо параллелится. Кодеки фильмов, архиваторы — тоже параллелятся неплохо. В формоклепательстве да, от параллелизма смысла мало. В клепании бизнес логики тоже выгоды мало будет. Но мощи даже бюджетных процессоров уже давно более чем достаточно для офисных приложений, браузера и т.д.
И параллелизм не исчерпывается процессорными ядрами. Всякие датацентры — там тоже параллелизм черти как. RAID — тоже параллелизм. SIMD инструкции — тоже параллелизм. На уровне просто выполнения процессорных команд — тоже давно идет параллелизм. И это совсем не ново, если что. Параллелизм активно юзался и 20 лет назад, и 30 в суперкомпьютерах. Он относительно нов только в бытовых ПК.
Соответственно параллелизм есть, он охрененный, но он локализован внутри библиотек, движков и т.д. А в обычный быдлокод и формоклепательства я не уверен что он вообще когда либо придет.

Здравствуйте, 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.