Автор Nuxt.JS вперше в Україні на конференції JavaScript fwdays | 14 березня, Київ
×Закрыть

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

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

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

LinkedIn

Лучшие комментарии пропустить

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

Допустимые теги: 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 даже для скриптовых языков даёт сильное ускорение где оно нужно.

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

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

Якби ж то!

Можливо незабаром людське життя буде подовжено і всі встигнуть стати тру сеньйорами? www.livescience.com/...​nded-five-fold-aging.html

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

Наразі маємо проблеми з нервовою системою та психікою при збільшенні віку людини.

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

Генетично сповільнені сіньори можуть виявитись недостатньо працьовитими.

Чому?

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

Якщо голоду не відчувається то в чому проблема? І таки про збільшення молодості, бо клітини переходять в режим відновлення а не ділення пошвидше, один фіг розплід організмів рішить. Це як зміна еволюційної програми від копіювання до егоїстичного збереження. Розплід був нам корисний раніше коли воювали за домінування. Тепер воно лише заважає.

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

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

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

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

Якась зрада. Ніде в статях не зустрічав що може погіршувати мислення отаке голодування.

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

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

Можливо тут стисло:

www.leafscience.org/...​w-with-dr-david-sinclair

Він СЕО власної компанії, тому може перебільшує аби інвестиції підняти. Є й інші компанії які свій метод пробують.

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

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 лет назад ещё читать не умел %)

О, мій фанат Майк. Ні, я не настільки юний)

Хоча якщо читати англійською, то в точку)

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

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

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

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

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

Вот и об этом тоже. Сейчас основной тормоз не технологии процов, а то, что архитектура просто не позволяет их полностью юзать.
Пример со сложением я специально привел. Мы имеем отличный массовый параллелизм и море гемора, если не он. Там есть тупой путь через блокировки — в итоге все ядра выстраиваются в цепочку и все очень и очень медленно будет. Его оптимизируют сводя с O(N) до O(logN) и код становится нетривиальным для тривиального сложения.

И там и там (CPU и GPU) пачка кешей, и там и там конвейеры. В результате все чем комп занимается — это все синхронизирует и пересылает туда сюда и 1% времени делает требуемое.

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

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

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

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

Та уже смесь везде
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
Майка надо пригласить.

Существуют гибридные архитектуры, сочетающие достоинства как гарвардской, так и фон-неймановской архитектур. Современные CISC-процессоры обладают раздельной кэш-памятью 1-го уровня для команд и данных, что позволяет им за один рабочий такт получать одновременно и команду, и данные для её выполнения. То есть процессорное ядро аппаратно гарвардское, но программно оно фон-неймановское, что упрощает написание программ. Обычно в данных процессорах одна шина используется и для передачи команд, и для передачи данных, что схемотехнически упрощает систему. Современные варианты таких процессоров могут иногда содержать встроенные контроллеры сразу нескольких разнотипных шин для работы с различными типами памяти — например, DDR RAM и Flash. Тем не менее, и в этом случае шины, как правило, используются и для передачи команд, и для передачи данных без разделения, что делает данные процессоры ещё более близкими к фон-неймановской архитектуре при сохранении достоинств гарвардской архитектуры.

По сути пошли по пути скрешивания бульдога с носорогом, а потом добавления к ним кенгуру. Такие химеры не жизнеспособны.
Создать-то можно, но она издохнет и быстро.
Если же смотреть на фоннеймановскую и гарвардскую по отдельности, то сами по себе каждая из них лаконичны, просты и удобны. Гибрид-химера уже сейчас монстр полуживой.

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

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

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

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

И если кто-то в этот момент громко крикнет тебе на ухо «Приятного аппетита», то зависнешь.

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

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

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

В этот твоей деятельности на 99% работает спинной мозг и мозг кишечника, а не головной и они друг другу шлют сигналы только в исключительных ситуациях — суп оказался испорченным, суп оказался из говна, кто-то крикнул тебе на ухо «приятного аппетита», стул оказался железным и по нему пустили ток, в супе купается живой такракан и подобные.

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

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

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

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

Вот тебе задачка: посчитай норму разности тензоров (3мерная матрица) изображения с маской или гистограмму.
И уже в этой задачке столкнешься с убогостью архитектуры компов, что в части CPU, что GPU.
Понятно можно просто вызвать ippiNormDiff_L2_8u_C1MR или nppiNormDiff_L2_8u_C1MR и расслабиться, а если чуть усложнить, то и начнется веселье у тебя.

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

