gribozavr

oeis.org/

Но в общем случае задача «выяснить закономерность» лишена смысла, так как под любую последовательность можно подогнать много различных «закономерностей», которые дают совершенно различные продолжения.

rsnapshot

Если хотите заниматься фигурным выпиливанием по байтам:

1. Подумайте, может оно того не стоит?

2. docs.oracle.com/javase/7/docs/api/java/nio/ByteBuffer.html Но учтите что невыровненные чтения/записи на не-x86 бывают дорогие.

У вас где-то в другом месте проблема, а это не решение, а просто уход от неё.

Портабельного аналога в стандарте нет. А Clang понимает __attribute__((noinline)).

Но если у вас там действительно всякие нестандартные атомики, то:

1. используйте стандартные атомики;

2. используйте ordered атомики;

3. используйте барьеры (или для процессора, или только для компилятора asm volatile("":::"memory"););

4. выясните, почему компилятор себе позволяет делать reordering вокруг ваших ассемблерных вставок или интринсиков. Баг компилятора?

А то потом придёт какой-нибудь link-time optimization и снова всё вам сломает.

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

isocpp.org/tour
isocpp.org/get-started

A Tour of C++ by Bjarne Stroustrup

isocpp.org/tour

На это лето вы почти наверняка уже опоздали. Процесс оформления документов обычно длительный, а все позиции разбирают где-то к январю.

Кстати, крупные компании, которые вы назвали, очень и очень хороши для стажировок. Подумайте: ехать в ноунейм организацию «мыть пробирки» — это не то, как вы хотите потратить лето.

www.phdcomics.com/comics/archive.php?comicid=508

apg

OpenFOAM

Возьмите один из готовых генераторов и не изобретайте велосипед. При реализации ГПСЧ можно очень легко наделать ошибок, которые на первый взгляд не заметны.

Возьмите, например, из [1] реализацию mt19937 и забудьте.

[1] llvm.org/viewvc/llvm-project/libcxx/trunk/include/random?view=markup

iotop

Можно. Пусть просто поговорят друг с другом и решат кто что делает.

Не нужно решать административные проблемы техническими мерами. Если у вас в проекте кому-то из разработчиков для номральной повседневной работы нужно блокировать целый *модуль*, то у вас что-то не так или с разработчиками, или с процессом, или с организацией дерева исходного кода.

Можно автоматизировать процесс только для очень общих и часто повторяющихся вещей, но у каждой конкретной ISA всегда свои заморочки. Вот посмотрите в LLVM: довольно большая часть ассемблеров/дизассемблеров генерируется автоматически, но всё равно рядом всегда есть код на C++ для обоработки команд, не попадающих под стандартные случаи.

И да, «генерируется автоматически» — из описания на специальном языке, которое для большой ISA тоже будет большое.

Так что чуда не будет.

llvm.org/viewvc/llvm-project/llvm/trunk/lib/Target/ARM/ARMInstrInfo.td?revision=168886&view=markup

Вот например (часть) описания команд ARM. Всего-то 200 Кб, и это на специально созданном для этого языке.

Просто используйте uniform initialization в C++11. Сегодня нет причин не использовать C++11.

Запустите ldd ./arm-none-linux-gnueabi-gcc и посмотрите, есть ли у вас все необходимые библиотеки.

Внутри одного процесса вся память всегда общая.

Не стоит путать олимпиадное и промышленное программирование. Разве что у вас наукоёмкие задачи для которых нужно постоянно изобретать принципиально новые алгоритмы.

bs=4M, так быстрее в несколько раз.