×

We’re approaching the limits of computer power — we need new programmers now

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Ever-faster processors led to bloated software, but physical limits may force a return to the concise code of the past

Way back in the 1960s, Gordon Moore, the co-founder of Intel, observed that the number of transistors that could be fitted on a silicon chip was doubling every two years. Since the transistor count is related to processing power, that meant that computing power was effectively doubling every two years. Thus was born Moore’s law, which for most people working in the computer industry — or at any rate those younger than 40 — has provided the kind of bedrock certainty that Newton’s laws of motion did for mechanical engineers.

There is, however, one difference. Moore’s law is just a statement of an empirical correlation observed over a particular period in history and we are reaching the limits of its application. In 2010, Moore himself predicted that the laws of physics would call a halt to the exponential increases. “In terms of size of transistor,” he said, “you can see that we’re approaching the size of atoms, which is a fundamental barrier, but it’ll be two or three generations before we get that far — but that’s as far out as we’ve ever been able to see. We have another 10 to 20 years before we reach a fundamental limit.”

We’ve now reached 2020 and so the certainty that we will always have sufficiently powerful computing hardware for our expanding needs is beginning to look complacent. Since this has been obvious for decades to those in the business, there’s been lots of research into ingenious ways of packing more computing power into machines, for example using multi-core architectures in which a CPU has two or more separate processing units called “cores” — in the hope of postponing the awful day when the silicon chip finally runs out of road. (The new Apple Mac Pro, for example, is powered by a 28-core Intel Xeon processor.) And of course there is also a good deal of frenzied research into quantum computing, which could, in principle, be an epochal development.

But computing involves a combination of hardware and software and one of the predictable consequences of Moore’s law is that it made programmers lazier. Writing software is a craft and some people are better at it than others. They write code that is more elegant and, more importantly, leaner, so that it executes faster. In the early days, when the hardware was relatively primitive, craftsmanship really mattered. When Bill Gates was a lad, for example, he wrote a Basic interpreter for one of the earliest microcomputers, the TRS-80. Because the machine had only a tiny read-only memory, Gates had to fit it into just 16 kilobytes. He wrote it in assembly language to increase efficiency and save space; there’s a legend that for years afterwards he could recite the entire program by heart.

As Moore’s law reaches the end of its dominion, Myhrvold’s laws suggest that we basically have only two options. Either we moderate our ambitions or we go back to writing leaner, more efficient code. In other words, back to the future.

amp.theguardian.com/...​need-new-programmers-n-ow

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Но шо , Диды, расчехляйте свой Си!

Вбрось хороший проект и зарплату — расчехлим)

Так OpenCL даже для скриптовых языков даёт сильное ускорение где оно нужно.

где человеки, там х#%ня и неэффективность, причём первого больше.

слава роботам!

Якби ж то!

Точно не «незабаром» бо нема механізму генетичної модифікації мітохондрій.
Також наступні пункти:
1) Не вирішене питання ракових пухлин. З віком сильно збільшується шанс захворіти.
2) Генетично сповільнені сіньори можуть виявитись недостатньо працьовитими.
3) Наразі маємо проблеми з нервовою системою та психікою при збільшенні віку людини.

Там в статті не про збільшення молодості, а про вповільнення енергообігу в організмі (аналогічно тривалому голоданню). От чи багато голодний сіньор накодить?

клітини переходять в режим відновлення а не ділення пошвидше

не клітини, а мітохондрії. А клітинам в цей час не вистачає енергії, котру ці мітохондрії мали б виробляти.

Якщо голоду не відчувається то в чому проблема?

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

Стаття базується на цьому en.wikipedia.org/...​hondrial_theory_of_ageing
Зазвичай рекомендують голодувать періодами. При тривалому голоданні чи обмеженні калорійності їжі змінюється психічний стан — стаєш спокійнішим. Але робить теж нічого не хочеться. Таке собі «созерцание». Більш-менш схоже описано тут www.lib.ru/...​IT/SMELEW/shmelev_sun.txt

А текстом нема? Там же година...

Дякую, цікаве.
Час впливає на організм мінімум наступними шляхами:

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

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

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

Чувак в статті бореться з пунктом (1). Якщо вони його поборють — матимемо популяцію старих маразматиків з постійними хірургіями раку.

