Сертифікацію — так. [Намагатися] наситити нагайну потребу зараз — так. А до всього решту ще потрібно дожити.

Про ефективність — Ви помиляєтеся. Ми аналізували це питання, із залученням багатьох зацікавлених і фахівців.

Власне, я ж згоден із Вашими міркуваннями! Але у Вас одне неявне припущення — що наші турнікети (які давали живим людям) гірші за середні, які «офіційно» йдуть на фронт. Це не так. (Зрозуміло, що поки — лише з моїх слів). Перед тим, як кудись їх відправляти, ми перевіряли, переперевіряли і знову, не знаю, прокидалися посеред ночі і бігли доперевіряти — знаючи, чим постановка експерименту відрізняється від «внутрішнього переконання». В припущенні, що ми не помилися — моральна проблема стає інвертованою.

Безвідносно до основної теми нашої дискусії, про стійку психіку. Був у нас конфлікт: одна людина, в той момент причетна до проекту, допустила річ, яку можна назвати злочинною недбалістю. Зробив жорстке зауваження — без лайки, погроз абощо, але і без евфемізмів. Реакція була — сльози, істерика, звинувачення, що я травмую, а вона вже й так настраждалася, і скарги на мене у всі інстанції. Зрозуміло, що тієї людини більше у нас не бачили.

Ні. Але ми користуємося їх досвідом. А «шишок» у тому, що залишилося — достатньо, але цілком підйомна кількість.

Саме так. Це називається — волонтерство. :-) А займатися все життя тим ми не плануємо.

1. Звичайно, ми читали, радилися із тими, хто нею займався. Але власного досвіду дефектокопії — не маємо.
2. Власне, ми, здається, про схоже говоримо! Я описав: «той же принтер, матеріал із тієї ж поставки, [зазвичай — та ж одна котушка, але іноді кілька з однієї партії закупки], той же день, той же оператор». Крім того, перевіряється кожен екземпляр! — просто недеструктивно, а статистика — для виявлення чогось, що проскочило візуальний і недеструктивний механічний контроль.
3. Ми в жодному разі не кажемо, що вартість в виробників не виправдана! Ми вкладаємо свій ресурс, звідти й ціна. Але справа навіть не так в ній — як в потребі, яку поставки поки не закривають.
4. Ви знаєте, знову дискусія йде в сторону неможливості відтворити інопланетну технологію. :-) Щодо заклику до життя солдатів — про емоційну сторону, зокрема — для кого це роблю/робимо, в тому числі — особисто, писав нижче. А по збоях, знову згадаю: «Evaluating new types of tourniquets by the Israeli Naval special warfare unit» (disastermilitarymedicine.biomedcentral.com/...​s/10.1186/2054-314X-1-1) «CAT and SOFTT were found to be superior to the IRT, in occluding arterial blood flow to the extremities (22%, 23% and 38%, respectively, failure rate)». Ні про яких 99.9%, яке неявно постійно висить в обговореннях, не йдеться для жодного турнікету, і тому їх радять завжди мати два — і накладати зразу другий, якщо є сумніви або кровотеча (вже послаблена) продовжується.

А про 20-30-70% — вибачте, це суперечить нашим експериментам дуже суттєво. (Так, розумію — це тільки з моїх слів, але у Вас інформації точно менше :-) Останніх 4 ітерації дизайну і 3-4 сотні виробів із запчастинами, що пройшли наш контроль якості (уточнення, бо пробуємо не тільки з ними), у нас не було жодної поломки, яка могла б послабити затискання під час застосування.

Я вище в коменті описав склад нашої команди, тому не повторюватимуся — це частково є відповіддю щодо системності: dou.ua/...​rums/topic/37968/#2394252 . Все ж, стаття була не про процеси, та й комент я не задумував як протокол — лише короткий опис. Вже побачили, що мусимо і про це написати.

Щодо військових — турнікети отримали люди, які знають їх походження, і свідомо взялися випробовувати — спочатку тестуючи їх самостійно. Звичайно, не у всьому спектрі варіантів — але вони також мали доступ до наших тестів і довіряють їм (опишемо, повторюся!). Були зауваження і поради, але нічого такого, що могло б загрожувати життю.

