Пикрандом.Сап двач, объясни мне чем так принципиально отличаются ARM и x86 архитектуры, что первая по сути используется только в мобилках и контроллерах, а вторая в нормальных компьютерах? Только не общими фразами: НУ ТИП ARM ЭТА RISC А ИЩО У НИХ TDP МЕНЬШЕ, а конкретнее: что есть в x86 такого, что его не заменяет ARM? Почему ARM-архитектура не получила распространение на компах/серверах? Ну или посоветуй материал, где про это почитать, можно на английском.
>>226996254 (OP)>Почему ARM-архитектура не получила распространение на компах/серверах?Слушай, я тоже не специалист, но полагаю, что дело в отсутствии поддержки специфически важных для ПК/серверов инструкций.Кстати, там вроде планируется скорое вторжение ARM на рынок серверного оборудования, что-то крутое придумали в плане железа.
>>226996446> Слушай, я тоже не специалист, но полагаю, что дело в отсутствии поддержки специфически важных для ПК/серверов инструкций.Вот мне бы хотелось от разбирающихся узнать хотя бы где узнавать, какие специфически важные инструкции есть в x86 и нет в ARM, потому что непонятно иначе нахуя этот x86 вообще нужен.> Кстати, там вроде планируется скорое вторжение ARM на рынок серверного оборудования, что-то крутое придумали в плане железа.Свежо предание, уже выпускали на ARM, но чет оно понадобилось только 1,5 гикам. Значит все-таки причины есть.
>>226996254 (OP)в arm меньше транзисторов чем у 86 (поэтому он маленький в размерах), и его железная логика работает медленнее
>>226996707> в arm меньше транзисторов чем у 86 (поэтому он маленький в размерах)Это понятно. > и его железная логика работает медленнееА вот это уже менее понятно. Чего именно не хватает? Векторных инструкций типа AVX? Насколько часто они используются и так ли это критично? Вроде же есть трансляторы с x86 на ARM, понятно что с костылями, но все же.
>>226996254 (OP)Различий масса, открывай спецификации, изучай матчасть. Тебе тут никто километры текста выдавливать не будет. Интересно - разбирайся самостоятельно, потому что тема слишком обширна, чтобы одним постом на дваче ее исчерпать.Удачи!
>>226997158Я понимаю, что одним постом все отличия никто не выдаст, поэтому и спросил у анона еще о том, где можно углубиться в эту тему, потому что мало ли есть годная литература, а я о ней не знаю.
>>226996254 (OP)>Сап двач, объясни мне чем так принципиально отличаются ARM и x86 архитектурыПод арм ни нормальных осей(винды) ни софта нету.
>>226997683Плюс линукс под АRM точно работает (даже для домашнего использования есть малиночка), а сервера в основном на линуксе, но тем не менее на них все равно используют x86 архитектуру.
>>226998141Чтоб понять отличие, возьми обычный нож и мультитул швейцарскийОбычный нож (арм) охуенно режет, но кроме как резать мало что им можно сдеать. Можно как-то изъебнуться и открыть им пиво, но то такоеШвейцарский нож как нож хуже, зато им можно суп съесть, бутылку открыть, пробку вынуть, котлету вилкой съесть и шуруп выкрутить
>>226998141Так это меня интересует: ARM архитектура менее энергозатратна и может показывать хорошее быстродействие, однако же для серьезных задач используют в основном x86. Не могут же все просто взять и делать хуйню, значит у этого есть причины, которые мне непонятны.
>>226998244быстродействие железяки ничего не значит нынче - важнее быстродействие писания под нее программСейчас конечно уже разницы нет под что писать, но еще 10 лет назад под x86 у тебя была ос, тулинг, инструменты, библиотеки и наработки, на основе которых ты и лепил свои конструкторыПод арм не было нихуя, и толку если он был бы на 20% быстрее, если тебе нужно было бы на решение одной и той же задачи 2000% больше времени тратить чтоб накодить
>>226998215И как часто в повседневной жизни нужен мультитул? Apple например хочет перевести свои компьютеры с х86-64 на ARM, судя по всему следующие маки будут на них. Почему они так отказываются от мультитула?
>>226998244Бля, да ты уже сам в своём вопросе ответил.Просто для задач уровня мобильного телефона достаточно ARM, батарейка держит дольше, супер-производительность тут особо и не нужна.Это не хуйню придумали, а вполне адекватное решение. Сейчас вот эпл вообще макбуки на ARM будет переводить, к примеру. Тогда батарейка мака будет держать не 7-8 часов, а все 15.
>>226998385Основная популярность x86 нынче - это не какие-то объективные плюсы данной архитектуры, а инерция и легаси код?
>>226998141Правда он не сможет в равную частоту она, внезапно, зависит от архитектуры, но армофилов это мало волнует.
>>226998500Если под легаси кодом ты понимаешь объем написаных под него библиотек и софта - то это блять и есть самый важный и объективный плюс
Наконец-то годный тред. Касательно ARM сам мало знаю, но во время развития ПК, упор делался на чистоту, в чем arm до сих пор проигрывает.
>>226998488> макбуки на ARM будет переводить, к примеруНо макбук - это уже не телефон с развлекаловками, макось изначально вероятно была нацелена на профессиональную работу, и раз эпл переводит все под ARM, значит стоит предположить, что ARM может справляться и с профессиональными задачами. Тогда в чем прикол x86 сейчас, в данный момент времени, если они сосут по энергозатратам, а производительность уже плюс-минус схожая?
>>226996254 (OP)ARM и x86-64 оба RISC. АRM хорош в мобильных устройствах с низким энергопотреблением.x86-64 в стационарных ПК где важна высокая производительность.
>>226996254 (OP)Под ARM свой софт нужен, отдельный, другой. Ну или адаптированный. За x86 тянется многолетняя история поддержки обратной совместимости, как след от говна. Но это старое говно многие использовали в своих программах, поэтому, собственно, и продолжали эту традицию обратной совместимости. В последнее время было несколько итераций отказа от целого пласта старого говна, поэтому сейчас переход произвести уже легче.
>>226998500> Основная популярность x86 нынче - это не какие-то объективные плюсы данной архитектуры, а инерция и легаси код?В принципе, да. Если арм сделать на нормальной частоте 4+ ГГц, то будет профитнее хуй86. Просто пока арм на нормальных частотах умеет делать только Эппл. хуй86капец близок, брат.
>>226998244Мы не знаем, может ли. Секундные тесты в geekbench - это не тесты, потому что одну секунду можно бустить, не перегреваясь.УA64FX, который супер, только фронт приделан к ARM ISA, всё остальное у фуджитсу свои наработки со времён спарков со специальными допиливаниями под супер.Сделают Apple комперы со своим процессором, на которых можно будет запустить взрослые задачи - тогда и узнаем.А пока что они запрещают публиковать бенчи со своих девкитов. С чего бы стесняться, если производительность там огого?
>>226998500х86 просто так уже не уйдет. Под него написана просто тонна софта и большинство из него уже не поддерживается, а аналогов как бы нет. Майки эту проблему думают решать программным транслятором х86 в ARM, но вопросы производительности ещё остаются открыты.
>>226998574И насколько хуево справляются с поддержкой тех же библиотек интерпретируемые языки программирования? Сейчас же все больше пишут на тех языках, где принцип "написал один раз - запустил на любой платформе", а не ассамблере пишут очередную говнойобу.
>>226998775в x86 RISC ядро начиная с Pentium Pro, а инструкции CISC.Это кстати хорошо, иначе бы программы HelloWorld на Си весили по 10 мегабайт в RISC инструкциях
>>226998830питонист и жабаскриптник, плес. ты-то чего страдаешь про производительность. раз ты взялся за 2 эти недоязыка, тебя она вообще не волнует.
>>226998830>"написал один раз - запустил на любой платформе"да. и делается это за счет огромных библиотек на всех платформах, а не за счет самих программ.
>>226998651>Тогда в чем прикол x86 сейчас, в данный момент времени, если они сосут по энергозатратам, а производительность уже плюс-минус схожая? она ни разу не схожая.в специфике разница вообще колоссальная.
>>226998911Я вообще не программист, и для себя изучаю лишь кресты. Но один хуй сейчас пишут в основном на питоне/джаве/js и этого хватает для большинства приложений, что всех насильно на си перетаскивать?
>>226996254 (OP)Основное отличие в способе выпонения инструкций. В контроллерах выполняются на аппаратном уровне базовой логикой. В процессорах общего назначения на микропрограмном уровне. Это упрощённо.
>>226998894Все хорошо, только вот наоборот. С этого самого пентиум про риск юзается внутри проца, т.е. большие инструкции делятся на меньшие.
>>226998651>Тогда в чем прикол x86 сейчас, в данный момент времени, если они сосут по энергозатратам, а производительность уже плюс-минус схожая?Прикол в производительности. ARM ноутбуки есть, но это издевательство над пользователем, они более тормозные чем на Intel Atom. Там только линукс реально использовать, больше они ничего не тянут.
>>226999020Нет, конечно. Но ты сознательно отказался от быстродействия в пользу других удобств. Для тебя разницы между ARM и x86 действительно вообще никакой.
>>226996962Любая трансляция x86 ->arm - это очень медленно Т.е при виртуализации x-86 машин на arm накладные расходы очень большие.Вот у amd есть аппаратная виртуализация amd-v. У intel тоже своя технология. И это позволяет создавать несколько виртуальных машин x86 на одном сервере практически без накладных расходов.Когда вот та же 1с-ка будет запускаться на arm пусть даже с виртуализацией, но с минимальными расходами и какой нибудь 20-ядерный сервер arm будет стоить меньше 100к,только тогда это все пойдет в продакшн. Потому что будет выгодно! И востребовано.X-86-64 - Это стандарт де-факто. Большинство софта разработано и скомпилировано с учетом этой архитектуры. И начало этому положено еще с 80 годов.
>>226998412батарея. Оно будет на руке жить дольше, и всё. Там все равно их будут для двачевания и набирания текстов брать, а не для сложной работы
>>226996254 (OP)Допустим есть задача сложить 1+2+3+4+5+6+7+8+9Арм как сначала занесёт в память 1, потом 2, после чего сложит их. Результат сложение опять занесёт в память, после чего 3, снова сложит итд. х86 тупо нахуй сложит всё разом. С одной стороны у арм из за такой работы в принципе невозможны ошибок аля команда вызывает саму себя, но зато х86 мощнее.
>>226999160Ты блять людям объясни, что нахуй вы пишите на питоне и жаве, а потом 1Тб оперативки ваша хуйня живет, пересаживайтесь на си, здесь все заебись, будете свое говно для плеймаркета на нем писать.
>>226996254 (OP)Существует три возможных ответа. Ни один из них, разумеется, не имеет ничего общего с производительностью.Наиболее оффициальный: технологическая инерция. Под x86/amd64 накомпилирована куча бинарников, и всем впадлу разбираться в чём-то новом ради, откровенно говоря, смутных профитов. Фундаментальная проблема тут, конечно, в форсе бинарной дистрибьюции софта вместо сорцовой самой по себе.Средний по оффициальности: интелу впадлу терять монополию. А у него таки да, накопилось достаточно различных рычагов влияния, чтобы не дать рыночку-хуиночку слова.Наименее оффициальный, но наиболее правдоподобный: дело в контроле. Не зря же АНБ потратило за прошедшие три десятилетия хуеву кучу денег на внедрение всякого говна в x86-е и удушение его конкурентов? ARMки, конечно, сами по себе ебучий зондодром, но пустить на рынок конкурирующую архитектуру значило бы стимулировать развитие кросс-архитектурных технологий, а следовательно, рисковать (игра слов) появлением чего-то третьего, более трудноконтролируемого. Оно им надо?
>>226999227Так маки тоже переводить собираются, и у эппле всякого софта для дизайнеров/аудиопидоров дохуя, программисты хуячат на макоси, может даже и в научной среде используют или в промышленном проектировании (но я не уверен).
>>226999280Ну, я например, пытался учить Си, но я не нашел нормального самоучителя, в то время находил одно говно, криво-косо отсканированное. Плюс, достаточно сложно разобраться.Потом взялся за Питон - и одно удовольствие на нем писать, разобрался легко и весело. И вакансий дохуя. На Си вакансий намного меньше, а скилл нужен повыше. Вот как-то так.
>>226999074Так-то это правда, но когда эппл выпустить маки под арм, вряд ли они будут тормозные. Все ли из-за низкой производительности? Что мешает ее нарастить на арме?
>>226999476>Так маки тоже переводить собираются,Маки уже эпично обосрались когда хотели доказать что "нитакие как фсе" и у них PowerPC а не x86. В итоге пришлось переползать на x86. Потому как конкурировать с Intel и AMD в современном мире никто не способен.
>>226999589>Плюс, достаточно сложно разобраться.Ты зумер? Cи "учится" за неделю. Это простой язык без ООП, функциональщины и прочих пидерсий.
>>226999589Я не программист, но решил ради самообразования поизучать это. И начал с питона как раз. Да, удобно писать и самоучителей дохуя, но я в один момент понял что нихуя не понимаю что делаю. Я будто работаю не с компьютером, а с обычными человеческими словами, пытаясь их выстроить так, чтобы что-то сделать, в некотором смысле получается магическое восприятие - ты делаешь что-то, но не понимаешь почему оно так происходит. В крестах уже пришлось немного глубже разбираться в архитектуре компьютера.
>>227000036Когда ARM хотя бы сравнится по-производительности с x86 тогда и приходите. А так использовать "телефонный" процессор в стационарном ПК есть глупость великая.
>>226999797Нет, я не зумер. И иди нахуй, я честно пытался научиться. И я даже не дошел до реально сложных вещей там, типа управления памятью.>>226999923Питон не для низкоуровневых штук, а для работы на логическом уровне. Когда ты знаешь что ты хочешь сделать, выстраиваешь такую себе архитектуру из инструкций. И тебе не особо нужно знать как оно внутри устроено, но зато надо знать, какая структура данных подходит больше и чем они между собой отличаются.На деле-то под капотом у Питона тот же Си. Если вдумчиво кодить, не будет такой хуйни как анон выше писал про 1Тб оперативной памяти.Но, конечно, до уровня производительности чистого Си Питону никогда не дойти, даже близко. Все питонисты знают, что питон медленный, но его любят за другое.
>>227000208Ну ок, а что конкретно сделало x86 быстрее ARM? Какие инструкции? Почему на x86 есть овер 5Ггц частоты, а на ARM нет хотя бы просто показать, что мы можем?
>>227000290>И я даже не дошел до реально сложных вещей там, типа управления памятью.Ты просто тупой. Смирись. Язык Си простой и логичный, любой нормальный программист его освоит очень легко.
>>227000290У тебя просто другие потребности, понимаю. Я то всю эту хуйню начал изучать, чтобы хотя бы иметь примерное представление о работе компьютера, и питон в этом не помог потому что абстракция над абстракциями. Но удобно для практической разработки.
>>227000322Avx, корни одной командой но не тактом и ид. Если 5 ггц в мобилке использовать они погорят нахуй
>>227000322>Ну ок, а что конкретно сделало x86 быстрее ARM?40 лет эволюции и миллиарды долларов вложенных в развитие> Почему на x86 есть овер 5Ггц частоты, а на ARM нетПотому что ARM не для производительности, он для энергоэффективности. Чтобы смартфон смог проработать хотя бы сутки на одном заряде батареи.
>>226996570> Свежо предание, уже выпускали на ARM, но чет оно понадобилось только 1,5 гикам. Значит все-таки причины есть.Когда они цены сделают пониже, тогда гики и подтянутся.
>>226999212Под Z80 софта намного больше. И его писали программисты, ну вы понимаете программисты... Настоящие.Писали на ассемблере. А вы макаки
>>227000558> Потому что ARM не для производительности, он для энергоэффективности. Чтобы смартфон смог проработать хотя бы сутки на одном заряде батареи.Чисто теоретически может сделать ARM проц на уровне рязани 3700 например, и если да, то почему не делают? Если нет, то почему?
>>227000615Что такое 1000$ для 300кк/наносек успешных господ? Вроде еще гигабайт выпускала плату с арм процессором для серверов, но тоже не взлетело.
Немного примеров ARM vs x86Нет не надо сравниваться по-производительности. Сделайте хотя бы половину производительности x86. Что не можете? Тогда идите нахуй...
>>227000505Да, я согласен, у меня другие потребности были, я просто хотел вылезти со дна, у меня тогда зп была около 2600руб.Если бы я изучал программирование, когда ещё был школьником/студентом первых курсов, я бы конечно, закопался поглубже в архитектуру. Я книгу неплохую скачал "хакинг искусство эксплойта", вот попадись мне такая книга в юности - я бы пошел другим путем.
>>226999923В свое время по этой же причине не стал учить плюсы. Пишешь какую-то хуйню около математическую в надежде что запустится.А в ассемблере всегда только один тип твердый и четкий: регистр.Делай с ним что хочешь, он простой и понятный как молоток.Кстати питон я потом изучил, а плюсы до сих пор нет.Сейчас программирую 8-битные контроллеры на js. (Эта строчка для справа).
>>227000833Ну главное, что со дна вылез, питон в этом действительно лучше си - вакансий больше. Удачи, анон.
>>226999280> , пересаживайтесь на си, здесь все заебись, будете свое говно для плеймаркета на нем писать.А браузер мне тоже на си писать? А библиотеки все питоновские тоже самому садиться и писать?А когда можно задачу уже начать свою решать?
>>226999321Почему не имеет?Арм по своей сути всю жизнь догоняет инцелов по производительности. Да и у них банально даже pci-e нету нормального.>>227000786Даже для 300кк это неделя работы. Ты согласен неделю въябывать чтобы тебе дали игрушку на арме?
>>226999280На Си тоже можно так написать, что вся оперативка вылетит в трубу. Что сказать-то хотел, чмошник?
>>227002260Но можно написать с таким минимальным потреблением ресурсов, с каким на питоне никогда не написать. Инструмент для тонких профессионалов: с помощью лазера можно криво порезать, но это не означает что теперь везде надо применять ножовку.
>>226996254 (OP)>>226996254 (OP)Почему люди такие тупые? Я просто зашёл на википедию и узнал за тебя ответ на твой вопрос. Кончай уже быть тупым быдлом.Режим, в котором исполняется 32-битный набор команд.ARM Base Instruction Set:[49]ADC, ADD, AND, B/BL, BIC, CMN, CMP, EOR, LDM, LDR/LDRB, MLA, MOV, MUL, MVN, ORR, RSB, RSC, SBC, STM, STR/STRB, SUB, SWI, SWP, TEQ, TST---------------------------------------------------------------------------------------Расширения архитектуры x86Расширение Флаг CPUID ОписаниеFPU EDX[0] Встроенное устройство с плавающей точкойVME EDX[1] Расширение режима V86DE EDX[2] Улучшенные средства отладкиPSE EDX[3] Большие страницы (4MiB/2MiB)TSC EDX[4] Встроенный счетчик времени (машинных тактов)MSR EDX[5] Моделезависимые регистрыPAE EDX[6] Расширение физического адресаMCE EDX[7] Генерация исключения машинного контроляCX8 EDX[8] Поддерживается инструкция CMPXCHG8BAPIC EDX[9] Встроенный локальный контроллер прерыванийSEP EDX[11] Поддерживаются инструкции SYSENTER и SYSEXITMTRR EDX[12] Имеется возможность задавать тип кэша для определённых областей памяти в специальных регистрахPGE EDX[13] Поддерживается флаг глобальных страниц (не сбрасываемых в TLB при переключении контекстов)MCA (англ.) EDX[14] Поддерживаются средства машинного контроляCMOV EDX[15] Поддерживаются инструкции условной пересылки данныхPAT (англ.) EDX[16] Поддерживаются расширенные атрибуты кэширования для отдельных страницPSE36 EDX[17] Большие страницы (4MiB) по физическим адресам выше 4GiBPSN EDX[18] Имеется возможность чтения серийного номера процессораCLFL EDX[19] Поддерживается инструкция CLFLUSHDTES EDX[21] Debug Trace and EMON Store MSRsACPI EDX[22] Имеются средства измерения температуры процессорного ядраMMX EDX[23] Поддерживается набор инструкций технологии Intel MMXFXSR EDX[24] Есть возможность сохранять/восстанавливать расширенный контекстSSE EDX[25] Поддерживается набор инструкций технологии SSESSE2 EDX[26] Поддерживается набор инструкций технологии SSE2SS EDX[27] Self-snoopHTT EDX[28] Поддерживается технология HyperThreading.TM1 EDX[29] Поддерживаются расширенные средства контроля температуры с генерацией прерыванияIA-64 EDX[30] Программа запущена в режиме эмуляции на процессоре ItaniumPBE EDX[31] Pending break eventSSE3 ECX[0] Поддерживается набор инструкций технологии SSE3PCLMUL ECX[1] Поддерживается инструкция PCLMULDTES64 ECX[2] 64-bit Debug Trace and EMON Store MSRsMON ECX[3] Поддерживаются инструкции MONITOR/MWAITDSCPL ECX[4] CPL-qualified Debug StoreVMX ECX[5] Поддерживается технология виртуализации Intel VT (Vanderpool)SMX ECX[6] Поддерживается технология управления доверием Intel TXT (LaGrande)EST ECX[7] Поддерживается Enhanced SpeedStep TechnologyTM2 EDX[8] Поддерживаются расширенные средства контроля температуры с генерацией прерывания и регистр THERM2_CONTROLSSSE3 ECX[9] Поддерживается набор инструкций технологии SSSE3CID ECX[10] context ID: the L1 data cache can be set to adaptive or shared modeFMA ECX[12] Поддерживается набор инструкций FMACX16 EDX[13] Поддерживается инструкция CMPXCHG16BETPRD ECX[14] MISC_ENABLE.ETPRDPDCM ECX[15] Performance Debug Capability MSRDCA ECX[18] Direct Cache Access (that is, the ability to prefetch data from MMIO)SSE4.1 ECX[19] Поддерживается набор инструкций технологии SSE4.1SSE4.2 ECX[20] Поддерживается набор инструкций технологии SSE4.2x2APIC ECX[21] Расширение локального APIC, 32-битный ID, регистры APIC доступны как MSRMOVBE ECX[22] Поддерживается инструкция MOVBEPOPCNT ECX[23] Поддерживается инструкция POPCNTAES ECX[25] Поддерживается аппаратное ускорение для алгоритма шифрования AESXSAVE ECX[26] Расширенная поддержка полного или частичного сохранения/восстановления расширенных контекстовOSXSAVE ECX[27] Флаг, указывающий приложению, что операционная система способна сохранять/восстанавливать расширенные контексты (регистры XMM и т.п)AVX ECX[28] Поддерживается набор векторных инструкций AVX и кодирование с помощью префикса VEXДополнительный набор расширений («от AMD»)CPUID, EAX=80000001HРасширение Флаг CPUID[1] ОписаниеSYSCALL EDX[11] Поддерживаются инструкции SYSCALL и SYSRETFCMOV (англ.) EDX[16] Поддерживаются инструкции условной пересылки данных с плавающей точкой (FPU)[2].MP EDX[19] Поддерживаются многопроцессорные конфигурацииNX EDX[20] Поддерживается атрибут страницы, запрещающий исполнение программного кода.MMX+ EDX[22] Поддерживаются расширения технологии MMX от AMDMMX+[3] EDX[24] Поддерживаются расширения технологии MMX от Cyrix[4].FFXSR EDX[25] Поддерживается быстрое сохранение/восстановление расширенных контекстовPG1G EDX[26] Гигантские страницы (1GiB)TSCP EDX[27] Улучшенная поддержка встроенного счетчика времениLM EDX[29] Длинный режим3DNOW+ EDX[30] Поддерживается расширение набора инструкций технологии 3DNow!3DNOW EDX[31] Поддерживается набор инструкций технологии 3DNow!AHF64 ECX[0] Инструкции LAHF/SAHF доступны из 64-битного режимаCMP ECX[1] HTT=1 indicates HTT (0) or CMP (1)SVM ECX[2] Поддерживается технология виртуализации AMD-V (Pacifica)EAS ECX[3] Поддерживается расширение APIC (APIC_VER.EAS, EXT_APIC_FEAT, и т.д.)CR8D ECX[4] Регистр CR8 доступен из наследственного режимаLZCNT ECX[5] Поддерживается инструкция LZCNTSSE4A ECX[6] Поддерживается набор инструкций технологии SSE4AMSSE ECX[7] Допустимо отсутствие выравнивания в SSE3DNow! ECX[8] Поддерживается инструкция PREFETCH/PREFETCHHWOSVW ECX[9] OS-visible workaroundIBS ECX[10] instruction based samplingSKINIT ECX[12] Поддерживается технология управления доверием в AMD-VWDT ECX[13] Поддерживается встроенный сторожевой таймерSHA (англ.) Поддерживается аппаратное ускорение для алгоритма шифрования SHA
>>227002226Ну давай, приводи пример, что ты написал и ни разу не использовал ничего стороннего.Ни конструкции языка, ни библиотеки, ни ассемблер, ни верилог, все сам собрал из говна и палок.Давай, петушок. Ты можешь
>>227002402Скорее, Си - это ручной напильник, которым ты можешь довести до идеала одну деталь, потратив на это уйму времени. А абстрактные языки - это заводской конвеер, которые хуярит потоком огромное количество продукции, пусть и не идеальной, но вполне достойного качества.
>>227002719лол, там про них ничего не написаноNEON, Thumb-2 (обязательно начиная с ARMv7), Jazelle, VFPv4-D16, VFPv4 (все обязательны в ARMv8)В микроконтроллерах: FPv4-SP
>>227000791очень уж древний снапдрагон, надо с 865 сравнивать, тем более он растет в производительности по 30 процентов в год в отличие от 5% у x86
>>227002853Ну в x86 fpu, sse1 -sse4, mmx, 3dnow, avx- это тот же самый neon. По сути avx и sse здесь актуальные, а 3dnow и mmx стоят для совместимости. Кстати 3dnow в новых процессорах отсутствует вообще.Шифрование есть и там и тут.Режимы 32-64 в арме тоже присутствуют, 16 битного нет.Остальные флаги вообще ни о чем, одну две инструкции добавили и все.
>>226996254 (OP)>что есть в x86 такого, что его не заменяет ARMЯ думаю, так исторически сложилось. Как ты знаешь, семейство x86 поддерживает архитектуру набора команд процессора интел 8086, который ещё в 70-е появился, видимо, от него пошли персональные пекарни и так тупо всем удобно. Сейчас на рынке процы семейства x86 производят интел и амд -- два гиганта. Короче понятно
>>226996254 (OP)Старый ассемблерист в треде. > объясни мне чем так принципиально отличаются ARM и x86 архитектурыКратко: это разные процессоры с различным набором команд, с формальной разницей в 10 лет, а фактически в 20 лет.Развернуто:Архитектура x86 родом из эпохи плохих компиляторов и больших микросхем. У таких камней оче мало регистров, но зато огромный набор команд. Их ассемблер богат, удобно даже писать руками.Архитектура ARM - это куча регистров, но небольшой набор команд. Настолько небольшой, что даже есть компактная форма записи. Эти камни из эпохи, когда компиляторы стали настолько хороши, распределяют регистры лучше, чем средний ассемблерист. Есть условные вычисления, для хорошего кода не нужен даже конвеер. В целом, эта архитектура лучше, экономнее по потреблению, код компактнее. Почему же x86 сейчас рвет ARM? Потомучто x86 уже 40 лет делают камни сильнейшие корпорации, есть куча софта, охуеннейшие компиляторы, а ARM делают карлики.
>>227003784> Какие карлики?По сравнению с Intel и AMD производители ARM - карлики. К тому же лицензия ARM доступна всем
>>227003581Как думаешь, ARM сможет немного сдвинуть x86-64, если крупные компании как Samsung какой-нибудь заинтересуются этим? Сам же пишешь, что в целом архитектура лучше, а первое что на ум приходит - это ноутбуки, где ARM сможет лучше проявить себя как мне кажется, а там может и до дескопов дойдет, и будут не два производителя процессоров для пк, а много больше.
>>227004404> Как думаешь, ARM сможет немного сдвинуть x86-64Так уже сдвинула. Монстры процессоростроения проебали рынок мобильных аппаратов. Потомучто невозможно засунуть в телефон проц, который излучает 75-100Ватт.> а первое что на ум приходит - это ноутбуки, где ARM сможет лучше проявить себя как мне кажетсяУ ARM только-только стали появляться многопроцессорные камни с хорошими конвеерами, а Intel это делает уже 26 лет. Это много, но ARM догоняет, да
>>227004762Intel еще и серит в последнее время, новая серия процов 10ххх на старом техпроцессе просто с более быстрыми ядрами и их больше, но соотвественно горячее все это. Еще яблочные отказались от их процов в сторону армы, что тоже может дать толчок к развитию арм на дескопах.
>>227003581То есть, чтобы написать полноценную систему на ARM нужно встраивать в нее компилятор набора команд какой-то?
>>227001145Сейчас программирую 8-битные контроллеры на js. (Эта строчка для справа). И как?Вот тоже хочу, а то кроме js ничего не умею.
>>227005016Противостояние x86 и ARM чем-то напоминает противостояние Windows и Unix-систем. Вторые долго были ублюдочным поделием(да и сейчас являются) для узких задач, но внезапно Google взял и сделал на этой хуите Android и сейчас формально самая распространенная ОС на планете - это unix.
>>227002844Господи, какую-то шаблоную хуйню пишешь, из интернетов. Что си, что плюсы нихера не сложные, если начинаешь учить разработку с них. Да и в принципе ничего там космического нет. Надо только понимать как устроен ЭВМ или МК. Просто большинство не интересно разбираться как устроена их область знаний, и довольствуются поверхностными знаниями.
>>227005269> То есть, чтобы написать полноценную систему на ARM нужно встраивать в нее компилятор набора команд какой-то?Не понял вопроса. Android - вполне полноценная система. О чем ты?
>>227005447Да я поттроллить хотел) Это же ппц, тратить время на восьмибитки да еще на js. В результате не знаешь ни современной техники, ни как она устроена.
>>227003581А почему ARM процессоров нет на таких частотах как у x86, хотя бы в качестве экпериментальных образцов? Чисто теоретически нет проблем нарастить число ядер/герц на АРМе, ведь тогда они будут ебать x86?
>>227005505Нахуй нужны кресты/си в 2к20 за исключением узкой хуйни, которой заняты 2% программистов максимум? В вебе нахуй кресты нужны, если есть пайтон?
>>227005897> А почему ARM процессоров нет на таких частотах как у x86Потомучто ТЕПЛОВЫДЕЛЕНИЕ. > нет проблем нарастить число ядер/герц на АРМеРазработка проца - это дорого. У производителей ARM нет таких средств, чтобы делать пососательные процессоры и крутить фиги интелу и амд. Опять же, понятно, кто будет покупать сильные интелы и куда их ставить. А кто будет покупать сильные армы и в какое железо из ставить?> ведь тогда они будут ебать x86ARM рулит в мобильных устройствах. Ему надо ебать по энергопотреблению, а не по MFLOPS. Что он давно и делает.
>>227000666Потому что блять это тупо не выгодно с точки зрения бизнеса. Сделаешь ты проц, кто его юзать-то будет? 3,5 пердоли? Людям в игрушечки для дебилов поиграться хочется, а не сидеть на нитакойкакфсе машине. Поэтому эпло и пилит свои процы в первую очередь для маленьких машин, потому что тепловыделение и энергоэффективность там важнее, нежели йоба 5ггц. А игрушечек там нет, ибо эпол покупается чтоб в интернетиках сидеть да кинчик разглядывать, ну или ты йобамонтажер/звукарь.x86 не умрет пока его не обгонят арм не только технически, но и софтом. А софт у мелкопидоров говно.
>>227006276Да да, узкая хуйня, все дела. Все сишники и крестовики давно сидят на своих местах и пишут код, не блядую из конторы в контору, ахаха)
>>227005361От юникса у андроида ровным счетом нихуя, кроме юникс-подобного ядра линукс. FHS нарушен чуть менее, чем полностью, базовых юникс-утилит нет, кроме libc да java-машины. Есть ядро, кучка библиотек и API, чтобы работали приложуньки. Всё осталньное лежит на плечах самих разработчиков.
>>226996254 (OP)>а конкретнее: что есть в x86 такого, что его не заменяет ARM?имхо здесь нет вопроса замены - это просто две ветви развития процессоростроенияпри чем здесь эмуляция х86 на арме или наоборот? логично что это будет медленнеекакая нахрен замена если все сводится к компиляции под нужную архитектуру?х86 просто вовремя стал популярным вот и все>Почему ARM-архитектура не получила распространение на компах/серверах?схуев это? sun sparc, просто его сдвинул интелwindows nt вполне работала на risc процессорах>>всем напоминаю про Transmeta Crusoe (не арм и не х86), виндоус вполне работал через трансляцию в x86 и не сильно медленнее.
А как влияет поддержка обратной совместимости на x86. Они же кучу старой хуйня тащят. Не будет лучше выкинуть старый мусор?
>>227007212> FHS нарушен чуть менее, чем полностью, базовых юникс-утилит нет> базовых юникс-утилит нетНу как-бы телефон - это не заготовка под сервер. Надо на всём экономить. В эпохе первых андроидов каждый мегабайт - ценность.> Есть ядро, кучка библиотек и API, чтобы работали приложунькиЯдро-то и система администрирования юниксовые, а не windows CE.
>>227008675Шиндовс очень дрочится по обратной совместимости из-за КОРПОРАТИВНЫХ КЛИЕНТОВ, для которых это важно. Чтобы ты мог документ отчёта в ворд 2003 запустить в 2020 году на своей машине без ебли
>>227003581Obiasni pozaluista esho odin moment, kasatelno mobilnih processorov.Vot dopustim est sovremenni snapdragon, kotori rvet core 2 duo i graphicheskie uskoriteli ala gtx 8800.Kakogo cherta na mobile net igr hota bi 2006 goda po grapike? Dage unreal tournament 2004 rvet v shepki luboi fps na mobilkah.(sorry za translit)
>>227008735>Ну как-бы телефон - это не заготовка под сервер. Надо на всём экономить. В эпохе первых андроидов каждый мегабайт - ценность.Я вижу ты проигнорировал тот факт, что FHS нарушен. А то, что нужно экономить дисковое пространство - не аргумент. Юникс был сделан в 70-х, и объем диска>Ядро-то и система администрирования юниксовыеНа этом юниксовоAndroid не является POSIX-совместимой ОС. А значит, что и юниксом оно называться не может, стандарты другие. Любая программа, скомпилированная под GNU/Linux, попросту не будет работать, ибо андроид уже не UNIX.
>>227010001Юникс-система не обязана поддерживать POSIX. Если у тебя в ноутбуке нет шины стандарта USB, это не значит, что он перестал быть ноутбуком
>>227009441> Kakogo cherta na mobile net igr hota bi 2006 goda po grapike? Dage unreal tournament 2004 rvetМало кто пишет шутеры для мобилок. На устройствах размеров с ладонь в такое просто неудобно играть. А вот всякие гоночки - это вполне качественное и выше чем, в 2006 году. Эксель на мобилках тоже скорее всего ублюдочный или отсутствует.
>>227010001> Я вижу ты проигнорировал тот факт, что FHS нарушенЯ даже думаю, что это сделано намеренно. Чтобы не было> любая программа, скомпилированная под GNU/Linux, попросту не будет работатьГугловцы сделали сорт забора от красноглазых в целях безопасности, чтобы там нельзя было запускать что-нибудь с помощью nohup& и выкидывать во внешний мир. Мобилами же пользуются все
>>227010373>Юникс-система не обязана поддерживать POSIX. Если у тебя в ноутбуке нет шины стандарта USB, это не значит, что он перестал быть ноутбуком Не пытайся выдавить из себя то, чего не знаешь, не позорься. Твой пример убог и жалок, учи матчасть, прежде чем что-то удтверждать, анон. UNIX - стандарт, и если система решила называть себя UNIX - она должна быть близка к соответствию или полностью соответствовать Single UNIX Specification (в т.ч. и POSIX, ибо стандарты схожи). Пример - MacOS. Там FHS нарушен полностью, но тем не менее стандарты не тронуты, поэтому она может называться UNIX. Android использует лишь ядро Linux, но не соответствует стандартам, ибо у Android они свои и софт у них также свой, не совместимый.
>>227010876>Гугловцы сделали сорт забора от красноглазых в целях безопасности, чтобы там нельзя было запускать что-нибудь с помощью nohup& и выкидывать во внешний мир. Мобилами же пользуются все.GNU/Linux и Android - две разные ОС. Мне дальше лень расписывать чем Android отличается, поэтому кину статейку на хабре https://habr.com/ru/post/16770/. Невозможно взять софт от одной ОС и использовать её в совершенно другой ОС, пусть даже ядра там одни.
Сижу с малины 4гб ОЗУ. Система - распиан. Хоть кто-нибудь из людей в треде эмулировал процессор под приложения? Не целую систему, а только userspace?
>>227012363Да вот чето не получается запустить ничего. Хочу приложения стильные, модные, молодежные. Здесь из рабочего софта - хуй да нихуя по сути. Только древнейшие портированные пакеты из репов.
Есть еще какой-то ахуенный вариант, когда ты можешь добавить альтернативные архитектуры к dkpg и запускать через кему, тоже хуй пойми как работает.
>>226996254 (OP)>а конкретнее: что есть в x86 такого, что его не заменяет ARM? Ничего - машина тьюринга же.
>>227011778> Невозможно взять софт от одной ОС и использовать её в совершенно другой ОСНу так-то ты и из RedHat ничего не запустишь под Linux без перекомпиляции. Но обе - unix. Ты реально в какое-то красноглазое упорство впадаешь, доказывая, что Android не unix.
>>227012653Да не будет это работать. dpkg будет качать пакеты для других архитектур, которые попросту не будут работать.
>>227006330>или ты йобамонтажер/звукарьА там разве не важна производительность? Монтажеру еще проц нужен помимо видео, звукарю триллион дорожен/синтов накрутить
>>227000791> Немного примеров ARM vs x86> Нет не надо сравниваться по-производительности. Сделайте хотя бы половину производительности x86. Что не можете? Тогда идите нахуй...Как это не можем? Еще как можем. Х86 - прошлый век. Из всех инструкций в основном используются только 30%. То есть х86 в тяжелых задачах использует только треть потенциала, и соответствующий арм будет в 3 раза быстрее.
>>227013190АРМ ахуенно быстрее, без базара. Это я уже понял. Только софта нету нихуя, если его пишут под задачи - то да. А так юзеру он в хуй не вперся, это я тебе точно скажу. Может яблочники исправят ситуацию.
>>22701281832 битный арм и 64 битный имеют две разные архитектуры, это тебе не x86_64. Держу в курсе.
>>227000615>Когда они цены сделают пониже, тогда гики и подтянутся.Wake up, NeoМалинка и её аналоги давно уже на АРМах
Я полагаю что разница в магическом соусе Intel/AMD. Он просто быстрее. Наверное потому что весь конвейер круче: x86 умеет замечать определённые идиомы, оптимизировать на уровне микроопераций, вероятно и самих модулей выполнения инструкций больше. Да, ARM вроде тоже суперскалярный, но x86 банально больше, во всех смыслах. Кроме этого имеются технологии уровня Management Engine, например, аналогов которых я не знаю на ARM ("не знаю" не значит "не существует", просто лично я не видел).Компиляция на другую архитектуру тоже частично проблема. Много софта под линукс отлично кросс-компилируется, чего не скажешь про винду, хотя там сподвижки тоже есть. Инфраструктура завязанная на мелкософте сидит на x86 как и сидела когда пытался появится Itanium от интела и по тем же самым причинам: closed-source софт которому 20 лет никто не перекомпилит под новую архитектуру а эмуляция это медленно. AMD64 победил Itanium потому что всем была нужна обратная совместимость.Опыта у меня мало, однако я бы сказал что сейчас ARM не имеет какой-то стандартизации хорошей. Вот на x86 есть BIOS/UEFI, которые хоть и полны обсёров и хреновых реализаций но к ним все привыкли, софт для них готов и взяв любой компьютер на x86 я уверен что я точно знаю как он грузится и что может пойти не так. С ARM надо колупаться с новыми загрузчиками, с device tree, ещё с чем-то – неудобно, короче, хотя может я просто не видел настоящие серверные решения и там это починили.Короче, для ARM нужно время. Они только недавно начали прорываться на этот рынок и процесс ещё идёт, вроде как.
>>227013335> Только софта нету нихуя, если его пишут под задачи - то даКак это нету нихуя? Весь апп стор. Там и фотошоп есть, и лайтрум, и куча софта по работе с медиа
>>227013433> Короче, для ARM нужно время. Они только недавно начали прорываться на этот рынок и процесс ещё идёт, вроде как. В смысле недавно? Уже лет 15 как.
>>226999244Хрен его знает сложит ли разом, но вот разделить на независимые друг от друга инструкции может и сложит скажем 1+2 и 3+4, 5+6, 7+8 в одном такте. Может по какому нибудь алгоритму томасуло поменять их эти сложения местами чтобы между ними ещё какую нибудь хуйню сложить чтобы не ломать конвеер, или прервать твои вычисления нахуй потому что пока твой конвеер сломан надо запускать гипертридинг и считать другое.
>>227013557Понимаешь, есть принципиально два разных подхода: решить задачу и "использовать опенсорс сообщество". Эпл обычно берут, чтобы решить задачу
А что там у хохлов арма с уровнями кэшей, их когерентностью и всякими лукап тейблами на случай промаха?
>>226998775"Reduced" (R) в RISC означает длину инструкции, а не количество инструкций. Архитектура, направленные на уменьшение числа инструкций обозначается MISC (minimal instruction set computer).
>>227013666Скорее всего этот господин прав. А малина - как я понял чисто для хостинга всякого скрытого говна.
А что там у арма с бренч предикшен и спекулятивным исполнением когда сначала делаем чтобы конвеер не ломать а потом смотрим ту ли ветку надо было исполнять?
>>227012711Могу, кто сказал что не могу? Вы? Обе - системы GNU, обе имеют одинаковую архитектуру, одинаковое ядро и одинаковые библиотеки. С чего бы приложению не запуститься на одинаковых системах? Android - не UNIX, и я тебе привел уже аргументы почему. Только ты неустанно приводишь бредовые аргументы, не совместимые с реальностью уж никак.
>>227014270> одинаковое ядро и одинаковые библиотекиНо не запускается. Я напишу простое приложение, которое читает что-нибудь с последовательного порта под красной шапкой и это не запустится под линухом. Красноглазая совместимость AS IS> Android - не UNIX, и я тебе привел уже аргументы почему.Аргументы уровня нету каталогов bin/etc и нету cat/ls/man? Да срать на это с колокольни. С точки зрения разработки софта, API, доступа к периферии, способ сборки приложения - Android это unix-система, а не Windows CE или что-то другое.
>>227014882>Но не запускается. Я напишу простое приложение, которое читает что-нибудь с последовательного порта под красной шапкой и это не запустится под линухом. Красноглазая совместимость AS ISПиши, а мы посмотрим, как оно не будет запускаться.>Аргументы уровня нету каталогов bin/etc и нету cat/ls/man? Да срать на это с колокольни. Я тебе статейку на хабре отправлял. Там видно, что внутренняя архитектура андроид кардинально отличается от того, что мы видим в никсах. И дело даже не в FHS. >С точки зрения разработки софта, API, доступа к периферии, способ сборки приложения - Android это unix-система.Загибай пальцы. Собранный код для Линукса НЕ ЗАРАБОТАЕТ на андроиде никак, первый твой аргумент говно. Доступ к переферии - там тоже свои наработки, не имеющие отношения к юниксу никаким боком. Второй твой аргумент говно. Собранный бинарь для линукса будет работать на любом дистрибутиве линукса. На андроиде - нет. Третий твой аргумент говно.
>>227015726> Пиши, а мы посмотрим, как оно не будет запускаться.> АРРЯЯ, ГОВНОНу слушай, диван. У меня в бытность писания кроссплатформенных приложений в ходу были обертки для uart, многопоточности, сокетов. Приложение должно было работать под FreeBSD/RedHat/Linux/Win/WinCE. Для КАЖДОЙ красноглазой оси я в обертки вносил свои флаги и способы для uart, обработки сокетов и в одной из них правил обертку для многопоточности. А код для Win на WinCE запускался просто без переделок. Я уж не говорю про обмен по USB. До появления ftd2lib(не на всех системах доступная) на красноглазых системах можно было просто забежать на потолок. Я на практике знаю, что красноглазые мантры про совместимость - просто понос. И для своих целей делают такие обрезки из FreeBSD или линукса, что Android выглядит просто образцовой unix-системой.
>>227016399>>227016442> > кожаных чулок то понятно,> > но у меня линупс> Но линукс куда более гейский, чем макосьТрадиция двача - подмена понятий.Макось не гейская. Её одни пидары покупают/воруют у других пидаров и анально засовывают в православную пеку. А у кого денег побольше - те покупают недопеку с анально предустановленной макосью у эпла.Причём в начале пути эпл не скрывал этого.
>>226996254 (OP)Тем, что у ARM-архитектуры набор машинных команд ограничен, и нет прямого доступа к оперативной памяти (значение из нее надо сначала выгрузить, к примеру, затем обработать, после чего - снова загрузить туда). Помимо этого, команды в ARM-архитектуре могут быть очень длинными, если принимают на вход очень много значений. Алсо, при вызове функций (и переброске выполнения в другое место программы в оперативной памяти) в ARM-процессорах применяется отдельный регистр, куда записывается текущий адрес следующей выполняемой команды, в то время как в архитектуре Intel это самое значение складывается в стек, в область оперативной памяти.
>>227019316> в то время как в архитектуре Intel это самое значение складывается в стек, в область оперативной памяти.Это ты про регистр IP/EIP сейчас написал, которого нет у x86?
>>227019604Тащемта, instruction pointer - это регистр именно Intel, у ARM же помимо такого регистра (не помню его название, вроде бы это r7) есть еще один регистр, куда при вызове функций сохраняется старое значение instruction pointer'a.
>>227003581Безмерно уважаю тебя. Ты реверс-инженер или хакер? Просто я не вижу иных способов практического применения асма в 2020.
>>227019316В x86 вроде как есть jump и long jump на случай если хочешь далеко по памяти прыгнуть на абсолютный адрес.
>>227020629А если мы рекурсию (или просто вложенная функция)замутили то куда поедет старое значение адреса возврата? В память? Или там регистров припасено на типовой уровень вложенности?
>>227020766У ARM при вызове вложенной функции в стек значение сохраняется именно из запасного регистра, куда до этого было положено старое значение. Советую просто изучить язык ассемблера данной архитектуры, все станет предельно понятно.
>>227020147Да, я посмотрел уже. В ARM есть регистр, в который кладется содержимое IP, если делать CALL. Это действительно может помогать в программах, где уровень вложенности вызовов равен 1. Если больше, то всеравно IP придется положить на стек. Или доверить это компилятору >>227020365> Просто я не вижу иных способов практического применения асма в 2020.Давно не пишу на асме. Но иногда поглядываю на отрыжку компиляторов, если приходится писать для какого-нибудь микроконтроллера.
>>227021060> Если больше, то всеравно IP придется положить на стекДа, я о том же.> Давно не пишу на асме. Но иногда поглядываю на отрыжку компиляторов, если приходится писать для какого-нибудь микроконтроллераСам начал кодить под микрухи, но быстро забросил, так как понял, что мне это неинтересно, и вообще си с асмом я учил, потому что хотел стать хакером (чего у меня не получилось, к сожалению). Жаль только потраченных денег на программатор, мультиметр, паяльник и микрухи с модулями..
>>227021317> что хотел стать хакеромСейчас хакинг лежит в области веба. Нынешние хакеры изучают питон, устройства баз данных и сетевые протоколы. CLI/HLT уже давно не работает
ARM прекрасно подходит для десктопа. Мало того, что на нём линукс стартует, так и винду завезли недавно. Если вкратце, и не вдаваясь в детали, то языки программирования до сих пор тащат за собой код прямиком из 90х. И за многие глды там скопилась такая хуева туча команд, которые как бы уже и не нужны, но и удалить нельзя. Потому что что-нибудь отвалится. А когда ARM только появилась, люди уже устраивали срачи AMD vs INTELКороче, нужно писать отдельные интерпретаторы для этой архитектуры. А это дело не быстрое. Да и ARM никогда к этому не стремились. Короче, основная причина - они опоздали. А так, они вполне могут представлять угрозу штеуду с амуде. Это лишь вопрос времени, когда начнут свою экспансию
>>227021515> Сейчас хакинг лежит в области вебаНо ведь это не обязательно так. Всякие переполнения буферов до сих пор могут встретиться в каком-нибуть нгинксе или ProFTPD, к тому же, лучше всего попытаться найти ошибки на разных уровнях абстракции, разве нет?> питонИзучил его пару дней назад. На нем ведь проще всего писать эксплойты и разного рода утилиты для автоматизации.> сетевые протоколыТоже изучил.
>>226998488>>226998651Просто у эпла нахуй отсутствует обратная совместимость. На шинде включаешь устройство 2000 года и им можно будет пользоваться, на эпл нет.
>>227021971А ты думаешь, обратная совместимость даётся бесплатно?Расплата за это - необходимость поддерживать легаси говно, из-за чего замедляется работа системы.Эппл выпиливают нахуй всё старое дерьмо, а в винде до сих пор две папки Program Files для х32 и х64
>>227022314>две папки Program Files для х32 и х64 ...и ты ещё не видел две разные панели управления, вот это вообще умора.
Поясните, можно ли скомпилить плюсовой код так, чтобы он без ос работал? Нахуя мне нужна ос, которая жрет кучу ресурсов, если можно просто запустить программу без ос.
>>226996254 (OP)Блядь, оп, ну серьезно? Ты на серьезных щах задаешь этот вопрос? Да наверное даже школьник знает что у arm число ppx гораздо меньше чем у х86. К тому же эффект сингулярности пониженной частоты у arm. Только из за этих двух причин нельзя arm в десктопах использовать, а этих причин миллиарды!