Якщо цікава соціальна модель суспільства з необмеженим терміном життя — раджу почитати Фукуяму gtmarket.ru/...​aboratory/basis/3604/3608
Там і інші моделі розвитку генетичного суспільства гідні антиутопій)

Не знаю, де ядра клітин зорового нерва. Пошкоджені нерви відростають десь на сантиметр за рік. Але це не нові клітини, а «хвости» клітин, ядра котрих знаходяться в головному чи спинному мозку.

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

Пошкоджені нерви відростають десь на сантиметр за рік.

миллиметр в день

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

Творческое состояние...

Во что они собрались упираться, если клауд только набирает обороты ?

А клауд этот на каких-то других инопланетянских процессорах работает?

уперся в перформанс — поднал еще один инстанс.

А взаимодействие между инстансами перформанс конечно же не сжирает

Ну и опять же, не все задачи параллелятся, закон Амдала никто не отменял

Это все хорошо, Карл. Только ты понимаешь что 3 гигагерц пенек был выпущен в 2003.

17 лет назад, Карл!

С тех пор частота не растет. При этом количество овнокодеров и вакансий для них не уменьшаеться а все растет и растет.

Как это не растёт? В кукурузенах и i9 4 ГГц, а разгоняются они до 4.5 ГГц и даже до 5 ГГц.

А если до графеновых процессоров доживём, то и повышения частот на порядок стоит ожидать. Но вот что-то пока даже мемристоров обещанных не видно.

и даже до 5 ГГц

Так разгоняли еще в 2005.

А если до графеновых процессоров доживём, то и повышения частот на порядок стоит ожидать.

Если доживем то хорошо.

эх сейчас бы думать что производительность проца зависит только от частоты

використовувати тормозні фреймворки, і почати оптимізовувати наш власний код

Основная проблема в том, что мы не пишем нетленку, а решаем проблемы бизнеса и «making customer happy». И мы получаем зарплату за свою работу, причем даже не за результат работы, а за часы работы. При этом более качественный и оптимизированный код требует больше часов разработки и стало быть более дорогой. Так вот, если бизнес удовлетворяет текущее решение их бизнес-проблемы, но которое требует 28 ядерный мак и где-то 50 тыс$ на разработку, то это решение будет выгоднее чем требующее обычного 4-ядерного PC и пару миллионов долларов на разработку.

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

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

которое требует 28 ядерный мак и где-то 50 тыс$ на разработку то это решение будет выгоднее чем требующее обычного 4-ядерного PC и пару миллионов долларов на разработку.

в наши 90ые как-то столкнулся с софтом в одной клинике, в качестве сервера обычная 286 машинка, к ней с 5ок терминалов.
автор лишился работы, нии и завод что курировал этот нии закрылись, и за еду, на С вперемешку с ассемблером написал всё.
от собственной базы данных до ui.
летало!

ну а потом, говорят уехал таки, в америки.

клиперисты потом пытались заменить, но — железа им требовалось поболе, для нетвари серверок, 486ой, и 286ые вместо терминалов

we need

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

Прийшов час зупинитися, перестати писати і використовувати тормозні фреймворки, і почати оптимізовувати наш власний код?

ніхто не заважає:
перестати використовувати тормозні фреймворки
та замість завдань від бізнесу — оптимізувати власний код.

Просто зупиніться, та почніть нову епоху!

P.S.
про нову епоху, майже без жартів
dou.ua/...​rums/topic/29433/#1756640

“Anything less than immortality is a complete waste of time.” © Bender

Невже настає епоха вдуманого програмування і висококваліфікованих розробників?

о боже нет! только не это!

Сказки и влажные метчы «труЪ-программеров».

Я намекну: лимит человеческого потенциала достигнут хрен знает когда. И хрен знает сколько раз. Открыто заявляю, люди отстой, развивайте рептилоидов

Это же хорошо. Каждые два года будет выгорать в два раза больше айтишников, не выдержав сношания мозга ассемблером.

Не всегда ассемблер дает перформанс. На C будет универсальнее. Хотя C тоже хватит)

да этот баян каждые 5 лет публикуют

Он 5 лет назад ещё читать не умел %)

вот только технологии производства чипов, с каждым разом, все ближе и ближе к атомарному пределу, о чем выше и было сказано

