LINUX.ORG.RU

Использование машинных инструкций ИИ в ядре Linux

 , , ,


0

2

Не так давно прочёл новость, что в Intel с 14го поколения будет аппаратное ускорение в виде инструкций ассемблера для работы с ИИ. Вопрос, в ядре линукс как-то это планируется использовать или нет?

★★★★★
Ответ на: комментарий от mittorn

Ну вот раньше тоже так думал про AVX512, но вот тут висела новость недавняя, что их уже применяют вовсю для шифрования.

Infra_HDC ★★★★★
() автор топика
Последнее исправление: Infra_HDC (всего исправлений: 1)

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

cobold ★★★★★
()
Ответ на: комментарий от Infra_HDC

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

bomjevik
()
Ответ на: комментарий от bomjevik

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

Infra_HDC ★★★★★
() автор топика
Ответ на: комментарий от bomjevik

Думается, ИИ лучше человека асемблером и сишкой владеет

ИИ владеет сишкой и ассемблером на уровне среднестатистического программиста, чей код есть на гитхабе.

ya-betmen ★★★★★
()
Ответ на: комментарий от mord0d

/me придумал! \ё/

ИИ в ядре будет заниматься портированием драйверов прямо на лету! Ты ему просто подсовываешь даташит или виндовый драйвер и он сам на лету создаёт и задействует линуксовый драйвер! Более того, если что-то перестало работать или работает криво, то пользователь просто сообщает об этом ИИ и он фиксит баги прямо не отходя от кассы! Тогда венде точно капец!

u5er ★★
()
Ответ на: комментарий от u5er

Тогда венде точно капец!

А в итоге получится так, что кроме Microsoft это вообще никто не реализовал. (% Потому что у Apple это всё давно есть, а больше никому и не нужно.

mord0d ★★★★★
()
Ответ на: комментарий от bomjevik

Попросил я как-то сгенерить мне решение на ассемблере. Оно понапридумывало кучу несуществующих инструкций и написало какую-то ересь.

А для С оно просто подставляет первый ответ со SO, плюя на то что он неправильный в 90% случаев.

PPP328 ★★★★★
()

аппаратное ускорение в виде инструкций ассемблера для работы с ИИ

Раз 10 перечитал, но так и не понял, что это значит. Я вот сделал себе аппаратное ускорение в виде инструкций ассемблера для работы своей программы - написал её.

PhD
()
Ответ на: комментарий от PPP328

Ну так ты наверное что-то общедоступное типа ЧатГПТ использовал.

А в жизни скорее всего какая-нибудь галера, которая массово (это ключевое слово) клепает сайты, возьмёт открытые наработки, натренирует их на своём коде и будет пользоваться. В открытый доступ она, разумеется, ничего не выложит.

И да, как это можно использовать для опенсорсного программирования, я не представляю. Скорее всего, паразитизм просто победит.

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

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

И получит те же самые галлюцинации, потому что это не думающий AGI, а Т9 на стероидах

PPP328 ★★★★★
()
Ответ на: комментарий от PPP328

Есть гипотеза, что стероиды, к сожалению, решают.

Классический T9 на мобильниках работал в условиях ограниченных ресурсов. А это для любой нейросетки и смежных технологий практически всегда означает «работать плохо».

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

Если у галерщиков всё пойдёт по плану, останутся «джи» — те, кто учит нейросети (но их много не надо), и те, кто пишет движки (этих нужно ещё намного меньше).

Капитализм.

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

и тестирование ИИ-продукции всё равно придётся поручать кожаным мешкам

А что в тестировании такого интеллектуального? Понять, что что-то пошло не так вроде как проще, чем накидывать кода на-гора.

red75prim ★★★
()
Ответ на: комментарий от vbcnthfkmnth123

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

peregrine ★★★★★
()
Ответ на: комментарий от hobbit

Там если что в студии специализированное решение от мелкомягких есть, отличается буйной фантазией, т.е. правильно пишет где-то 1/3 и то если код ну прямо шаблонно тупой. Шаг вправо, шаг влево и нифига не работает.

peregrine ★★★★★
()
Ответ на: комментарий от hobbit

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

peregrine ★★★★★
()
Ответ на: комментарий от peregrine

Можно будет запилить умный планировщик на ИИ

Эххх. ИИ он жрет для работы процессор(и тогда работает медленно) и оперативку либо видеокарту(и тогда работает быстро) и видеопамять. Если у тебя процесс выжрал кучу памяти, то работа ИИ на процессоре у тебя систему окончательно подвесить, и это в том случае, если у тебя хватило памяти для ИИ. Если нет, то просто выдаст ошибку и ничего не сделает с этим подвисшим процессом. А учитывая что ИИ на процессоре медленно работает, то учитывая это он может не успеть отреагировать до того система рухнет.

Если же на видеокарте он будет выполнятся то это все будет работать и быстро, но потребуются ресурсы видеокарты и не маленькие.

Это я так навскидку говорю

vbcnthfkmnth123 ★★★★★
()
Ответ на: комментарий от vbcnthfkmnth123

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

и оперативку

готов отрезать от 64 гигов моей оперативки 4 гига под нужды системного ИИ.

peregrine ★★★★★
()
Последнее исправление: peregrine (всего исправлений: 2)

Там отдельный чип, а не новая процессорная инструкция. Можно задать встречный вопрос использует ли ядро GPU инструкции? Кажется нет, а ведь GPU гораздо ближе к обычным процессорам чем NPU асики.

LINUX-ORG-RU ★★★★★
()
Ответ на: комментарий от peregrine

готов отрезать от 64 гигов моей оперативки 4 гига под нужды системного ИИ

Оххх. 4 гига это ничто для ИИ. Готовь сразу 12 гига как минимум. А лучше 48 гига или больше, если хочешь хорошего результата.

vbcnthfkmnth123 ★★★★★
()
Ответ на: комментарий от vbcnthfkmnth123

Планировщику много не надо. Тут глубокого обучения не требуется. Нейронка из 9 нейронов которая умеет решать задачу про ирисы фишера и с ooom киллером справится. Там логика очень простая на самом деле кого убивать. Беда в том что в ядре планировщик совсем обезьянка делала, которая не думала про то что убивать надо самого вероятного виновника у которого вполне явные характеристики, а сначала надо ну кисонька, ну ещё капельку, если 1 процесс кушает 100% процессора и отожрал 95% всей оперативки, то вот если 1% оперативки освободтить то ему конечно хватит, он же не просто так 100% процессора кушает, видимо очень важную задачу выполняет, нельзя его убивать, лучше грохнем сначала процессы которые на процессоре мало ресурсов жрут, они наверное не так важны...

peregrine ★★★★★
()
Ответ на: комментарий от anonymous

Ладно, спасибо. Глянул, это комбинация из умножения пар 16битных интов (или обрубков float наверное, для вариации инструкции) и последующего их сложения в 32битный аккумулятор. Достигается комбинацией двух уже существующих SIMD инструкций. Инновация что обосраться, да я обделался по поводу факта существования, ты победил. Но всё равно фигня какая-то. Эх, ладно.

LINUX-ORG-RU ★★★★★
()