То есть любое взаимодействие с волатайл это андефайнд бех?

ну зависит от архитектуры

на x86 байт и меньше атомарны вроде

volatile int a = 3; std::cout « (a+a) « std::endl; Не могу понять, почему это UB? Какое рациональное обьяснение?

Нет тут UB никакого...

гонки по данным — UB, volatile тут ни при чём

ну да, может задающий вопрос и не это имеет ввиду

Разумеется, в этом смысл ключевого слова волатайл

Нет, смысл volatile не в этом

Волатиль это ж анти кеш?

нет

Анти кеш из регистра я думал. Хм

То есть любое взаимодействие с волатайл это андефайнд бех?

С какого перепуга? Нет там никакого UB.

С какого перепуга? Нет там никакого UB.

Даже гонки нет?

С какого перепуга? Нет там никакого UB.

Проверяй информацию

volatile object - an object whose type is volatile-qualified, or a subobject of a volatile object, or a mutable subobject of a const-volatile object. Every access (read or write operation, member function call, etc.) made through a glvalue expression of volatile-qualified type is treated as a visible side-effect for the purposes of optimization (that is, within a single thread of execution, volatile accesses cannot be optimized out or reordered with another visible side effect that is sequenced-before or sequenced-after the volatile access. This makes volatile objects suitable for communication with a signal handler, but not with another thread of execution, see std::memory_order). Any attempt to refer to a volatile object through a non-volatile glvalue(e.g. through a reference or pointer to non-volatile type) results in undefined behavior.

Даже гонки нет?

Для гонок нужно как минимум два потока

Нашел все таки

Неопределенное поведение