Зато сами чипы все дешевле. Пересядут на фермы из АРМов. Что поменяется?

Тут вопрос в блокировке — как гарантировать, что в ту же память не пописал кто-то другой. На хардварном уровне там какая-то жесть между кешами процов, которые отслеживают инвалидацию по кольцевой шине. Даже на вики многобукв en.wikipedia.org/wiki/Cache_coherence
Если туда еще видяху запихнуть — прийдет капец.

Кстати, тут один человек на ДОУ давно предлагает новую архитектуру...

*начертил вокруг себя круг* (или пентаграмму нужно было?)

Та уже смесь везде
Modern processors appear to the user to be von Neumann machines, with the program code stored in the same main memory as the data. For performance reasons, internally and largely invisible to the user, most designs have separate processor caches for the instructions and data, with separate pathways into the processor for each. This is one form of what is known as the modified Harvard architecture.
en.wikipedia.org/...​wiki/Harvard_architecture
Майка надо пригласить.

Хомо сапіенси не мислять мультипоточно. Точніше мультизадачність у нас витісняюча. З чого випливає, що писати /дебажити код, в якому все по іншому — насилувати мозок.

Нужно будет больше программистов чтобы делать то же самое.

Не знаю, как другие, но я точно не зависаю когда ем суп или когда смотрю в монитор %)

так суп через AsyncIO

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

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

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

Сложности возникают только когда нужно делать 2+ задачи, в которых нужно думать, в твоём списке это максимум одна, так что это легко достижимо

Кстати, может я и не прав, но уже сейчас нет смысла в более чем 4-6 ядер на PC. Чтобы их заюзать полноценно тебе нужно вывернуться наизнанку в коде. Реально 2-3 еще как-то будут работать, остальные ждать и кушать электричество.

Смотря чем на нем заниматься. Нужна статистика. Вот в компиляцию много ядер умеют.

Я не шарю в математику

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

1) заполняем массив размерности 2^16: 
uint32_t sq[256][256];
for(unsigned i = 0; i < 256; ++i)
    for(unsigned j = 0; j < 256; ++j) {
        const int tmp = i - j;
        sq[i][j] = tmp * tmp;
    }
2) делим входную матрицу на количество относительно равных сегментов по количеству доступных ядер numcores
uint64_t result[numcores];
memset(result, 0, sizeof(result);
uint32_t start[numcores];
start[0] = 0;
for(unsigned i = 1; i < numcores; ++i)
    start[i] = start[i - 1] + size / numcores;
3) на каждом ядре запускаем по потоку:
for(unsigned offset = start[core]; offset < start[core + 1]; ++offset)
    result += sq[A[offset]][B[offset]];
4) когда они домолотили, суммируешь result:
uint64_t final = 0;
for(unsigned i = 0; i < numcores; ++i)
    final += result[i];
return sqrt(final);
будет оно быстрее или медленнее, чем в лоб — надо мерять.
result += sq[A[offset]][B[offset]];

Вот ты правильно написал, а теперь вспомни, что у него есть процедура вычисления тензоров, где он ложит в матрицу результат, который в коде вверху ты опять достаёшь. Т.е. эту строчку кода нужно просто вставить в его процедуру вычитания тензоров. Всё.

На GPU вычесть 2 тензора очень быстро.

А как там на GPU со скоростью доступа к памяти? На CPU это основной тормоз будет, 256КБ индексного массива в кеш первого уровня не влезут.

А как там на GPU со скоростью доступа к памяти?

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

A и B — у нгего это не скаляры, а матрицы, там индексный массив не нужен.

По сути его задача: есть две матрицы A и B, над ними он делает unspeakable acts и получает матрицу С, как продукт операций над A и B. Дальше он шарится по всем элементам матрицы С и суммирует квадраты значений, в конце берёт корень из суммы (единичная операция).

Вся проблема в том, что он представляет операцию над A и B и над C как две разные задачи, что является ошибочным. Вполне возможно что над A и B работает не его код, а библиотечная функция но тут он ССЗБ, так как занимается оптимизацией кирпичиков неоптимизированного алгоритма.

ну так всегда. либо мало кода на питоне, либо — много на ассемблере.

ну не знаю. Там только пока инфраструктуру и заголовки напишешь — уже в 2-3 если не 5 раз кода больше.