sqrt(sum((A-B).^2))

Это норма Фробениуса, а не L2. Но часто норму Фробениуса называют L2. Есть между ними незначительные отличия, но не особо важные.

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

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 работает не его код, а библиотечная функция но тут он ССЗБ, так как занимается оптимизацией кирпичиков неоптимизированного алгоритма.

Уже не смешно.
Начнешь писать на CPU у тебя еще появиться момент с запуском потоков — они очень медленно запускают.
В итоге, самый быстрый вариант.
Разделить по строкам или столбцам, как оно в памяти лежит.
До этого стартовать пачку потоков и повесить их в ожидание, потом по мере поступления задач условными переменными запускать их — остальное время они будут стоять и ждать.
В обшем produser-consumer (как он там этот подход называется).
А уже сам код, что считает с учетом AVX сделать. GCC 8 уже научился, до него нужно было на асме писать.
И не забыть про выравнивание данных.

В итоге 3 строчки на С у тебя превращаются, превращаются в элегантную страницу две кода. И да этот код будет раз в 10 (зависит от количества ядер и поддержки векторных инструкций твоим CPU) или более быстрее простого однопоточного кода на С.

Еще может оказаться момент, что делить на блоки может оказаться хитро, чтобы с кешами все правильно разруливалось — но здесь для меня уже что-то дикое там в CPU нынче.
Посему и предпочитаю юзать IPP и MKL, если их хватает.

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

На С и С++ кода всегда меньше, чем на питоне почему-то.

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

А на питоне хуек -хуяк?
Импортов, часто странных, там тоже куча.

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

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

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

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

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

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

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

И тут пошла фантастика от жаваскриптеров. Нет, оно за тебя не думает и будет тормознуто и очень то, что ты написал. Но ядра загрузит все полностью (если не ограничишь). Проходил я это уже раз 100 с openmp.
Но эти либа и прагмы идеальны, когда нужно показать, вон какой сложный код мы написали, он все ядра на 100% загрузил и так долго считает. В реальности обычно в 1.5-2 раза быстрее на 8 ядрах, чем на одном с этой либой.
А вот если ручками с потоками разрулится, то можно получить и в 7.5 раза на 8 ядрах, против одного.
Но это очень много ручной работы и шаманства всегда.

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

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

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

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

OpenMP вполне съедобно для 9/10 всех задач, за разруление ручками тариф может быть и 10x.

Не съедобно, но для втюхивания годится, потому что типичный обман. Вон чуть быстрее и главное проц на 100% запахали.
Это как и с вебом. Инфы на сайтах уменьшилось, удобство жуткое, но для его отображения дайте суперкомпьютер. Съедовно? Нет. Но для втюхивания подходит.
Точно также, как в пальмовым маслом в коровьем масле. Съедобно? Нет. Но для втюхивания отлично.

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

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

Нет. Никто не рассказывает, что включив ключик в компиляторе они ускорили программу и это было очень сложно. Этот ключик сам при сборке релиза по дефолту часто подставляется и половина програмеров не в курсе его даже.
Мы же оптимизировали программу целым изучением openmp и его сложным встраиванием в программу и теперь она выжрала CPU на 100% — ОГОГО

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

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

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

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

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

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

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

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

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

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

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

Может и не прав.
Но когда они спят? Что-то я такого не замечал на PC.
Ну и второй вопрос Зачем они спящие в счетной задаче? Ждут, когда им доступ к памяти дадут?

Ну и напомню вопрос выше про

норму разности тензоров (3мерная матрица) изображения с маской

.
Вот как ее правильно решить, чтобы посчиталось быстро?
На GPU вычесть 2 тензора очень быстро. Посчитать норму очень медленно.
На CPU вычесть 2 тензора очень медленно. Посчитать норму в 2 раза быстрее.

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

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

Не все задачи счетные.

А я где-то такое утверждал?

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

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

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

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

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

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

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

ока будешь писать в файл, пропустишь пару аудио фреймов

И как мы в свое время справлялись на одноядерных процах с этим под виндами когда-то? Там ДМА был и организовывалась пачка буферов.
Про остальное не знаю.

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