Це мої друзі і знайомі. Люди жорсткі та не схильні до зайвих сентиментів. (Дехто із них є в коментах на ФБ — коли мають нагоду, але точно нікого немає тут). Якби щось пішло не так — я відповідатиму не тільки перед совістю, але й перед розгніваними військовими — не рандомними абощо (чим тільки вже мені не погрожували в ФБ) — а тими, які мене добре знають. Це знову не формальний протокол отримання дозволу для військових — хоча й Ваш запит не схожий на офіційний парланс, мова лише те, що це не абстрактні тестери, а живі люди, з якими я взаємодію. Якщо Ви у Львові — можемо якось домовитися про зустріч із тими з них, хто буватиме тут (зазвичай вони на дуже коротко потрапляють).

Щоб щось тестувати, його потрібно виробляти. Так працює навіть в цифровому світі — важко тестувати відсутній код, хоч і менш жорстко, ніж в реальному.

Розподіл тиску по поверхні, півобертах та його зміну протягом двох годин — тести виконуємо. Маємо відповідні відео і т.д. — готуємо більш технічний матеріал із подробицями. Температурні коливання — теж. Тестувалося на людях від тендітних (для дітей — не підходять, як і більшість решту турнікетів — потрібна окрема дитяча модель) до крупних різної тілобудови, включаючи — тренованих, включаючи динамічні навантаження. Звичайно, є тести на доплері. Ви навіть мали шанс їх бачити. Працюємо над більш технічним описом.

В подальшому не планую відповідати на Ваші демонстративно зверхні чи хамські коментарі, однак тут Ви сформулювали дуже важливі питання — то не втримався. BTW, чи могли б Ви підказати компанію, де Ви працюєте? На жаль, не знайшов на Вашому профілі в Linkedin — хотів би поцікавитися, чи є такий стиль дискусії їх корпоративним, і якщо так — уникати, якби довелося перетнутися.

Так і є — недоступні людям технології? :-)

Назва статті, на жаль, таки невдала... Це — не кустарне виробництво і не чисто студентський проект. Команда: Medical robotics engineer із Worcester Polytechnic Institute, що спеціалізується по виготовленню роботів для медичних маніпуляцій; фізик із одного з кращих НДІ України — ІФКС, [опір матеріалів, теорія і практика постановки експериментів, мат. статистика входять в базову освіту]; велика група старанних і ретельних студентів; залучені медики та парамедики — із яких більшість, через потік безапеляційних, часто — хамських, і, зазвичай — безпідставних звинувачень, не хочуть говорити публічно, [із тих, хто записав відео — Олег Кристиняк (військовий парамедик, інструктор школи «Воїн Самооборони»); Thom Mayer, (medical director of the NFL Players association); David Young, (wilderness medicine doctor), Rupen Dajee, (paramedic) — іноземцям якось простіше]; ряд інших фахівців — по тканинах, пошиттю, друку, засобах тестування; що консультували. Цих людей достатньо, щоб разом створити виробництво турнікетів, користуючись вже перевіреними іншими науковцями, виробниками і практикою ідеями.

Повертаючись до інопланетян, турнікет — достатньо простий виріб. Багато складніший, ніж можна кустарно зробити вдома — є багато нюансів! Ми надивилися на ті жахіття! Тому теж не підтримуємо «Надрукував на принтері собі турнікет». Однак, в порівнянні із задачами, які ми вирішували повсякденно у своїй довоєнній роботі — простий. Будь-який буденний масовий виріб — нетривіальний, насправді. В результаті, ми тижнями шукали, що ж ми такого впускаємо, раз така жорстка критика?! Виявилася загадкова річ. Люди чи то забули, що університети та інститути є тими установами, що розробляють нові ідеї, технології та прилади. Чи, через якісь особливості освіти, практики, не знаю, повсякденного життя, повірили у безпомічність свою та інших осягнути зовсім прості речі. Проблема, що, в результаті, замість фахової критики, обговорення, в коментах, в основному типові, «клішовані» фрази-закиди від людей.

Щодо відтворюваності, зацитую статтю: «Evaluating new types of tourniquets by the Israeli Naval special warfare unit» (disastermilitarymedicine.biomedcentral.com/...​s/10.1186/2054-314X-1-1) «CAT and SOFTT were found to be superior to the IRT, in occluding arterial blood flow to the extremities (22%, 23% and 38%, respectively, failure rate)».

Дякую за Ваш коментар! У нашої команди виникла проблема — кожного разу в коментах дуже багато прямих стереотипних закидів, і зовсім мало конкретики.