Начнешь писать на CPU у тебя еще появиться момент с запуском потоков — они очень медленно запускают.

Запускаешь заранее, держишь потоки горячими (spinning threads). Если не умеешь в низкоуровневое потоковое программирование, то OpenMP расширение для С/C++, которое уже дохерища лет есть в gcc, сделает за тебя всю работу.

#pragma omp parallel for 
for (int j=0; j<n; j++)

в прагме можешь задать больше деталей, сколько потоков и как разбивать на гриды.

До этого стартовать пачку потоков и повесить их в ожидание, потом по мере поступления задач условными переменными запускать их — остальное время они будут стоять и ждать.

Обычно данные подготавливают заранее для всех потоков, они по заданному курсу ведут вычисления.

В реальности обычно в 1.5-2 раза быстрее на 8 ядрах, чем на одном с этой либой.

Там есть свои хитрости, как и везде. Например цикл на миллион, оно просто разобъёт на четыре цикла с разными диапазонами в каждом из потоков, что будет убийством. Это уже твоя забота, чтобы разбить длинный цикл на два вложенных, к примеру, чтобы сбалансировать разбиение и параллелизацию внутреннего на относительно короткие диапазоны.

А вот если ручками с потоками разрулится, то можно получить и в 7.5 раза на 8 ядрах, против одного

OpenMP вполне съедобно для 9/10 всех задач, за разруление ручками тариф может быть и 10x. Я около 8 лет подрабатывал удаленно тем что оптимизировал творчество тех, кто не умеет в оптимизацию и параллелизм. Обожал эту работу — снос башни каждый день, хуже наркоты, но очень стрессовая.

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

Ну тогда для тебя и использование -O0 и -O3 тоже должно быть обманом.

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

Так никто и не рассказывает для OpenMP, задействовали и отлично. Также как и с оптимизацией — для 9/10 всех случаев этого достаточно. За тюнинг идёт специальный прайс.

Один одесский еврей купил себе офигенно дорогой майбах. Неделю откатал на нем и майбах перестал заводиться. Что делать? Куда бежать? И посоветовали ему обратиться к старому Мойше, он-де первоклассный диагност, вмиг найдет и решит проблему. Пригласил еврей старого Мойше к себе, показал машину. Старый Мойше открыл капот и долго смотрел внутрь. Затем достал серебряный молоточек, стукнул им один раз и сказал еврею: «Заводи!». Еврей завел, машина работает.

СМ: С вас 10 000 долларов!

Е: И это за то, что вы один раз ударили молоточком?!

СМ: Неет, за то, что я один раз ударил молоточком, с вас 1 доллар. А вот за то, что я знал, куда ударить, с вас остальные 9 999 долларов!

а в реальности

Ты не путай галерное программирование с реальным программированием.

Кстати, может я и не прав, но уже сейчас нет смысла в более чем 4-6 ядер на PC. Чтобы их заюзать полноценно тебе нужно вывернуться наизнанку в коде. Реально 2-3 еще как-то будут работать, остальные ждать и кушать электричество.

Ты не прав. Когда ядра спят, то они потребляют меньше электричества, чем светодиод на корпусе. Вот взять эмбеддед, 4 ядерный процессор от Intel (ApolloLake), мой драйвер GPU, который в расслабленном состоянии имеет 21 поток и до 50 под нагрузкой. Как ты думаешь, 4 ядра мало или нет? 2/3 всех потоков, конечно, спят большинство времени, но, если ты имеешь около 10 клиентов, использующих GPU, то проснуться они все вместе по событию от GPU, например, рендеринг закончен. И каким образом ты сможешь обеспечить системе realtime свойства с одним или двумя ядрами?

Ну и второй вопрос Зачем они спящие в счетной задаче? Ждут, когда им доступ к памяти дадут?

