"...ученый Хазм, который стажировался на Биг Бизе и считался у тамошних экономистов гением-самородком (среди них он был известен под псевдонимом Адам-Смит Вессон Монтстрейтери). Хазм утверждал, что мир уже несколько столетий живет в Эре Насыщения — когда практически не меняются технологии и языки, человеческие и машинные, ибо исчерпан экономический и культурный смысл прогресса."
"Суперскалярность" эль-Burroughs - это некоторые "ld+op/st+op" (то, что в 8086 прямо в ISA) с разбиением стековых команд фронтэнда на смешанный микрокод. Это при том, что оно даже к концу 80-х было сырым.
Примеры костылей? Именно в x86_64. А то костылей, из которых ARM и состоит, можно привести массу. От странных размеров imm, не влезших в прокрустово ложе фиксированных кодировок команд до штук 5 попыток сделать вложенную виртуализацию. А уж забавные косяки RTL, которые принято патчить компилятором и костылями в ядре ОС - отдельная песТня.
Ключевое слово здесь. Во-первых, является ли эта задача CPU-bound или IO-bound? Более вероятно второе - смотрите количество потоков, порождаемых этой поделкой, и потребление памяти. Если потоков слишком много, то это оно (там IO так сделан), и надо подбирать бэкэнд среди нескольких полурабочих
POSIX AIO в glibc, помнится, был реализован на тредпуле - возможно, так и осталось. С Native AIO там были связаны относительно удобные векторные системные вызовы (что-то наподобие io_pwritev, io_preadv, на которых было достаточно удобно делать 0-copy DMA, но там была куча багов в обработке kiocb
Как же, как же. 90-e. Усилитель на 2-х лампах (6П14П и 6Ж1П, вроде), и к нему 1 каскад прямого усиления на 6К3П с диодным детектором - и все дела.
"...ученый Хазм, который стажировался на Биг Бизе и считался у тамошних экономистов гением-самородком (среди них он был известен под псевдонимом Адам-Смит Вессон Монтстрейтери). Хазм утверждал, что мир уже несколько столетий живет в Эре Насыщения — когда практически не меняются технологии и языки, человеческие и машинные, ибо исчерпан экономический и культурный смысл прогресса."
Нет ли в этом дискредитации?
"Суперскалярность" эль-Burroughs - это некоторые "ld+op/st+op" (то, что в 8086 прямо в ISA) с разбиением стековых команд фронтэнда на смешанный микрокод. Это при том, что оно даже к концу 80-х было сырым.
30 лет сплошных побед. Уже 1.5% рыночная доля. Каких-то 1500 лет - и дойдет до 100%. Такъ победимъ!
Можно одним предложением было обойтись: "Винда - плоха и ваще маздай, а линупс - крута, он на манявиртуалках стоит! Маам, скажи им!"
"Как я вилкой-то чистить буду?"
Виртуализация на ARM - печальная история.
Примеры костылей? Именно в x86_64. А то костылей, из которых ARM и состоит, можно привести массу. От странных размеров imm, не влезших в прокрустово ложе фиксированных кодировок команд до штук 5 попыток сделать вложенную виртуализацию. А уж забавные косяки RTL, которые принято патчить компилятором и костылями в ядре ОС - отдельная песТня.
Классика же
Это, допустим, субъективизм чистейшей воды, и главный баг FDT - отсутствие исполняемого кода - не фиксится вовсе.
Тогда зачем им devicetree, раз ACPI якобы есть?
Но главным образом - опыт ученых американских.
Молодой человек, это какого надо человека права.
Какой там 2006 - еще с 96-97 25 лет сплошных побед.
>если какая-то несовместимость с системными либами - можно ведь докер взять
Вообще не нужно. chroot, и все.
>QEMU
Ключевое слово здесь. Во-первых, является ли эта задача CPU-bound или IO-bound? Более вероятно второе - смотрите количество потоков, порождаемых этой поделкой, и потребление памяти. Если потоков слишком много, то это оно (там IO так сделан), и надо подбирать бэкэнд среди нескольких полурабочих
Какой жадный порридж.
POSIX AIO в glibc, помнится, был реализован на тредпуле - возможно, так и осталось. С Native AIO там были связаны относительно удобные векторные системные вызовы (что-то наподобие io_pwritev, io_preadv, на которых было достаточно удобно делать 0-copy DMA, но там была куча багов в обработке kiocb