В основном да. Но не только.
неоднократно показывал что если воспользоваться механизмом gp2c и скомпилить программу на PARI в С-ый код, то потом получается программа в сотню раз быстрее. Скорости асм+AVX2 конечно не достигается (это вообще надо сильно постараться), но скорости неплохой программы на С вполне.
Из-за интерпретации не только медленно, но ещё и "ломаются" (не работают или дают противоположный результат, т.е. ухудшают вместо улучшения) многие известные техники ускорения программ, я несколько раз об этом говорил и приводил примеры. Например у меня не получилось поднять скорость с 63.2 раза до теоретических 75.6 раз, хотя я точно знаю как это сделать и как оно должно было сработать (обрабатывать большие таблицы небольшими кусочками), но реально получилось незначительное
(до 62 раз где-то) вместо ускорения. Потому что в циклах стало больше команд PARI и они стали больше раз выполняться (и декодироваться), и это съело весь выигрыш от оптимизации обращений в память.
Почему "не только". PARI по моему в принципе не оптимизировался под
и универсальность вычислений. Особенно сложных. Например проверка чисел на простоту, интегрирование, вычисление всяких интересных функций и так далее. Видимо поэтому нет нормальной работы со строками (только с массивами символов), чтения даже текстовых файлов (только или построчно, или целиком в вектор), выделения памяти под сложные или очень простые структуры данных (я не смог выделить большой массив байтов, никак, или многомерных массивов кроме как массива массивов). Про кривизну реализации многопоточности тоже уже говорил. Зато удобно и понятно.
У Вас случайно нет желания открыть тему с примерным названием "Асм для чайников и кофейников"?
По типу имеющейся про PARI? Нет, желания не было. Впрочем если у народа (пусть даже в Вашем лице) будет желание позадавать вопросы в такой теме, то готов её завести и поотвечать. Но превращать её в цикл лекций по обучению - не готов. Потому что считаю что асм настолько отличается от привычного мира, даже от C или PARI, что объяснять надо буквально с азов (школьной программы если у кого в школе всё же была информатика). И эти вот азы у каждого свои, уровень понимания, и он даже не линейный, а скорее фрагментами (кто-то знает много, но некоторые базовые вещи нет, и наоборот). А мне многие и многие вещи уже давно настолько очевидны, что просто не понимаю как их можно не знать или не понимать. Я даже помню как сам кое-что простое в упор не понимал годами, но что-то другое мне и в голову не приходит что это малопонятно. Приведу аналогию с математичкой: кто-то знает арифметику, но не уравнения; кто-то знает уравнения, но не признаки делимости; кто-то знает логарифмы, но не квадратные уравнения (да, есть и такие!); кто-то умеет интегрировать, но не понимает тригонометрию; а кто-то понимает тригонометрию, но не логарифмы; и так далее в самых разных комбинациях, которые я даже в страшном сне представить не смогу. И это не голословные заявления: я нескольким людям помогал разобраться и с С и с асмом и видел всё это вживую. А уж сколько раз сам попадал в идиотскую ситуацию с техподдержкой, когда исключил уже казалось все возможные причины сбоев чего-то там, вплоть до квантовых флуктуаций и космического фона (да-да, и такое бывало проверялось!), а потом спустя недели разбирательств оказывается просто забыли вставить провод!!
Ну ка-а-а-а-к можно было это не проверить первым делом за столько времени?!?! А я просто не подумал (не мог представить) что столь очевидную ведь могли пропустить и выдумывал и заставлял проверять более сложные причины.
Ещё, асм требует очень логического (формализованного) мышления, сильнее чем для С или PARI. В этом смысле математикам проще, они привыкли к формализму и им в общем всё равно какой именно. Тут просто другой. Например есть лишь 7-15 переменных (регистров) с которыми можно делать
очень простые действия, а если надо больше переменных - то будь добр прочитать (и записать обратно) из файла на диске (грубая аналогия). И тип переменных строго ограничен и простой: только небольшие целые числа или только с плавающей точкой фиксированной точности. Или короткие вектора из ник (MMX, SSE, AVX). И если число не влезает в регистр (например более 5млрд в 32-битной архитектуре), то придётся его хранить в двух (трёх и т.д.) регистрах и уже не получится их просто так сложить/вычесть или сравнить друг с другом - придётся самому писать в деталях как именно это надо делать. А ещё половина этих переменных/регистров имеют спецназначение и например умножение нельзя сделать над произвольными регистрами, а только над первым и любым другим и результат будет не где захотите, а строго в первых двух (утрирую, но не сильно). И попытка написать хоть сколько нибудь сложный код (что-то посчитать) выливается в попытку вычислить интеграл от синуса от чего-нибудь несложного через
четыре действия арифметики (опять же утрирую, но снова не столь уж сильно). Да, можно, да,
в принципе известно как (хотя путь от принципа до реального алгоритма вычисления очень неблизок), да, кто-то когда-то это уже делал и даже выложил свой код (обычно кстати весьма кривой и вам в конкретную задачу ну совсем не подходящий и надо переписывать под свои условия если не хотите сильно потерять в скорости счёта) и можно не париться и взять готовое - но это всё намного муторнее (кому-то зато и интереснее!) чем на языках высокого уровня. И на асме нет такого понятия как "компилятор умный, он сам всё сделает". Нет, он в этом смысле
тупой! И сделает ровно и только то что вы ему прикажете, ни на йоту больше. И многих (например меня) именно это и привлекает, полный контроль над происходящим.
И отдельной большой проблемой стоит оптимизация. По скорости, по памяти, по количеству обращений к файлам (и памяти). Написать абы какой код несложно, достаточно пары недель занятий (обычно на изучение тех самых 4 арифметических действий что умеет проц и на привычку раскладывать сложную операцию типа проверки простоты на много-много простейших действий) и он будет работать, но вот когда захочется чтобы он работал не абы как, а
быстро - вот тут придётся помучиться в разы больше. И почитать намного больше, и тупо придумывать раз за разом новый
принцип вычисления и проверять быстрее он или медленнее, причём часто на конкретной аппаратуре, не где-то там на воображаемых идеальных проце, компе и винде, а вот конкретно у себя на компе в это время суток (а винда любит подсуропить и начать шебуршиться в самый неподходящий момент) при таких запущенных программах и так далее. Подчеркну, не просто переписать код по другому (хотя и этого хватает), а реально
придумать как например факториал посчитать ну совсем-совсем по другому, не как привычно и понятно. Да даже тривиальное казалось бы умножение, а есть ведь быстрые методы, ну какому нормальному человеку придёт в голову для перемножения двух чисел использовать фурье разложение?! Его ещё далеко не каждый понимает (скажем я почти нет) или даже вообще знает что оно есть. А так иногда оказывается быстрее. Это конечно не исключительно про асм, но там таких трюков море, намного больше чем на нормальных языках. И иногда такие трюки могут дать ускорение в десятки раз! Даже когда казалось бы выжато всё возможное и дальше некуда - вдруг приходит новая идея (совершенно казалось бы не подходящая и вообще "из другой оперы", как с фурье для умножения), приходится переписать весьма значительную часть кода, зато оно вдруг раз и работает заметно быстрее. Короче написать
быструю программу в разы сложнее чем написать хоть какую-то правильно работающую, тут пары недель не хватит, могут и годы уйти на
в основном придумывание (ну или узнавания из книжек и гитхаба) разных трюков.
Вопросов надёжности вычислений или многопоточности касаться не буду, это ещё два айсберга не меньше оптимизации, не столь сложные в коде, но сильно не интуитивные (сказал бы как квантовая механика, но физики обидятся) и проблема скорее не в умении так писать код, а в ломке собственных навыков (причём как раз наработанных выше, при изучении асма и попыток оптимизации программ) чтобы писать код
именно так, а не как кажется более правильным, чтобы правильным стало казаться вот так.
В итоге дублировать множество имеющихся книжек и лекций и видосиков типа "асм для чайников" не вижу ни смысла, ни терпения мне не хватит объяснять
последовательно и понятно много базовых (и самоочевидных для меня) вещей. А вот объяснить непонятные моменты, конкретные вопросы - это запросто. Собственно как и с физикой или математикой: никто же не открывает тему "КМ для чайников" или "Топология для чайников" (хотя книги и видосики такие точно есть), все отсылают к учебникам (и видосикам) и лишь помогают в их изучении. Да и тема про PARI выродилась в это же, ответы на вопросы, лекции давно закончились, хотя и сильно помогли на самом начальном этапе (но для асма они и так уже много где есть).
Но так как у меня собственно нет законченного образования по программированию, то я даже учебников и курсов порекомендовать не могу - когда изучал сам, то это было сумбурно и по десяткам старых книжек (и не учебников), часто совсем не о том (я шёл не от С или PARI к асму, а от схем на релюшках (кто ещё помнит как они работают?!) и транзисторах и процессоров и их команд к асму, т.е. совсем с другой стороны).
Но помочь разобраться методом ответов на вопросы и разъяснений непонятных моментов - легко.
завести готов. Глупые именно ответы, не вопросы - как бы не претендую на гуру в асме, но что знаю поделюсь. Если соберётесь с духом/силами. Или может опрос замутить интересно ли это кому-то ещё? Тут-то никто не увидит. Хм, а мысль ...
простых чисел приходится лишь одна 3-ка 6-6. 13 млн троек найдено.
3-к 6-6 — лишь одна центральная 5-ка 24-6-6-24.![$\tikz[scale=.08]{
\fill[green!90!blue!50] (0,190) rectangle (50,200);
\fill[green!90!blue!50] (0,140) rectangle (50,150);
\fill[green!90!blue!50] (0,110) rectangle (50,120);
\draw[step=10cm] (0,110) grid +(50,120);
\node at (5,225){\text{2}};
\node at (5,215){\text{3}};
\node at (5,205){\text{5}};
\node at (15,205){\text{29}};
\node at (5,195){\text{7}};
\node at (15,195){\text{31}};
\node at (25,195){\text{37}};
\node at (35,195){\text{43}};
\node at (45,195){\text{67}};
\node at (5,185){\text{11}};
\node at (5,175){\text{13}};
\node at (15,175){\text{37}};
\node at (25,175){\text{43}};
\node at (5,165){\text{17}};
\node at (15,165){\text{41}};
\node at (25,165){\text{47}};
\node at (35,165){\text{53}};
\node at (5,155){\text{19}};
\node at (15,155){\text{43}};
\node at (5,145){\text{23}};
\node at (15,145){\text{47}};
\node at (25,145){\text{53}};
\node at (35,145){\text{59}};
\node at (45,145){\text{83}};
\node at (5,135){\text{29}};
\node at (15,135){\text{53}};
\node at (25,135){\text{59}};
\node at (5,125){\text{31}};
\node at (5,115){\text{37}};
\node at (15,115){\text{61}};
\node at (25,115){\text{67}};
\node at (35,115){\text{73}};
\node at (45,115){\text{97}};
}$](https://dxdy-03.korotkov.co.uk/f/6/a/e/6ae1163418c4c761170d514f79eb432782.png "$\tikz[scale=.08]{
\fill[green!90!blue!50] (0,190) rectangle (50,200);
\fill[green!90!blue!50] (0,140) rectangle (50,150);
\fill[green!90!blue!50] (0,110) rectangle (50,120);
\draw[step=10cm] (0,110) grid +(50,120);
\node at (5,225){\text{2}};
\node at (5,215){\text{3}};
\node at (5,205){\text{5}};
\node at (15,205){\text{29}};
\node at (5,195){\text{7}};
\node at (15,195){\text{31}};
\node at (25,195){\text{37}};
\node at (35,195){\text{43}};
\node at (45,195){\text{67}};
\node at (5,185){\text{11}};
\node at (5,175){\text{13}};
\node at (15,175){\text{37}};
\node at (25,175){\text{43}};
\node at (5,165){\text{17}};
\node at (15,165){\text{41}};
\node at (25,165){\text{47}};
\node at (35,165){\text{53}};
\node at (5,155){\text{19}};
\node at (15,155){\text{43}};
\node at (5,145){\text{23}};
\node at (15,145){\text{47}};
\node at (25,145){\text{53}};
\node at (35,145){\text{59}};
\node at (45,145){\text{83}};
\node at (5,135){\text{29}};
\node at (15,135){\text{53}};
\node at (25,135){\text{59}};
\node at (5,125){\text{31}};
\node at (5,115){\text{37}};
\node at (15,115){\text{61}};
\node at (25,115){\text{67}};
\node at (35,115){\text{73}};
\node at (45,115){\text{97}};
}$")
способов выбрать 5 кубиков из 25 и всего лишь 3 набора подходят. А вдруг понадобится искать такие наборы среди бо́льших чисел? Нет ли способа ускорить поиск, не перебирая все кубики с номером меньше определённого в качестве кандидата на первую позицию?
.
по модулю 
равен 
равен 
равен 
.