Репутація українського ІТ. Пройти опитування Асоціації IT Ukraine
×Закрыть
Leading engineer в Institute for Condenced Matter Physics
  • DOU Books: 5 книжок про функціонування комп’ютерів від Олега Фаренюка, викладача УКУ

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

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

  • DOU Books: 5 книжок про функціонування комп’ютерів від Олега Фаренюка, викладача УКУ

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

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

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

  • DOU Books: 5 книжок про функціонування комп’ютерів від Олега Фаренюка, викладача УКУ

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

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

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

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

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

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

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

    Ремарка:

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

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

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

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

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

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

    3.

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

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

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

    4.

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

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

  • DOU Books: 5 книжок про функціонування комп’ютерів від Олега Фаренюка, викладача УКУ

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

    Потік, справді, абстракція ОС, процесори про них (майже) нічого не знають. Але ж треба якось говорити про потоки виконання коду, які виконуються на різних ядрах багатоядерного процесора. При чому, у випадку, що розглядається, у них має бути спільна пам’ять, тому 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.

  • DOU Books: 5 книжок про функціонування комп’ютерів від Олега Фаренюка, викладача УКУ

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

  • DOU Books: 5 книжок про функціонування комп’ютерів від Олега Фаренюка, викладача УКУ

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

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

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

    Поддержали: Valentin Nechayev, Dmytro Menshykov