Except where noted, evaluations of operands of individual operators and of subexpressions of individual expressions are unsequenced. [ Note: In an expression that is evaluated more than once during the execution of a program, unsequenced and indeterminately sequenced evaluations of its subexpressions need not be performed consistently in different evaluations. — end note ] The value computations of the operands of an operator are sequenced before the value computation of the result of the operator. If a side effect on a scalar object is unsequenced relative to either another side effect on the same scalar object or a value computation using the value of the same scalar object, the behavior is undefined. [ Example: void f(int, int); void g(int i, int* v) { i = v[i++]; // the behavior is undefined i = 7, i++, i++; // i becomes 9 i = i++ + 1; // the behavior is undefined i = i + 1; // the value of i is incremented f(i = -1, i = -1); // the behavior is undefined } — end example ] When calling a function (whether or not the function is inline), every value computation and side effect associated with any argument expression, or with the postfix expression designating the called function, is sequenced before execution of every expression or statement in the body of the called function. [ Note: Value computations and side effects associated with different argument expressions are unsequenced. — end note ] Every evaluation in the calling function (including other function calls) that is not otherwise specifically sequenced before or after the execution of the body of the called function is indeterminately sequenced with respect to the execution of the called function.9 Several contexts in C++ cause evaluation of a function call, even though no corresponding function call syntax appears in the translation unit. [ Example: Evaluation of a new expression invokes one or more allocation and constructor functions; see [expr.new]. For another example, invocation of a conversion function ([class.conv.fct]) can arise in contexts in which no function call syntax appears. — end example ] The sequencing constraints on the execution of the called function (as described above) are features of the function calls as evaluated, whatever the syntax of the expression that calls the function might be.

Но как-то это все равно непонятно

Но как-то это все равно непонятно

Ты не то нашел, я выше тебе кинул с сппреференса

Ты не то нашел, я выше тебе кинул с сппреференса

Все, вижу

Вопрос то непростой оказался...

volatile object - an object whose type is volatile-qualified, or a subobject of a volatile object, or a mutable subobject of a const-volatile object. Every access (read or write operation, member function call, etc.) made through a glvalue expression of volatile-qualified type is treated as a visible side-effect for the purposes of optimization (that is, within a single thread of execution, volatile accesses cannot be optimized out or reordered with another visible side effect that is sequenced-before or sequenced-after the volatile access. This makes volatile objects suitable for communication with a signal handler, but not with another thread of execution, see std::memory_order). Any attempt to refer to a volatile object through a non-volatile glvalue(e.g. through a reference or pointer to non-volatile type) results in undefined behavior.

Так не было у него там доступа к volatile через не volatile glvalue.

Нет тут UB никакого...

Ильюха, ну хоть в стандарт загляни

Так не было у него там доступа к volatile через не volatile glvalue.

А a+a? Где здесь glvalue?

видимо речь о том, что порядок чтений в (a + a) не определен, но это не UB в смысле стандарта

Как выяснилось выше - ub

Как выяснилось выше - ub

ох ты ж

А a+a? Где здесь glvalue?

нет glvalue — нет non-volatile glvalue!

что-то я совсем запутался, где в a+a non-volatile glvalue?

что-то я совсем запутался, где в a+a non-volatile glvalue?

Вот именно.

что-то я совсем запутался, где в a+a non-volatile glvalue?

там sequence нет

Доброго времени суток! Возник такой вопрос: есть 2 консольных приложения, оба запускаются через пайплайн (т.е. вывод (stdout) одного является входом (stdin) для другого процесса). Приложение которое генерит данные многопоточное, в каждом потоке производятся вычисления и готовится символьный буфер, далее происходит блокировка (spin_lock, чтобы избежать перехода в режим ядра) и весь буфер сбрасывается в stdout (чтобы уменьшить число системных вызовов). Профайлер показывает что больше всего времени уходит на запись буфера в stdout. Можно ли как-то ускорить вывод в stdout? Я пробовал: писать через cout.write(...) с sync_with_stdio(false), писать через fwrite/write, играться размером буфера, отключать буферизацию, все результаты отличаются максимум на 20-30% (если это как-то может помочь - то при перенаправлении в файл пропускная способность 200-230 Мб/с (походу край для моего hdd)). Может кто встречался/знает какие библиотеки/советы на эту тему?

ос?

Доброго времени суток! Возник такой вопрос: есть 2 консольных приложения, оба запускаются через пайплайн (т.е. вывод (stdout) одного является входом (stdin) для другого процесса). Приложение которое генерит данные многопоточное, в каждом потоке производятся вычисления и готовится символьный буфер, далее происходит блокировка (spin_lock, чтобы избежать перехода в режим ядра) и весь буфер сбрасывается в stdout (чтобы уменьшить число системных вызовов). Профайлер показывает что больше всего времени уходит на запись буфера в stdout. Можно ли как-то ускорить вывод в stdout? Я пробовал: писать через cout.write(...) с sync_with_stdio(false), писать через fwrite/write, играться размером буфера, отключать буферизацию, все результаты отличаются максимум на 20-30% (если это как-то может помочь - то при перенаправлении в файл пропускная способность 200-230 Мб/с (походу край для моего hdd)). Может кто встречался/знает какие библиотеки/советы на эту тему?

Профайлер показывает что больше всего времени уходит на запись буфера в stdout. -- так и должно быть, операции ввода-вывода самые долгие. Чтобы реально понять, что у тебя там тормозит, и тормозит ли, тебе надо ЗАБЛОКИРОВАТЬ (выключить) вывод в stdout на время прогона в профайлере.

Я полагаю товарищ хочет вывод быстрый

Доброго времени суток! Возник такой вопрос: есть 2 консольных приложения, оба запускаются через пайплайн (т.е. вывод (stdout) одного является входом (stdin) для другого процесса). Приложение которое генерит данные многопоточное, в каждом потоке производятся вычисления и готовится символьный буфер, далее происходит блокировка (spin_lock, чтобы избежать перехода в режим ядра) и весь буфер сбрасывается в stdout (чтобы уменьшить число системных вызовов). Профайлер показывает что больше всего времени уходит на запись буфера в stdout. Можно ли как-то ускорить вывод в stdout? Я пробовал: писать через cout.write(...) с sync_with_stdio(false), писать через fwrite/write, играться размером буфера, отключать буферизацию, все результаты отличаются максимум на 20-30% (если это как-то может помочь - то при перенаправлении в файл пропускная способность 200-230 Мб/с (походу край для моего hdd)). Может кто встречался/знает какие библиотеки/советы на эту тему?

В общем, цель-то у тебя какая ? Ускорить генерирующее приложение, или ускорить передачу данных между этой парой?

Я полагаю консольки достаточно медленные, как и пайпы

Я полагаю товарищ хочет вывод быстрый

Я полагаю, товарищу сказали, "НАДО УСКОРИТЬ", и он запустил профайлер, и решил, что тормозить IO. Но это нормально, IO ВСЕГДА ТОРМОЗИТ.

В общем, цель-то у тебя какая ? Ускорить генерирующее приложение, или ускорить передачу данных между этой парой?

Ускорить именно передачу, т.к. с генерацией все норм

https://www.reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes_so_fast/?st=j3v3iw3c&sh=5651ea3c

"spin_lock, чтобы избежать перехода в режим ядра" ... )

Ускорить именно передачу, т.к. с генерацией все норм

Что делает второе приложение?

"spin_lock, чтобы избежать перехода в режим ядра" ... )