1. Дефектоскопія — так, це дещо б спростило контроль якості. Таких приладів у нас немає, але думаємо над варіантами, як її організувати. Будемо вдячні, якщо порадите щодо технічної сторони, зокрема — вибору приладів! Зараз задача вирішується ретельним оглядом кожної «тонкої» пластикової частинки — кліпси, пластинки, пряжки, де дефекти лягання волокон видно та механічним випробуванням воротка — завдяки великому запасу міцності, це достатньо безпечно.

2. Про маркування — у нас є такий варіант. Зараз, оскільки весь друк, що йде в роботу, відбувається локально і під постійним наглядом, підхід наступний: одна зміна (конкретний оператор принтера протягом 6-8 годин), одна партія пластику, один принтер — вважається партією пластикової деталі, ретельно оглядаємо, але зберігається окремо, до статистичного тесту. Маркування з унікальними кодами передбачені, якщо дійдемо до розширення.

Однак, щодо статистичного тесту, (із Вашого п.1) що працює лише для іграшок — не погоджуся. Це спосіб виявити непередбачені проблеми, із достатньою ймовірністю — за правильного дизайну методу. Методики для такого і розроблялися.

3. Падіння міцності з часом в масштабі кварталів-років безпосередньо ми не заміряли, покладалися на дані з літератури — наші тести лише тривають. Значимої деградації за тижні в воді чи на сонці не спостерігалося. Із польових випробувань — за тиждень в полі (заморозок-сонце-сухо-вода-повторити), єдине що відбулося — відклеїлися частина білих смужок для підписів. Виправили, чекаємо на тест. (По застосуванню зауважень до останнього варіанту не було). Якщо ж Ви про накладений турнікет, поведінка при намоканні на рівні CAT. Працюємо над використанням литих деталей, але, хоча досягнути належної міцності там простіше — гарантії лиття не дає, теж купа потенційних проблем і ті ж тести.

Ми готуємо більш технічний і з більшою кількістю подробиць, матеріал — це займе трохи часу. Будемо вдячні за Ваші відгуки там. Стосовно воротка: міцність на злам «в цілому», коли його беруть за кінці; міцність на злам кінця, який фіксується на кліпсі; міцність на злам внутрішньої частини — у якій паз для стропи, при закручуванні. Якщо проходить візуальний контроль на якість друку (який ми виконуємо для кожної деталі!) і обмежений механічний, фіксуючи деформацію (максимальний пошкоджує, у вироби такі давати не можна) — запасу міцності достатньо для будь-якого практичного використання.

Звичайно, зараз це лише свої слова — але у технічному матеріалі буде більше подробиць із фото-відео. Крім того, їх тестують в полі, поміж іншого, мої друзі на фронті. Люди, які вимагають більше і швидше, яким інші пропоновані способи «закупіть, знайдіть волонтерів/гроші» не допомагають в належних об’ємах, і які, ну, люди різкі — словами чи зіпсутою «кармою» не обмежаться. На жаль, на ДОУ вони не бувають. Працюємо над сертифікацією, хоч це і складно.

Щодо кустарного виробництва — мова не про «краще, ніж нічого». Ми працюємо, щоб зробити просто добре. Власне, назва статті вийшла відверто невдалою. Це не зовсім студентська робота — хоча їх вклад величезний, це проект співпраці (людей із) двох університетів. Якось в тих дискусіях відчуваю часто, люди чи то забули, що університети і є місце, де створюється нове, а дрібно-серійні виробництва там — нормальна практика, чи щось ще й гірше...

Якщо дуже коротко (трохи детальніше — в інших коментах), ми працюємо над тим, щоб сертифікувати. Однак, наші внутрішні тести відповідають і розширюють процедури, що використовуються при тестуванні на сертифікацію. Крім того, ми проводимо різноманітні польові і наближені випробування.

А на китайські, які ламаються двома пальцями і на жахіття саморобні, ми надивилися... Тому, в жодному разі не підтримуємо «сам зробив на 3д принтері» — забагато нюансів.

Ви знаєте, в мене іноді закрадається думка, що люди вірять — турнікети нам постачають інопланетяни, виготовляючи їх за недоступними людям технологіями... І не в людських силах їх відтворити. Ми тестуємо — всіма доступними нам способами, ми консультуємося із військовими та (пара)медиками, просимо її випробовувати — детальніше писав у іншому коментарі. Поміж сертифікованих турнікетів, які йдуть на фронт і для яких ми змогли отримати зразки, наші тести успішно проходять заледве половина.

