Относительно того что по ссылке. Или я, или автор не совсем понимает проблемы. Если b — dword. То компилятор его автоматически преобразует в qword в данном случае. gcc, по крайней, мере так делает.

Это ничего не значит. Мы можем найти такие случаи, когда это можно сделать. А для компилятора все равно какие абстракции представляет C++ — он работает уровнем ниже.

А еще Вы не упомянули о вот такой вот вещи en.wikipedia.org/wiki/Simultaneous_multithreading

А как же sunburst?

Интересно, почему на макбуке с глянцевым экраном я вижу отличия?

По поводу рекурсии. Оптимизировать хвостовую рекурсию предельно просто и эта оптимизация реализована, наверное, везде. Как-раз факториал будет иметь вид хвостовой рекурсии.

Вы пишете, что алгоритм фибоначчи является итеративным(это как?), хотя само определение алгоритма рекурсивно. Другое дело, что «не рекурсивный» алгоритм вычисления чисел фибоначчи относится к классу методов динамического программирования.

Насколько я знаю сетевой фильтр — это, простая схема(состоящая с конденсатора, индуктивности, чего то еще) фильтрующая шумы и высокое напряжение итд. Так вот, если этот фильтр ставить непосредственно перед трансформатором в самом усилителе, мне кажется это позволит избежать дорогих проводов. У меня есть подозрение, что производители так и делают.

И еще. Что будет если подключить через такой кабель обычный компьютер, повлияет ли это на производительность?

Очень интересно узнать объяснение, каким образом сетевой кабель может влиять на звучание, если он все же подключается к обычной проводке?

Мне кажется, что одним из огромнейших недостатков DFS является то что протокол namenode реализован через сильноспецифический java RPC, поэтому все клиентские реализиции работают через Java-биндинг

А ведь пользователей использовали против их воли. Это же бот-нет получается.

Если есть желание, мешать ничего не будет.

Вот интересно, сейчас паралельность в пределах программы достигаеться, фактически, только использованием потоков. А нельзя было бы использовать подход, на уровне разпаралеливания блоков инструкций. Например

for(i=0; i!=N; i++) {
...
}

Если :-) известно, что i не зависит от i-1. Генерировать, не как делают нынешние компиляторы, одну последовательность инструкций, а максимально возможное количество "паральных" блоков инструкций. А при загрузке программы составлять схему, что делать паралельно, а что нет, причем хитро указывать процессорам на отдельные блоки инструкций.

OpenMP, вроде как, всеравно все в потоки превращает.