Ну да, смешно, но фиг с ним...

Ускорить именно передачу, т.к. с генерацией все норм

а если сокеты

не очень понятна цель, какая нужна скорость?

Читает stdin и тоже производит счет, видно что оно простаивает пока ждет данные

Я полагаю консольки достаточно медленные, как и пайпы

+1, запист в пайп обычно медленее записи в файл

Ускорить именно передачу, т.к. с генерацией все норм

Ну надо просто от этой модели работы уходить, убирать пайп вообще. Либо два приложения свести в одно, это вообще идеально, либо уйти от ввода-вывода, передавать через shared memory например

Т.е. первое не успевает запитать данными второе

там наверно одно из ядер кипятится на этом спинлоке пока консоль ворочается

Читает stdin и тоже производит счет, видно что оно простаивает пока ждет данные

Что простаивает, это нормально

Что простаивает, это нормально

Это я понимаю)

Это я понимаю)

Ну просто убирай пайп на фиг.

линукс? сколько ядер?

От второго приложения нет исходников к сожалению из -за этого и пайпы

От второго приложения нет исходников к сожалению из -за этого и пайпы

Гы, ТОГДА СТРАДАЙ!

От второго приложения нет исходников к сожалению из -за этого и пайпы

Что ты тогда сделать можешь?

линукс? сколько ядер?

Windows пока, но linux в планах

Windows пока, но linux в планах

А на Линух то второе приложение само перекомпилируется?

может, там какая-то извесная программа

ERROR: S client not available

Windows пока, но linux в планах

а ты по сколько байт записываешь в пайп за раз?

а ты по сколько байт записываешь в пайп за раз?

Ну он же написал, что буфер накапливается и сбрасывается

без понятия, кто там ест стдин

если будешь больше 4096, то всё будет храниться в невыгружаемом пуле в ядре (т.е. в оперативке), что будет быстрее, чем в выгружаемом

Доброго времени суток! Возник такой вопрос: есть 2 консольных приложения, оба запускаются через пайплайн (т.е. вывод (stdout) одного является входом (stdin) для другого процесса). Приложение которое генерит данные многопоточное, в каждом потоке производятся вычисления и готовится символьный буфер, далее происходит блокировка (spin_lock, чтобы избежать перехода в режим ядра) и весь буфер сбрасывается в stdout (чтобы уменьшить число системных вызовов). Профайлер показывает что больше всего времени уходит на запись буфера в stdout. Можно ли как-то ускорить вывод в stdout? Я пробовал: писать через cout.write(...) с sync_with_stdio(false), писать через fwrite/write, играться размером буфера, отключать буферизацию, все результаты отличаются максимум на 20-30% (если это как-то может помочь - то при перенаправлении в файл пропускная способность 200-230 Мб/с (походу край для моего hdd)). Может кто встречался/знает какие библиотеки/советы на эту тему?