Вороток — ота ручка для закручування, має вже міцність із багатократним запасом. Звідти жартівлива історія про ламання — нам потрібно було мати певну кількість зламаних. Взагалі, більшість підводних каменів — не в пластикових частинах, зробити їх належної міцності можна, хоча це й вимагає зусиль і акуратності. Наприклад, дуже серйозні вимоги до стрічки, що стягує. Якщо основна стропа масивна, то ця стрічка помітно менша, її розрив чи розтягування — смертельно небезпечні. Якщо вона скручується — це боляче і може додатково травмувати. І таких нюансів — багато десятків. Ми крок за кроком продиралися через все це — з тестами, дискусіями і т.д. В жодному разі не підтримуємо «зроби турнікет на 3D-принтері» — сходу і фурнітура буде непридатною, і все решта проблемним.

Ми працюємо над сертифікацією, але це потребує купу часу. Будемо вдячні, якщо відгукнуться люди, причетні до сертифікації таких виробів, з якими ми могли б порадитися — або співпрацювати.

Так, віддаємо — дякуємо. Довідалися про них минулого тижня.

Ми тестували та тестуємо найрізноманітнішими способами — працюємо над розробкою технології і тестуванням від перших днів війни, із залученням як парамедиків та військових, так і інженерів по розробці медтехніки.

Чи зупиняється кров — за допомогою ультразвукової доплерографії. Чи тримає тиск протягом тривалого часу — на пластичній пластиковій ємкості, щільно заповненій водою, із манометром, (такий прилад використовується під час сертифікації). Тести на руйнування — за яких умов і як ламається, на ходіння з турнікетом — щоб моделювати динамічні навантаження і т.д. і т.п.
Систематичні тести в умовах, наближених до реальних, проводилися, поміж іншого, під час тренінгів у школі «Воїн самооборони». Випробовувалися в польових умовах, військовими парамедиками, які знали, що це — поки не випробуваний виріб.

Схема тестування відтворює та розширює ту, що використовується під час сертифікації. Ми працюємо над тим, щоб сертифікувати, однак, це довга процедура. Дякуємо за відео, будемо дивитися, можливо є ідеї до тестування, які ми поки не використали.

Для окремих компонент — як пластикових, так і стрічок, теж маємо формалізовану процедуру тестування. Окремо статистично тестується кожна партія — виготовлена у тих же умовах, за наглядом тієї ж людини, за один захід. Потім аналогічно тестується 5-10% випадкових виробів.

Ні, f(x) відносно компактна (хоча виконуватиметься не менше пари-другої десятки тактів), просто дуже багато раз викликається.

Для різних точок час роботи буде на 2-3 порядки відрізнятися, тому початкові затримки швидко «забудуться».

Щодо IACA — теж зразу подумав, що це любительська утилітка. Тим не менше, для моїх (нехай, специфічних) задач: з одного боку, робота із студентами, викладання, з іншого — обчислювальний код, корисна.

Я говорю о том, что его реальный кейс в книге высосан из пальца.

А это тут причём? Если данные объёмные, какая вероятность того, что несколько ядер будут писать в один участок памяти?

Щодо спільного використання рядків кешу, приклади із моєї практики (фізик-теоретик, ІФКС), опис тезовий, заради лаконічності — і так багато тексту:
1. Двомірна CFD-задачка, наприклад, розв’язання рівняння теплопровідності. Двомірний масив: температура у кожній точці сітки. (Якщо взяти цікавішу задачку руху газу чи рідини — в кожній точці буде вектор із 5 елементів). На кожній ітерації весь цей двомірний масив оновлюється. Очевидно, обчислення розпаралелюються. [Синхронізація на кожній ітерації, хоча можна хитрувати]. Кожному потоку виділяється свій квадратний блок сітки. На границях блоків маємо якраз таку ситуацію.
2. Так-звана модель Фалікова-Кімбала, будуємо фазову діаграму. Для цього слід розв’язувати хитре інтегральне рівняння — багато-багато раз. Його розв’язання, у свою чергу, потребує від тисяч до мільйонів раз виконати таку операцію: x[i] = f(x[i]) у багатьох (до десятків мільйонів) точках. Тобто, є великий масив double чи std::complex, кожен елемент якого оновлюємо на кожній ітерації. Знову ж — розпаралелення. Кількість ітерацій для різних точок може відрізнятися на 2-3 порядки. Тому прямолінійна реалізація розпаралелення може просто брати для обчислення наступний ще не порахований елемент масиву. І на одному рядку кешу топтатиметься 4-8 потоків. [Особливої синхронізації між потоками не потрібно, крім бар’єра в кінці].
3. Задачі молекулярної динаміки — теж 2/3-мірний масиви, теж постійно оновлюються різними потоками, хоча, часто (завдяки використанню хитрих алгоритмів) синхронізації багато менше треба, ніж в п. 1.