Там со звуковой карточки звук брали. USB еще и не пахло.
USB — вообще странная хрень, особенно, когда от него реалтайм хотят.
Косвенно о его странности говорит то, что море железа, особенно на USB3 до сих пор с трудом работает. Вот эта хреновина только на USB2, а вот эта только с USB3. Причем ни там ни там скорость большая не нужна и USB2 хватает за глаза.
Но глубже юзания libusb я не совался, да и то раздражали libusb0.1 и libusb1.0. ну как у гэ-стримера.

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

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

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

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

Ну вы тут грамотные современные программисты с горчаком (что стоят в одиночку 4 програмеров на нвидии) — разгребайтесь сами.
Я слишком глуп и безрамотен в сравнении с вами.

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

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

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

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

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

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

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

Вот, Майк, правильный ответ riptutorial.com/...​e-g—how-to-sum-an-array
Но это жесть решение для сложения всех элементов массива.

Но, я могу ошибаться и если приведешь код приведешь код CUDA (OpenCL) кернела, то покажешь что я не прав, или прав.
Если там все просто, то ты за 3-5 мин его набросаешь.

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

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

Жду от тебя правильного решения, на которой ты, как спец потратишь 3-5 минут.
Пока же от тебя только понты.

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

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

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

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

И почему меня такой на русскоязычных форумах давно не удивляет.

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

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

Там массовый параллелизм. То есть все процессоры на куче данных в один момент времени выполняют одну операцию. Это круто и быстро.
Но как только тебе понадобилось сложить все чти числа, то ты должен повесить барьеры на запись и выстроить все процы в очередь выполнения. Итого в тупой реализации у тебя в последовательную цепочку выстроятся все m*n*k процессоров.
Есть трюк чуть ускорить и выстроить их в цепочку не m*n*k, а log(m*n*k). Но код у тебя станет очень сильно сложнее.

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

И вот представь насколько нетривиальный код получается в итоге.

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

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

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

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

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

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

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

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

sqrt(sum((A-B).^2))

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

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

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

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

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

__global__
void sub(int n, float *x, float *y)
{
  int index = blockIdx.x * blockDim.x + threadIdx.x;
  int stride = blockDim.x * gridDim.x;
  for (int i = index; i < n; i += stride)
    y[i] = x[i] - y[i];
}
devblogs.nvidia.com/...​easier-introduction-cuda

Заводишь локальную переменную 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 по окончанию выполнения всех кернелов у тебя будет сумма квадратов всех элементов. Достаёшь её процессором и вычисляешь корень.

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

i5-8600K на 4400 рвет 1080, как тузик грелку, где-то в 7 раз быстрее ippiNormDiff_L2_8u_C1MR чем nppiNormDiff_L2_8u_C1MR,
а если нужно считать чуть сложнее, чем такое простое, то там вообще несравнимо.

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

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

З.Ы. Но тем ни менее спасибо за направление, как такие вещи пишут на GPU. Вот про регистры я ничего толком не знал на GPU.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ну вот NVIDIA в npp не справилась с этой задачей.

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

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

И я специально сравнил достаточно неудобные функции, там еще и маска битовая (как uint8) подается на вход функции.

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

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

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

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

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

И да есть один постсовковый продукт, что юзают очень много в мире nginx.
И 100500 американских и западноевропейских.

ИТ здесь уже 20 лет и за эти 20 лет только деградация даже относительно совка.
Возьмем модную сейчас область ML — поле непаханное и все разработки и причем в опенсурсе снова америкосы и зап европейцы.
Ни одной либы от постсовков.

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

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

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

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

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

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

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

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

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

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

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

или ещё лучше, дёрнуть ресет на чипе памяти, и будет тебе 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 видишь?
куда его девают?

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

Развивались процы по частоте. Потом уперлись в потолок. Что сделали — начали плодить ядра.

Хуже. Прилепили кешей 100500 уровней и предсказывающие конвейры 100500 уровней.

А про NUMA с вики:

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

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

Пережили в том плане, что утилиты стали показывать его загрузку в 100%.
По сути одели шапочки из фольги и стали счастливы.

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

Ну тоесть уперлись в способности работников 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 блин уже пересобирает фактически логику в зависимости от его понимания запроса. Не, не физически, просто она основана на таблицах которые он поправляет.
Токо ж не всегда работает почемуто, иногда к еще большим фризам приводит.

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