Не все задачи счетные. У меня сейчас порядка 10 потоков:
* ЮСБ обработчик (1 или 2 потока)
* Прослойка (HAL) на стороне ЮСБ
* Основная логика
* Прослойка (vendor abstraction layer) на стороне SIP
* SIP обработчик (1 или 2 потока)
* Стек таймеров
* Работа с файлами (история звонков, телефонная книга)
* Нотификации демону через запуск скриптов
* Консольный ввод
* Прокачка аудио
Может, че забыл.
Все, кроме аудио, обычно не нагружены. Но написать это без потоков или тасклетов было бы той еще камасутрой. И тут минимум 3 уровня приоритетов:
0) аудио
(1) таймера
2) логика
3) файлы
Более высокие приоритеты должны прерывать задачи более низких приоритетов.
То есть, мне куча ядер не надо, но многопоточность очень даже полезна — каждый поток делает что-то свое, не лезет к соседям, и даже особо о них не знает.

что из этого нельзя сделать в одном потоке, машиной состояний, одним большим switch()-ем на 100500 case-ов? :D

Заказчик посчитает, что его обманули, когда у видит, что код очень прост.

Это проблемы заказчика. Я искал одну эфемерную багу в чужих GPU драйверах на протяжении больше года пробами и фейлами до тех пор пока не пришёл заказчик и не сказал, что дальше мы не едем, пока не исправим, я плачу. Вендор драйверов тоже был оплачен заказчиком и тоже искал. Через три месяца патч состоял из двух строк. Заказчик пытался возмущаться, конечно, но ему сразу предложили бери исходники и ищи сам или плати и жди фикса. То, что патч из двух строк — не моя вина, в коде их десятки миллионов и надо было найти нужные две.

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

Передачу аудио и работу с фалами. Пока будешь писать в файл, пропустишь пару аудио фреймов, или провтыкаешь обработать прерывание, которое плата прислала по ЮСБ, и телефон не покажет номер звонящего, потому что буфер под номер на плате размером 8 цифр, и его надо пополнять, когда он 7 цифр отослал.
Короче, софт реалтайм в свитчи не умеет.

Сейчас в юзерспейсе ДМА, кажется, не реализуешь. Да и очень спорный какой-то ДМА между ЮСБ и сокетом, с разворачиванием заголовков одного пакета и наворачиванием заголовков другого.

для софт реалтайма с jitter buffer оно ок, но файлы в том же потоке не попишешь, и телефонную книгу не посортируешь. Пакеты по 10 или 20 мс аудио + несколько разговоров одновременно.

но файлы в том же потоке не попишешь,

Это почему вдруг? На девайсе есть ОСь? Асинхронное i/o не завезли?

Линух. Асинхронное не пробовал — проще отдельный поток. Сортировать телефонную книгу или историю звонков тоже можно по кускам, но это все — изврат.

Ну зачем делать сложно то, что можно сделать просто. Сложности дофига в бизнес-логике (вон соседние растаманы даже стандарт читать не стали). Засовывать себе палки куда не надо еще и искусственной однопоточностью — ну нафига?

Если в железке один процессор/ядро — то это многопоточность там искусственная, а не наоборот :)

Есть несколько достаточно независимых задач, производимых одновременно:
1) передача аудио
2) логика управления системой
3) работа с файлами и сортировка данных
Докажи, что многопоточность искусственная.

В данном случае многопоточность ничем не отличается от многозадачности, т.е. все должны работать под DOS’ом с GUI? Ибо многозадачность такая же искусственная. Ты просто отождествляешь понятия многопоточности и многозадачности с параллельностью выполнения кода, а это понятия хоть и не ортогональные, но и не рядом лежать.

Вот как ее правильно решить, чтобы посчиталось быстро?

Наверное нужно немного отойти от классического программирования а ля Basic-style. В качестве элементарного примера рассмотри комбо-операцию Multiply-Add: en.wikipedia.org/...​iply—accumulate_operation . Ничего не мешает сделать сначала умножение, потом сложение, но комбо-операция будет где-то в 1.5 быстрее, тем более, что большинство операций умножения заканчиваются сложением, как, например, в расчёте приведенной тобой норме. Теперь, если ты поднимешься на пару уровней абстракции выше, то что тебе мешает во время вычисления твоих тензоров проводить операцию подсчёта нормы, ведь конечный результат ты всё равно сохраняешь в матрицу, вот и сохраняй промежуточные суммы перед сохранением в матрицу результата, потом просуммируй полученные суммы из всех потоков, в результате норму ты получишь почти бесплатно.

Но это жесть решение для сложения всех элементов массива.

