ИИ лажает там где должен был сиять

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

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

Программирование, говорите? Ну хорошо, вот три мои попытки оправдать ИИ на задачах из программирования.

Попытка оправдать ИИ номер 1. Что может быть софтовее чем AWK?

Мне на работе нужно было словить баг в подсистеме GPU, работающей на эмуляторе Synopsys ZeBu. Я сделал экстракт сигналов и после цепочки превращений получил текстовый файл в формате .csv, то бишь просто числа разделенные запятыми. На миллионы миллионы строк:

Время,координата-X,координата-Y 100,17,15 101,3,14 ....

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

Самый традиционный способ обработки файлов с колонками - это AWK, стандартная программа в юниксах, линуксах и прочих BSD с 1970-х годов. Что может быть более софтовым чем AWK?

Но даже тут ИИ умудрился налажать. Он выдал скрипт, который на моем файле надолго задумался. "Что такое?" - подумал я и прервал вычисление с помощью Control-C.

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

Для тех кто не сталкивался с AWK: массивы в нем динамические, растягиваются при использовании новых индексов.

Для тех кто не понял про квадратичное время: Нормальный человек определяет границы изображения одним из двух способов: или расширяя min/max после каждой обработанной строчки на основе координат в ней, или делая проход через массив после ввода всех строчек. Это делается за время O(n строк в файле). ИИ придумал обходить весь массив после каждой строчки, что требует O(n²).

#!/usr/bin/awk -f # ... пропущенный код { x = $5 y = $6 # ... пропущенный код for (i in A) { split(i, t, SUBSEP) if (t[1] < minx) minx = t[1] if (t[1] > maxx) maxx = t[1] if (t[2] < miny) miny = t[2] if (t[2] > maxy) maxy = t[2] } } END { for (yy = maxy; yy >= miny; yy--) { for (xx = minx; xx <= maxx; xx++) { printf "%d ", (A[xx][yy] ? 1 : 0) } printf "\n" } }

Попытка оправдать ИИ номер 2. Что может быть проще для ИИ в Embedded, чем Linker скрипты?

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

При этом линкер скрипты хорошо описаны в документации GCC и LLVM, для них есть тонны примеров на гитхабе. Казалось бы - идеальная область для применения ИИ.

И вот я попросил ИИ сгенерировать для меня линкер скрипт для компиляции примеров на Си для учебного RISC-V процессорика, синтезированного в FPGA для семинаров в Индии.

ИИ нагенерил мне скрипт с описаниями что в нем происходит, и я думал "ну вот, нашел полезное применее для ИИ". Пока ИИ не ляпнул реплику, из которой следует, что он считает, что BRAM (Block RAM в FPGA) - это якобы ROM (Read Only Memory). Ну и как после этого верить всему остальному выплюнутому ИИ тексту?

Попытка оправдать ИИ номер 3. Вранье, большое вранье и микрокалькуляторы

Я отношусь к поколению советских людей, которые научились программировать с помощью программируемых микрокалькуляторов MK-54 и их родственников: MK-52, MK-61, Б3-34 и Б3-21. В них был стек операндов с глубиной 4, память для сотни инструкций, 16 адресуемых регистров, косвенная адресация, условные переходы, команды для организации циклов и даже вызова подпрограмм с возвратом из них (стек на 5? адресов возврата).

Короче ассемблер на коленке, причем в прямом смысле: я держал это чудо на коленях в 1984 году, когда ехал на скоростном трамвае из Южной Борщаговки в физматшколу номер 145 города Киева.

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

Сначала ИИ начал писать программу не для МК-54, а для Texas Instruments-58. А при попытке призвать к порядку оно начало клеветать на советский строй, утверждая что якобы МК-54 не поддерживает условных переходов:

Я был так потрясен, что даже скачал из интернета инструкцию по МК-54, чтобы удостовериться, что я не сошел с ума:

В нем даже косвенные условные переходы есть:

Потом ИИ окончательно заврался что в МК-54 было якобы всего ... 16 шагов для программ:

Господа! Я конечно не ожидаю, что ИИ будут тренировать на журналах "Наука и Жизнь" середины 1980-х годов, а также не считаю данное устройство вершиной технологической мысли данного периода. Но почему ИИ не может сказать "НЕ ЗНАЮ!!!"??? Когда ликвидируют этот дефект?