все результаты отличаются максимум на 20-30% (если это как-то может помочь - то при перенаправлении в файл пропускная способность 200-230 Мб/ вот так вот и будет, там больше не ускорить.

если будешь больше 4096, то всё будет храниться в невыгружаемом пуле в ядре (т.е. в оперативке), что будет быстрее, чем в выгружаемом

Пробовал 256, 1024, 4096, 65536, 1 Мб. Для 256, 1024, все не очень идет, с 65536 быстрее, 1 Мб самый быстрый но от 4096 отличается на 20%

так, а через пайп какая скорость-то? вдруг у него там 5 мб/с

Пробовал 256, 1024, 4096, 65536, 1 Мб. Для 256, 1024, все не очень идет, с 65536 быстрее, 1 Мб самый быстрый но от 4096 отличается на 20%

ты тут параллельно в консоль не смотришь, случаем?

все результаты отличаются максимум на 20-30% (если это как-то может помочь - то при перенаправлении в файл пропускная способность 200-230 Мб/ вот так вот и будет, там больше не ускорить.

В целом подозревал, просто я подумал - мало ли есть что-то что я упустил или о чем не знаю)

ты тут параллельно в консоль не смотришь, случаем?

Пардон, не понял - о чем вы?

Пробовал 256, 1024, 4096, 65536, 1 Мб. Для 256, 1024, все не очень идет, с 65536 быстрее, 1 Мб самый быстрый но от 4096 отличается на 20%

скорость ещё от версии Windows будет зависеть, 1 Мб быстрее 4096 т.к. каждый вызов записи в пайп - переключение в ядро с копированием туда данных. Соответственно лучше сразу больше в разумных пределах записать.

скорость ещё от версии Windows будет зависеть, 1 Мб быстрее 4096 т.к. каждый вызов записи в пайп - переключение в ядро с копированием туда данных. Соответственно лучше сразу больше в разумных пределах записать.

Вот, сегодня буду это пробовать - спасибо!

ещё можно с thread affinity поиграться

так, а через пайп какая скорость-то? вдруг у него там 5 мб/с

Через пайп не мерил, но точно быстрее.

ещё можно с thread affinity поиграться

Хм. Поднять приоритет для потока который пишет в stdout?

Через пайп не мерил, но точно быстрее.

странный подход, имхо, но то такое

Хм. Поднять приоритет для потока который пишет в stdout?

нет, на разные ядра шедулить

но мы до сих пор не знаем, какая ОС, сколько ядер и прочее

вдруг у тебя там дебажные версии, вообще

нет, на разные ядра шедулить

А ясно. Целевая ОС Windows 10 Enterprise процы Intel. Ядер по разному на разных машинах у разных заказчиков. Все версии release x64, статическая линковка (/MT)

А, еще вопрос на будущее: если ситуация будет обратная, т.е. приложение изготовитель будет слишком много данных генерить и приложение потребитель не будет успевать их прожевать, если ли вероятность что-то потерять? Если есть как программно понять какой максимальный размер буфера stdout/stdin?

А, еще вопрос на будущее: если ситуация будет обратная, т.е. приложение изготовитель будет слишком много данных генерить и приложение потребитель не будет успевать их прожевать, если ли вероятность что-то потерять? Если есть как программно понять какой максимальный размер буфера stdout/stdin?

https://en.cppreference.com/w/cpp/io/c/setvbuf

оно для стдоут сработает?

А почему нет?

Ребят а знает кто где найти как __builtin_launder работает в gcc? Я что-то никак не найду нигде

В плане что за хак он делает во время компиляции

ты про его реализацию в коде гцц, или зачем он нужен?

Что он делает на уровне компиляции