Ты просто не привык. Я раньше давал подобные задачки на собеседовании (только проще, а ля multiply-add), которые жёстко отсеивали математиков и вайтишников от труъ программеров. Научись думать как процессор, вникни в суть происходящих процессов, стань процессором! © почти сержант американской армии. Просто математики не умеют в параллелизм, так их учат.

Пока же от тебя только понты.

Витя, иди броди в своих чащах.

У тебя есть вычислительный грид, допустим 8×512, если нет ручного управления гридами, то обычно среда предоставляет размерность сетки. Это значит что ты в 8 потоков будешь считать по 512 элементов. В каждом кернеле у тебя есть атомарная переменная SUM — сумма, при подсчёте каждого из 512 элемента ты делаешь SUM=MADD (E[x], SUM), в конце работы какдого из 8 кернелов у тебя будет 8 переменных SUM, которые нужно просуммировать и вычислить квадратный корень, что и будет твоей нормой.

Бедненький, ничего не сказал, никого не обвинил, а теперь играешь обиженку.

Я в низкоуровневых штуках не понимаю но в чем проблема?
На каждое ядро одна операция за один такт(может и не один)

Я когда-то читал на хабре, было очень интересно, но нифига не понятно — как я понял GPU разделен на блоки по сколько-то там ядер.
Допустим у нас есть гпу в котором есть 3 блока по 5 ядер.
Нам нужно посчитать сумму массива из допустим 8 элементов
В такой ситуации задействуются первые 2 блока
допустим в первый блок мы кормим 5 элементов,во второй блок мы кормим оставшиеся 3 элемента (оно так будет загружатся, или разобьет пополам по 4 элемента на блок?) в этот же момент третий блок остается свободный и может считать что то отличное от сложения или он вхолостую посчитает что-то или он просто будет неактивным?
и после первого такого сложения у нас уже есть массив из 4х элементов — мы можем его уже посчитать на одном блоке, опять же что в это время будут делать 2 других блока?

Есть трюк чуть ускорить и выстроить их в цепочку не m*n*k, а log(m*n*k).

А вот интересно, если тебе дать задачу сделать memset() операцию на 16 ядрах на участке в 1Gb RAM. Какой код ты напишешь?

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

Я тебе написал решение: подсчитываешь сразу сумму во время вычитания двух тензоров. Ты в упор делаешь вид, что его не видишь его и начинаешь выдавать мне какие-то «сферические» правильные решения, которых быть не может априори, есть оптимизация конкретной задачи.

Витя, мне больше делать нехер, как писать за тебя код — приведи код вычитания двух твоих тензоров, я покажу тебе что нужно делать. Код подсчёты нормы не нужно.

Так я увижу решение это задачи от супеп-пупер-нинзя-гуру на CUDA или OpenCL?

Ты очень упорот. Я тебе пытаюсь объяснить что тебе не нужно решать эту задачу, её можно добавить как субчасть при вычислении разницы двух тензоров. Где ты всё равно имеешь доступ к элементам матрицы. А ты пытаешься оптимизировать задачу, которая порождена неоптимизированным алгоритмом.

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

Заводишь локальную переменную interim_sum типа register float interim_sum = 0.0;

....
    for (int i = index; i < n; i += stride) {
        y[i] = x[i] - y[i];
        interim_sum += y[i] * y[i];
    }
    atomicAdd(&global_sum, interim_sum);
}

В global_sum по окончанию выполнения всех кернелов у тебя будет сумма квадратов всех элементов. Достаёшь её процессором и вычисляешь корень.

И все ядра выстроились в цепочку. О чем я выше писал.

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

Я не знаю, какая встроенная видяшка в моем ноуте)

И все ядра выстроились в цепочку. О чем я выше писал.

Объясни где ты там увидел цепочку? Она есть только в месте atomicAdd, но она per invocation, их должно быть немного, либо контроллируй размеры сетки сам.

А к твоему коды еще нужно запрашивать, что там на конкретном GPU с блоками, ядрами и правильно задать все размеры.

Зачем? У тебя есть вычисление y[i], ты просто его используешь повторно для суммы квадратов.

Но как только начал суммирование, то вся скорость GPU сдохла.

С какого хрена, прости, мой французский?

но стоит появиться хоть одной операции с барьером и GPU сразу сливает по полной.