Типовий наш обчислювальний вузол — два 6- або 8-ядерних процесора. Плюс гіпертрідінг ввімкнено — множимо кількість потоків виконання на два. (Експерименти показують, що він дає виграш мінімум 10-15% по часу, іноді більше. При обчисленнях, які тривають тижнями і місяцями — непоганий виграш).

Правда, не маю акуратно заміряної ролі того ефекту. Може таки треба буде провести невелике дослідження...

Щодо uncached write: за пояснення — дякую, тепер зрозумів, про що Ви!
В принципі, можна б ще й подискутувати під настрій (на тему інтерпретації конкретних фраз :-), але в цілому — згоден, той підрозділ більше збиває з пантелику.

Если посмотреть на сгенерированный код, то он уже давно один и тот же на протяжении многих поколений процессоров.

Цікаво! Подивлюся при нагоді. Було інше враження, але можу помилятися — не звертав особливо уваги.

Её поддержку как раз дропнули и переключились на VTune.

Яке джерело інформації, що закинули? Анонсів на сторінці чи форумі не бачу (не дуже ретельно шукав, зізнаюся), частота релізів — в межах норми, стверджують, що в кінці минулого року радикально її переписали...
VTune — інструмент важливий, але інший.

По решті ж — в мене остаточно виникло відчуття, що ми говоримо різними мовами.

Давайте так:
1. Агнер Фог стверджує: коли два різних потоки пишуть у різні комірки пам’яті, які належать одному рядку кешу, це сповільнює виконання коду. (В порівнянні із ситуацією, коли комірки із різних рядків кешу).

Ви ведете до того, що це твердження помилкове? Чи правильне, але мотивація невірна? Чи ще щось? Якщо можна, із обґрунтуванням або посиланням на джерела.

В современных процессорах судя по падению производительности более чем в 100 раз, процессор просто переходит на некешируемый протокол обмена с памятью.

Чи Ви ведете до того, що сповільнює? Що тоді не так із написаним в автора?

Ремарка:

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

Такі ситуації бувають регулярно, в тому ж коді молекулярної динаміки, CFD чи інших фізичних та інженерних обчисленнях. Часто, ще й в умовах великого тиску на кеші — дані об’ємні, матриця (розріджена) мільйон на мільйон — звична річ.

Крім того, звертання до різних комірок — data race немає за означенням, про атомарні операції мова просто не йде.

2. Далі, там же, він стверджує, що лише читання, в тій же ситуації, не сповільнює (при співпадінні інших умов, звичайно).

Процентов 10% производительности съедает.

Я правильно розумію, ви стверджуєте, що сповільнює на ~10%? Якщо так — з чим це пов’язане? Особливо, якщо я правильно зрозумів Ваше твердження із п.1. (Прохання пояснити чи надати джерела — не щоб змусити Вас витрачати зайвий час і т.д., просто, якщо я правильно розумію Ваші твердження, вони — достатньо дивні, хотілося б розібратися).

3.

Они умели всегда, начиная с i386 ...

— і текст далі, не став все копіювати. Якраз тут я остаточно перестав щось розуміти. З мінімальним врахуванням контексту, ( немає сенсу говорити про NC-регіон чи ввімкнений (глобально чи для регіону пам’яті) режим WB), говорячи про взаємодію записів у RAM i кешу, автор пише те ж, що й Ви...

Його висновок якийсь такий: «Якщо відбувається запис в область пам’яті, яка не буде читатися найближчим часом, ефективним може бути скористатися командою ’записати без кешування’». Воно, з Вашої точки зору, правильне, помилкове — стане гірше, помилкове — немає різниці? І, якщо помилкове — те ж запитання: чому? Мені здавалося, без цієї інструкції, процесор підтягне в кеш відповідний рядок — створюючи зайвий тиск на кеш. Це помилкове уявлення, чи за Вашими міркуваннями стоїть ще щось?