Так выноси барьеры за циклы! Тем более atomic не полный барьер.

Заточи под свою архитектуру:
devblogs.nvidia.com/...​g-shared-atomics-maxwell

Вот про регистры я ничего толком не знал на GPU.

Регистр говорит лишь о том, что тебе не надо это число в памяти, и то, что тебе пофиг, где оно находится, если компилятор для GPU сможет всё время держать его в регистре, то будет очень быстро.

Ты говоришь про библиотечный вызов? Ну я хз что они там написали, я тебе говорю про голый код. Я просто иногда балуюсь своим рейтрейсером, добавил radiosity ( en.wikipedia.org/...​osity_(computer_graphics ) для мягких теней, FPS упали со 100 для FullHD до 98 на мобильном Atom CPU от Intel. А там далеко не только суммирование, там дохерища вычислений.

Да, это их либа и не думаю, что ты сильно квалифицированнее разрабов на нвидии.

Бугага! Если учесть то, чем я занимаюсь и то, что как минимум двое моих бывших коллег, которые доводили своими решениями меня до прединфарктного состояния, сейчас работают в nVidia, то могу сказать, что ты не прав на 200%. Но это оставим на твоей совести.

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

Ну расскажи, какие драйвера к подобному железу пишут в постсовке.

Писали и очень много (тебе, конечно, не доложили!), но если не настолько туп, как пытаешься тут показаться, то у тебя хватит ума понять, почему люди уезжают — потому что нет работы тут.

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

И как оно живётся с такими тараканами, что ты каждого, кто что-то умеет делать обвиняешь в ЧСВ и понтах?

Раз уже пошла такая пьянка, то хочу сказать, что ты мудила редкостный, пришёл, чтобы спросить как сделать быстро, а вместо того чтобы разобраться в предложенном решении ты начал тыкать ссылками на какое-то «правильное» решение. Т.е. ты не за советом пришёл, а по-проверять? Отныне ты сразу будешь идти на йух с любыми вопросами.

Украинский программист самый программистый в мире.

Тебе обязательно нужно кого-то унижать, чтобы возвыситься и по другому ты существовать не можешь? Очень много украинских программистов работают в выше перечисленных компаниях не на пол ставки, потому что украинские, а на всю катушку, только потому что специалисты. Тебе так это тяжело вбить в свою голову?

Вот только почему то INTEL, NVIDIA, AМД — все пиндосские (как принято говорить у еще более восточных антиамериканцев).

И причём тут программисты к основанию полупроводниковых компаний?

надо DMA для этого задействовать!

DNA!

или ещё лучше, дёрнуть ресет на чипе памяти, и будет тебе memset() за O(1)

Лет 20 назад — да, сейчас это мегадырища, вся надежда на то, что питание было отключено и память получила частичное повреждение. Но кого волнуют такие мелочи %)

у вас там в куде штоле sub group operations не завезли?

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

Но как только тебе понадобилось сложить все чти числа

все потоки в саб группе дружно делают subgroupAdd и записывают результат в output буфер согласно gl_SubgroupID

потом все это повторить пока у тебя не останется одна сабгруппа с одним итоговым результатом

Ну так GPU и есть эта «переработка» архитектуры в сторону паралельности.
А дальше будут другие компромисы, типа Xylix чипов или нейро-сетевых специализаций(вроде гугловского чипа).
Возможно, когдато весь x86 станет отдельным контроллером и основа будет как GPU, но это точно не в ближайшее время.

Embedded Tech Lead

остановите эту Землю, я сойду

Ну смотри.
Развивались процы по частоте. Потом уперлись в потолок. Что сделали — начали плодить ядра. Ну пришлось слегка попереписывать часть софта для поддержки многопоточности.
Сейчас плодится количество ядер, но тоже скоро может быть потолок. Какой следующий шаг? NUMA. Тоже надо будет попереписывать, методика уже понятна — давно делают распределенные системы в энтерпрайзе.
Твои пред(по)ложения?

а куда его девают последние лет 15? Вот туда же и девать.

www.karlrupp.net/...​icroprocessor-trend-data
перелом по частоте и производительности в 2005 видишь?
куда его девают?

то, что процики делают многоядерными, совсем не значит, что софт на них начинает быстрее работать, может быть и наоборот