4.

Даже там она сейчас не играет особой роли.

Як же їм тоді вдається генерувати код (а таки вдається), що складається із часто неочевидних інструкцій, який, тим не менше, швидший за еквівалентний, написаний на асемблері вручну, просто із знань ISA, без особливого залучення відомостей про мікроархітектуру?..

Не то, чтобы существенно, но поток — это примитив ОС, а не процессора.

Потік, справді, абстракція ОС, процесори про них (майже) нічого не знають. Але ж треба якось говорити про потоки виконання коду, які виконуються на різних ядрах багатоядерного процесора. При чому, у випадку, що розглядається, у них має бути спільна пам’ять, тому thread краще підходить, ніж process.

Он описывает типичный случай race condition, который никто не будет использовать, ибо смысла в этом немного.

Гонитви даних чи атомні змінні до ситуації, що розглядається, не мають відношення. Нехай є масив чисел, два різних потоки (виконання коду, що виконуються на різних ядрах одного процесора) звертаються, в тому числі — на запис, до двох сусідніх його елементів (double якихось абощо), які потрапляють в один рядок кешу. Тоді цей рядок постійно перетягуватиметься між кешами L1 двох ядер. В старому MESI це взагалі довго, але й форвардинг із MESIF чи аналогічних — не безкоштовний (хоча, безпосередніх вимірювань не бачив, зізнаюся).

Лише читання цієї проблеми не породжує — той же рядок буде в кількох кешах та й все. Тому порада автора залишається правдивою, хоч і менш значущою, ніж була колись.

Про uncached доступ всё ошибочно от начала и до конца.

Випадок із записом в кеш аналізувати мені важче — не знаю подробиць,невже сучасні процесори навчилися безпосередньо із буфера запису в основну пам’ять писати, без залучення кешів? Якщо ще ні, то автор трішки нижче пише про мотивацію такого твердження: «This [інструкції, які пишуть безпосереньо в пам’ять, уникаючи кешування] is advantageous in cases where we are writing to uncached memory and we do not expect to read from the same or a nearby address again before the cache line would be evicted». Сенс в цьому є. Якщо ж вже навчилися — підкажіть, де можна про це почитати, якось я впустив...

Я не говорил об ошибочности, я говорил о бесполезности и малоправдивости.

Неправильно зрозумів Вас, подумав, кажете — наведені таблички містять неправдиві дані (скажімо, пише — латентність чогось-там 7, а вона 27).

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

Справді, дані такі не часто потрібні — навіть «гарячий» код на асемблері рідко оптимізують. Та й в голові моделювати поведінку процесора важко. І оптимізатори компіляторів мало хто пише — де ця інформація критична.

Однак, іноді доводиться. І тоді варто знати — на які блоки претендувала дана команда, на який час їх займатиме, скільки породила мікрооперацій тощо. Так, воно буде доволі неточно — через складність задачі, але як відправна точка — зійде. Крім того, педагогічна роль не нульова — показати, що це за конвеєр, мікрооперації, ООЕ Вами згадуване і т.д. такі, іноді корисніше на конкретних прикладах. (Не вірять сучасні студенти без наочного прикладу — який самі запустити можуть, щоб ефект побачити).

До речі, для інтелівських процесорів останні роки є помічна утилітка, що якраз таким займається: IACA.

1. Безперечно! Оскільки книг мало бути 5, я трішки схитрував — написав про неї в кінці розділу про Патерсона і Хеннесі.
2. Так, ARM явно виглядає перспективнішим зараз, хай пробачать мене автори книги із п.1, але ARM-варіант мені поки в руки не потрапляв.

Певні анахронізми у нього справді присутні — у будь-яких книгах, які перевидаються десятиліттями, трапляються речення, що свою актуальність втратили, а автор не зауважив.

Однак, мушу сказати, решту Ваших твердження виглядають достатньо дивно. Зокрема, в чому ж така суттєва помилковість зацитованого Вами, про спільне використання рядків кешу різними потоками? (Навіть якщо про літеру F знати у якому-небудь MESIF)

Також, чисто практично, на чому базується Ваша думка про помилковість таблиць (із четвертого тому)? Якщо Ви знаєте надійніше джерело/джерела (наприклад, експериментальні публікації щодо конкретного процесора чи мікроархітектури) — поділіться. :-)