А до этого стало невозможно поюзать всю мощность системы в классическом однопоточном приложении. Пережили.

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

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

Пиши на Джаве и будет тебе счастье

— Простите, я потерял сынишку в вашем торговом центре. Можно сделаю объявление по радио?
— Конечно.
Наклоняется к микрофону:
— Я пишу на джаве.

Сорян, але ще поки не у всіх стоїть по терабайту оперативи.

А Java ME и не знает, что ей терабайт оперативы нужен!

Java ME не знает, что она уже 10 лет как сдохла.

И что, Java за 10 лет стала прожорливее? Или -Xmx отменили? Наоборот — над производительностью работают, GC совершенствуется.

Поддержка Java ME встречается даже в относительно недавних китайфонах, например, LEXAND A2 Flip и Allview H3 Join. Приложений новых не от энтузиастов нету, да; многие, тем не менее, развивались вплоть до середины 10-х: Opera Mini, UC Browser, разнообразные игры от Gameloft. Так что цифра малость завышена.

Було б добре, та тоді треба відмовитись від PHP, Ruby, Python і JS, та почати розробляти на C++, C, Rust

А відмовитись буде неможливо

Так і бачу інтеграційний проект з купою rest та xml-ws, що написано на C.
І замовник такий: «Вау, лише в 12 разів дорожче, та ще й лише в 17 разів довше. Але ж працює в 3 рази швидше. І пам’яті на 1к баксів можна менше використати!»

Щось дуже в крайність)

Та нет, не особо. Еще и эстимейты занизил.

Можно на Go писать, он быстрее чем java (незначительно), python, ruby.

Зараз почнеться)

А можно писать на cython и шатать тот го на чем свет стоит, ну или в крайнем случае PyO3 и не отказываться от удобства в пользу сомнительной скорости и явного неудобства.

он быстрее чем java (незначительно)

Но неудобнее. Значительно.

Так і бачу інтеграційний проект з купою rest та xml-ws, що написано на C.

а что такого

І пам’яті на 1к баксів можна менше використати!

Сабж станет реальностью, лишь когда (и если) инвестиции в железо станут дороже труда низкоуровневых программистов.

А пока что тенденция обратная, уже даже в микроконтроллеры JS пихают.

Кстати интересно, на сколько порядков возрастет «гаунность» кода написанного на С и ++ после того, как все начнут на них писать и не дешевле ли будет делать мультипроцессорные системы, чем переписывать по 10 раз?

А чем тебе поможет С если например ORM делает дико неоптимальный запрос?

например ORM делает дико неоптимальный запрос?

А если VM делает дико неоптимальные вычисления?) Какая будет реальная вычисл. сложность банального перебора массива на ruby в сравнении с, например, c/c++?

А является ли это боттлнеком? Разве что в какой-то сугубо вычислительной задаче, когда нету баз, сетевых вызовов и прочих тормозных штук.

Ты что? Какая ORM? рост мощностей замедлился!!!! алярм, ахтунг какие могут быть прослойки вообще? исключительно чистый sql хотя его же нужно парсить да и сервер бд иметь — это все в мусорку, нужно напрямую читать файл с диска,а пользователь пускай на своей стороне богомерзким джаваскриптом уже обработает.

SQL запросы будут транслироваться в машинный код на этапе конпеляции проекта :)

берите круче, эпоха ИИ на подходе.

во время компиляции проекта будет собираться сервер БД оптимизированный под описанные запросы.
причем, с кодом, который на основе статистики реальной работы, будет пересобирать сервер БД.
JIT компилятор в JVM же так уже делает. Немножко, не всегда, но может.

Дело за малым — расширение применения этого подхода

Что означает — думать об оптимизациях вообще не будет иметь смысла.

Это у автора статьи

Way back in the 1960s,

а надо мыслить о 2060s

а дальше, еще интерсенее — писать код вообще не придется.
а только спецификации, ТЗ, и прочую литературу.
ИИ сам сгенерит, скомплирует, перекомпилирует, ...
А если ему будет непонятно, то еще и переспросит — у вас в спецификации на странице 15 написано вот это, а странице 96 — вот это. и эти вещи логически несовместимы. Предлагаю варианты: ...

Так что автор статьи — просто ностальгирует по прошлому.

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

Підписатись на коментарі