Первые и последующие шаги в ассемблере x86/x64

[Dmitriy40]

Yadryara в сообщении #1625912 писал(а):

Dmitriy40 в сообщении #1625911 писал(а):

сподвигнуть меня помочь в этом странном начинании.

Странном? А кто говорил про выигрыш в скорости в сотни, а то и в тысячи раз?

Это относительно тормозного PARI/GP можно получить сотни и тысячи раз (я же получаю как Вам известно), а относительно более нормальных языков типа C/C++ ускорение будет в разы, максимум для некоторых специфичных задач несколько десятков раз (это уже сомнительно). А при использовании технологии gp2c и скорость PARI/GP программ можно приблизить к скорости С программ, те. выигрыш асма будет до десятка раз. Стоит ли оно того - каждый решает сам. Мне асм просто нравится. Не только выигрышем скорости, но и практически полным контролем над происходящим, меня привлекает как там (в компе, проце, видюхе, и т.д.) всё внутри крутится-вертится (например процессоры интересны вплоть до уровня отдельных транзисторов, что программированию не помогает никак).

[Yadryara]

Dmitriy40 в сообщении #1625956 писал(а):

Ребята, стоп-стоп-стоп.
Эта тема- - лишь вопрос, понять надо ли оно вообще. И в каком объёме. И с чего начать.

Тогда надо было в "Работе форума" тему создавать. А так обсуждение уже пошло прямо здесь.

worm2 в сообщении #1625959 писал(а):

Поэтому ассемблер в данном случае не будет сильно выигрывать у Си.

Что такое сильно? Даже двукратный выигрыш — это полгода счёта вместо года.

worm2 в сообщении #1625959 писал(а):

Вы, вероятно, выбрали 100 миллиардов, чтобы в оперативную память современного домашнего компьютера решето Эратосфена такого размера не поместилось.

Счёт в реальной задаче 19-252, которую Dmitriy40 решает уже почти год, добрался примерно до высоты $10^{24}$. Так что более актуальным будет диапазон $10^{24}+10^{11-12}$.

[Dmitriy40]

Yadryara в сообщении #1625972 писал(а):

Тогда надо было в "Работе форума" тему создавать. А так обсуждение уже пошло прямо здесь.

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

Yadryara в сообщении #1625972 писал(а):

Что такое сильно? Даже двукратный выигрыш — это полгода счёта вместо года.

Зависит от задачи. Бывает что и недели хватит, а тут уж разница между неделей и парой дней - быструю прогу на асме часто писать дольше недели (при том что на скажем С хватит дня-двух). А про время изучения асма я высказался выше, может и года не хватить (мне пара идей ускорения приходила спустя годы занятий другим, а некоторые идеи и до сих пор не реализовал) и будет проще подключить друзей с компами (не говоря уж про боинк) для помощи в вычислениях чем изучать асм. Я не отговариваю, но надо понимать риски и возможности. И свои желания.

worm2
Насчёт скорости посмотрите табличку и текст под ней здесь, там в формате "1:25260" приведено какая доля от всех чисел реально проверяется.

[worm2]

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

[talash]

Yadryara в сообщении #1625946 писал(а):

talash в сообщении #1625936 писал(а):

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

Чтобы развеять сомнения предлагаю Вам написать на Сях решение такой задачи.

Вот есть сплошная 5-ка простых чисел:

$76883 \quad 76907 \quad 76913 \quad 76919 \quad 76943$

Как видим, гэпы здесь такие: $24-6-6-24$. Найдите все такие 5-ки, скажем, от 0 до 100 ярдов.

Прикладываю программу, писал её BingAI. К сожалению, с косяками, какие-то из них поправил чтобы заработало, но возможно не все. Проверил у себя на компе, до 100 ярдов слишком долго считать, до 10 ярдов пару минут. Памяти хватает, если побитово хранить числа. Вот первые и последние результаты:

76883, 76907, 76913, 76919, 76943
516847, 516871, 516877, 516883, 516907
956083, 956107, 956113, 956119, 956143
1056287, 1056311, 1056317, 1056323, 1056347
1428863, 1428887, 1428893, 1428899, 1428923
1440853, 1440877, 1440883, 1440889, 1440913
...
9995927033, 9995927057, 9995927063, 9995927069, 9995927093
9996373003, 9996373027, 9996373033, 9996373039, 9996373063
9996848647, 9996848671, 9996848677, 9996848683, 9996848707
9997886383, 9997886407, 9997886413, 9997886419, 9997886443
9999105607, 9999105631, 9999105637, 9999105643, 9999105667
9999568063, 9999568087, 9999568093, 9999568099, 9999568123

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

const unsigned long long BILLION = 1000000000;
const unsigned long long MAX(10 * BILLION);

char *sieve;

#define ISCOMPOSITE(n) (sieve[n >> 3] & (1 << (n & 7)))
#define SETCOMPOSITE(n) sieve[n >> 3] |= (1 << (n & 7))

void eratosthenes() {
    unsigned long long i, j;
    memset(sieve, 0, MAX/8);
    for (i = 2; i * i <= MAX; i ++)
    {
        if (!ISCOMPOSITE(i))
        {
            for (j = i; j <= MAX; j += i)
                SETCOMPOSITE(j);
        }
    }
}

void find_quintuplets() {
    unsigned long long i, j;
    for (i = 0; i <= MAX - 60; i++)
    {
        if (!ISCOMPOSITE(i) && !ISCOMPOSITE(i + 24) && !ISCOMPOSITE(i + 30) && !ISCOMPOSITE(i + 36) && !ISCOMPOSITE(i + 60))
        {
            for (j = i+1; j < i + 60; j++)
            {
                if (j == i + 24 || j == i + 30 || j == i + 36)
                {
                    continue;
                }
                if (!ISCOMPOSITE(j))
                {
                    break;
                }
            }
            if (j == i + 60)
            {
                printf("%llu, %llu, %llu, %llu, %llu\n", i, i + 24, i + 30, i + 36, i + 60);
            }
        }
    }
}

int main() {
    sieve = (char*)malloc(MAX / 8 + 1);
    eratosthenes();
    find_quintuplets();
    return 0;
}

-- 15.01.2024, 18:04 --

Почитал предыдущие комменты. BingAI через решето Эратосфена сделал программу. Так что тут не оптимально, но не из-за языка программирования, а сам алгоритм.

[Yadryara]

talash

BingAI это круто! А теперь спросим что скажет по поводу этой скорости Dmitriy40.

Вы не указали количество таких 5-к до 10 ярдов, но может это и к лучшему.

[talash]

Yadryara в сообщении #1625989 писал(а):

Вы не указали количество таких 5-к до 10 ярдов

Quintuplets count: 11535

[Dmitriy40]

(Сравнение скорости)

Yadryara в сообщении #1625989 писал(а):

А теперь спросим что скажет по поводу этой скорости Dmitriy40.

Не буду я ничего говорить. Скорость решета Эратосфена известна всем кто в теме:

C:\>primesieve.x64con.exe 0 -d10e9 -c1 -t1
Sieve size = 128 KiB
Threads = 1
100%
Seconds: 1.615

Проверка найденных простых на совпадение с паттерном из 5-ти чисел займёт проценты времени. Разницу "пары минут" и двух секунд все посчитают сами.

Кроме того приведённая прога явно не оптимальна минимум по двум причинам:
1. Можно не проверять и не хранить чётные числа.
2. Вместо логических операций проверки и сброса бита у процов есть команды bt/btr, по моим тестам они в этой задаче дают примерно двухкратное ускорение. Покажите мне компилятор ЯВУ который их сам подставит?!

Скорость своей программы я быстро оценить не могу (надо убирать часть проверок): она заточена под поиск редких решений (длинных цепочек/паттернов), а не тысяч и десятков тысяч в секунду.
Зато за две с половиной минуты с задачей справляется и тормозной PARI/GP (конечно не решетом, а поиском по паттерну с коэффициентом 1:192 и памятью порядка 10МБ).

[Yadryara]

talash, а BingAI понимает, что значит искать по паттерну с кэфом 1:192 ? А Вы?

[Dmitriy40]

Yadryara
Давайте всё же ограничимся заявленной темой о нужности специальной темы о помощи с асмом, а? И BringAI и кэфы и так есть где обсудить.

[talash]

Dmitriy40 в сообщении #1625993 писал(а):

C:\>primesieve.x64con.exe 0 -d10e9 -c1 -t1
Sieve size = 128 KiB
Threads = 1
100%
Seconds: 1.615

Проверка найденных простых на совпадение с паттерном из 5-ти чисел займёт проценты времени. Разницу "пары минут" и двух секунд все посчитают сами.

Это мощно, а 100 ярдов за сколько считает?

Я тоже посчитал 100 ярдов. Но просто ради интереса. Понятно, что со спецами тут не потягаешься.

...
99995882387, 99995882411, 99995882417, 99995882423, 99995882447
99999136063, 99999136087, 99999136093, 99999136099, 99999136123
99999278227, 99999278251, 99999278257, 99999278263, 99999278287
Quintuplets count: 86543

-- 15.01.2024, 21:24 --

Yadryara в сообщении #1625994 писал(а):

talash, а BingAI понимает, что значит искать по паттерну с кэфом 1:192 ? А Вы?

Вряд ли BingAI что-то сложнее хорошо сделает, он даже в поиске паттерна затупил, не учёл ситуации, когда простые числа не соседние и добавил лишние паттерны, я это починил сам костылём. Однако, большую часть кода написал правильно, не пришлось самому выписывать все эти нюансы с побитовой адресацией. Я бы и поленился сам), так что помощь от AI уже существенная, но нужен контроль.

Я тоже в теории чисел мало понимаю.

-- 15.01.2024, 21:25 --

Dmitriy40 в сообщении #1625998 писал(а):

Давайте всё же ограничимся заявленной темой о нужности специальной темы о помощи с асмом, а? И BringAI и кэфы и так есть где обсудить.

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

[Dmitriy40]

(Скорость решета)

talash в сообщении #1626011 писал(а):

Это мощно, а 100 ярдов за сколько считает?

Достаточно очевидно что примерно в 10 раз дольше:

C:\>primesieve.x64con.exe 0 -d100e9 -c1 -t1
Sieve size = 128 KiB
Threads = 1
100%
Seconds: 20.419

Для решета Эратосфена скорость падает не от размера интервала, а от того где он расположен: одно дело если он около нуля, совсем другое около $10^{19}$:

C:\>primesieve.x64con.exe 1e19 -d100e9 -c1 -t1
Sieve size = 128 KiB
Threads = 1
100%
Seconds: 90.842

Это не моя программа, сайт https://github.com/kimwalisch/primesieve, одна из самых быстрых, очень хорошо оптимизированная программа, причём оптимизация разная в разных диапазонах ($<10^{12}, <10^{15}, >10^{15}$ если не ошибаюсь). Мои программы проигрывают ей в скорости раза 2-3 (мне лень оптимизировать в разных диапазонах, потому всегда где-то меньше, где-то больше).

[Dmitriy40]

Модератор посчитал что здесь теме место лучше.
Тогда готов ответить и на какие-то практические вопросы по ассемблеру, но без углубления в теорию или пересказа больших кусков книг (или вики). В общем задавайте если есть, но подробного ответа не обещаю.
Эта тема остаётся в основном организационная. Но не исключительно.

Ещё набросал "план мероприятий" (типа roadmap) по теме, получилось пара страниц текста, это ещё даже не введение в асм, лишь что, как и когда планирую рассказать. Выложу тут (как допишу, сегодня-завтра) и прошу заинтересованных покритиковать, что можно и нужно пропустить, что расширить, что переставить местами, что забыл. Кто не собирается изучать ассемблер или "лишь почитать" прошу не разводить холивар, я не гуру и пишу не учебник, многие моменты весьма спорны, какие-то готов аргументировать, какие-то "просто так (не) хочу/привык". Но прислушаться к мнению готов.
Указанные выше книги чуть позже внимательно посмотрю на предмет возможных отсылок к ним за дополнительной подробной информацией. Буду рад если накидаете ещё хороших книг (только на русском) и по ассемблеру (современному, как минимум с SSE, а лучше и AVX) и по оптимизации. Видеоуроки (ютуб и иже с ним) - в топку.

[Dmitriy40]

Итак, вот черновик (ещё пару раз перечитаю и обдумаю) начала новой темы, прошу покритиковать (кроме размера, сам знаю, но короче не получается):

Цитата:

Для кого и о чём эта тема.
Народ выразил желание изучить ассемблер для написания быстрых программ для решения вычислительных задач, причём фактически с нуля. И если книг и (видео)лекций по ассемблеру достаточно, то по оптимизации программ по скорости их гораздо меньше (и многие сильно устарели), а уж про использование для этого технологий векторных вычислений (MMX, SSE, AVX) совсем мало. Во всяком случае на русском.
Основная цель использования ассемблера в данной теме - максимальное повышение скорости счёта. Достаточно узкий класс задач. И речь не про задачи на пару минут или пару часов, а на пару недель или месяцев (а то и лет).
Соответственно все прочие вопросы, как то: ввод/вывод данных (за исключением ввода параметров счёта и вывода результатов), любая графика и звук, веб сайты и любые сетевые технологии (возможно за одним исключением), игры, и многое другое - рассматриваться не будут. Для всего этого есть более удобные языки программирования. К которым можно будет или подключить кусочек на ассемблере ради ускорения нескольких функций, или воспользоваться встроенным ассемблером для тех же нескольких функций.
Когда и как и в каком объёме затрагивать вычисления с плавающей точкой - пока не знаю, это достаточно отдельная большая тема, посмотрим по ходу дела будет ли интерес, насколько я понимаю пока народ интересует ускорение целочисленных вычислений.

Ограничения.
В качестве компилятора ассемблера буду использовать FASM как достаточно современный и бесплатный и компактный и просто мне нравится больше остальных.
Писать будем исключительно под винду, в общем любую, но не старше WinXP (запустится ли под Win2000 вопрос, по идее должно). И не новее Win7 - даже под Win10 всё работать тоже по идее должно, но проверить мне сложно, а про Win11 и новее даже думать не хочу (но опять же, по идее работать должно). Но это и непринципиально так как от ОС зависят лишь служебные куски кода, а вычислительная часть от ОС обычно практически не зависит (обрабатывать терабайты или использовать сеть в любом виде не планирую, это задача более высокого уровня на нормальном языке).
Любые другие ОС в пролёте, и MacOS, и все (под)виды Linux, и Android, и что там ещё в мире существует. Я их просто не знаю в достаточной мере.
В основном все примеры будут под x86 (32-разрядные) так как это более совместимо.
Для иллюстраций буду использовать код на PARI/GP (простой язык, довольно похожий на С, удобный быстро что-то посчитать, плюс для работы нужен всего один файл .exe, плюс его многие здесь уже неплохо знают) и на C (его любой программист должен уметь как минимум читать/понимать) если будет необходимость.
Предполагается что с работой в винде - создать файл с нужным именем и расширением, создать папку, сложить файлы в нужную папку, что такое консоль и права доступа, как запустить файл .exe и мышкой в проводнике и клавиатурой в консоли - человек уже знаком. И отвечать на бесконечные вопросы типа "а куда я сохранил текстовый файл? и как мне его теперь найти?", "а почему .doc или .docx не хотят работать если сказано сохранить в .txt?" и аналогичные не буду, тема про ассемблер, а не работу в винде.
Также предполагаю что человек знает (или сам прочитает) про арифметические операции, про виды кодирования чисел (во введении расскажу про какие надо и где найти), про логические операции и чем они отличаются от арифметических (тоже видимо поясню, но совсем коротко), про основные алгоритмические конструкции (линейный код, условное выполнение, циклы, процедуры, отличие от функций в математике, это всё тоже коротко опишу во введении). Простите но пересказ всего курса информатики я не осилю, и не в этой теме.
WinAPI будет использоваться (по необходимости), но чисто как "заклинания" для того-то и того-то, без подробных разъяснений. Не потяну. Это отдельная огромная тема, много где уже освещена. Да и онлайн справка есть (на английском на сайте MS). Приведу примеры как использовать нужное конкретно под FASM и на этом всё.
MMX упомяну, но описывать и рассматривать не буду, оно устарело.
AVX-512 тоже рассматривать не буду: мне не на чем проверять. И подозреваю заинтересованным товарищам тоже. Да и там по сравнению с AVX/AVX2 сильно изменилась идеология, это может дать дополнительный выигрыш скорости (кроме вдвое шире регистров), но требует и переосмысление кода, и алгоритма, и даже полной смены алгоритмов вычислений. Короче без проверки это утопия. Очень интересная технически, но всё же утопия.
Рассказывать ли про длинную арифметику в общем виде ... Думаю нет. Только коротко несколько практически полезных (в интересных мне и кое-кому ещё) частных случаев. И только ради новых команд процессора и иллюстрации сколько при этом подводных камней.
Темы многозадачности, обработки ошибок (за малым исключением), стресс-тестов и вообще тестирования программ (не специфичные для ассемблера), вообще техники написания (доказуемо) надёжных программ - всё мимо. Это общая информация без привязки к языку программирования. Да моих знаний может оказаться маловато.
Рассказ об отладчиках (а все книги говорят что без него никуда) пока под вопросом, это отдельная программа, встроенный в винду (кстати не факт что есть и в новых) убогий, тот чем пользуюсь сам замороченный. Если включу, то видимо после второго пункта (см. ниже план) отдельным отступлением. А может ограничусь показом как выводить много самой разной статистики и потом анализировать что же там в вашей программе происходит на самом деле.

План мероприятия.
В следующем сообщении предполагаю дать коротко основные базовые сведения для начала работы: что внутри процессоров с точки зрения программиста, как они работают и как ими управлять, зачем нужен язык ассемблера, где взять его компилятор, что он (и процессор и компилятор ассемблера) умеет и главное что он не умеет, как настроить компиляцию своих будущих программ на асме, где смотреть справочную информацию (например список команд процессора), поток выполнения и его изменение, может ещё что-то что вспомню по ходу дела.
В третьем сообщении собственно приступим. После каждого пункта пауза на вопросы и ответы.
1. Разумеется сразу в бой - покажу тестовую программу (вычисление 45-го числа Фибоначчи) и подробно расскажу что, как, зачем и почему она считает. И как вообще записываются команды и прочее.
Либо сразу же, либо в следующем сообщении разберу понятие символического имени для констант и переменных и видимо и варианты их хранения в памяти.
Где-то тут, или по ходу дела, или отдельным сообщением, попробую разобрать возможные ошибки и к чему они приводят.
2. Дальше изменим программу чтобы она считала любое число Фибоначчи до 48-го, причём указываемого в параметрах при запуске. Это добавит две большие (раз в 5 больше всей предыдущей программы) процедуры с кучей новых команд, вот и будем их разбирать, заодно и как процедурами пользоваться. И включаемыми файлами (.inc) чтобы не захламлять код в основном файле.
3. Далее нужно будет сказать об отличиях x64 от x86 и переписать программу под x64 чтобы можно было вычислить числа Фибоначчи до 93-го. Возможно чуть перепишу одну из больших процедур чтобы показать новые команды процессора (более удобные программисту).
4. Если будет запрос на вычисления с плавающей точкой, то тут удобно сделать отступление и переписать программу для вычисления любого числа Фибоначчи по формуле Бине с точностью 17-18 старших цифр. Потребуется дополнение внутреннего устройства процессора (FPU) и новые команды.
5. Дальше удобно рассказать об MMX (чисто в историческом плане), SSE и AVX и переписать программу на SSE и AVX для вычисления одновременно сразу двух и четырёх чисел Фибоначчи. Либо методом суммирования целых (до 93-го даже под x86), либо ещё и по формуле Бине если было про FPU. Куча новых команд ...

Думаю всё выше займёт недели две. И мне надо всё сформулировать и написать, и код написать и проверить, и на вопросы ответить ... Не, думаю быстрее не выйдет. Только если вдруг все желающие всё это уже и так знают.
Здесь сделаю паузу чтобы ответить на вопросы, потренировать в исправлениях программ под разные варианты задачи (что-нибудь непременно придумаю) в виде "домашнего задания", если хорошо пойдёт, то и написать самим что-то простенькое (пока не знаю что, посмотрим). Просто для наработки практики и снижения страха перед великим и ужасным ассемблером.
Займёт это сколько займёт, пока интерес не угаснет или желание идти дальше не пересилит.

Пора приступить к чему-то полезному. Знаю что одной из целью было поиск цепочек простых чисел, вот и займёмся проверкой чисел на простоту. Решето Эратосфена пропустим, оно интересно лишь парой новых команд, а оптимизировать его на данном этапе слишком сложно и непрактично. А кому "очень надо" - есть прекрасные готовые программы в исходных кодах, можно изучать. Быстрее них я сделать не умею (точнее мне терпения не хватает, слишком много надо придумать и реализовать).

6. Проверка числа на простоту. Сначала тупо проверкой делимости. Потом тут же сразу и красивый метод замены медленного деления на быстрое умножение. Понятие о времени выполнения команд (и где смотреть инфу). Разные процессоры и разная скорость одних и тех же команд. И соответственно необходимость разных вариантов кода для разных процессоров. Понятие псевдопростого числа. Тест Ферма и быстрый его вариант. Комбинация разных методов. Варианты под x64 метода с умножениями и теста Ферма. Замеры скорости всех вариантов и сравнение. Как вообще более-менее правильно мерить скорость своих программ.
Очень большой пункт. Наверное на неделю с лишним только рассказа, плюс вопросы и обсуждение ... Зато будет задел для следующих практически полезных пунктов, к чему собственно и хотелось дойти.
7. Поиск цепочек простых чисел. По паттерну (и кратко что это вообще такое). Модулярная арифметика (коротко и только нужное). Сначала поиск с делениями. Потом с умножениями вместо них. Потом с суммированием. Потом векторизация (SSE и AVX). По ходу изложения разные трюки для ускорения, не всегда из книг. Разные варианты кода одного и того же алгоритма и сравнение их скорости.
Тоже очень немаленький пункт. Где-то тут может быть скорость наших программ превысит скорость среднего С кода ... А может и нет, но хотя бы подберётся.
8. Отступление в сторону для практической пользы. Разделение работы между разными программами и языками (использование связки aасм + PARI/GP). Понятие фильтрации кандидатов в решения и выбор глубины (качества, отношения) фильтрации. Примеры деления работы между асмом и PARI и сравнение скорости. Получение .dll вместо .exe для использования в других языках (практически всех, кроме PARI/GP).
9. Если хватит сил, то примеры тонкой оптимизации по скорости для конкретного процессора. И в теории, и на практике (которая тут часто противоречит теории). Наверное здесь и новые возможности FASM введу для сокращения кода и повышения его понятности.
Вероятно тут (почти) доберёмся до реального кода моей программы и достигнем понимания как же он чёрт возьми работает. И хоть занимает буквально 3-4 десятка строк, но для понимания нужно почти все что выше.

Собственно на этом основная цель достигнута.
Займёт это пару-тройку месяцев. Плюс-минус. Впрочем, как известно, любые сроки называемые программистами надо умножать на 3, а для больших проектов (больше недели/месяца) и на 5. Ну, тут больше будет зависеть от собеседников, насколько придётся углубляться в детали или уходить в сторону при ответах.
Дальше в режиме свободного полёта, по вопросам и заявкам трудящихся собеседников, что интересно им.

Как можно заметить совершенно не затронута тема многозадачности/многопоточности. Да. Я её реализую или на другом языке, или на уровне WinAPI, это уже не ассемблер. Спускать её на уровень ассемблера ... извините глупость (или чисто ради развлечения). Мне не хватит ни сил, не желания, ни знаний. Другая не менее важная причина: многозадачность сильно неинтуитивна и требует заметно других навыков написания кода чем были наработаны выше. Да, вот такая засада! Совсем не зря многопоточность (и тем более многозадачность) считается одной из самых трудных для новичков и достойна не меньшей темы. А если на неё наложить ещё и трудности ассемблера ... Не, это без меня. Ну или не здесь.


PS. Может показаться что цель похвалиться своим кодом. Ну, да. На самом деле это просто хороший пример (многолетней!) глубокой оптимизации ассемблерного кода по скорости выполнения. С использованием самых современных возможностей (доступных мне SSE и AVX2). Часть примеров на самом деле не используется (тест Ферма), зато на них удобно показать другие команды процессора и оно полезно практически.
План не окончательный, приветствуются предложения и поправки. Как по сокращению, так и по расширению и углублению.
Вопрос с литературой для отсылок за подробностями пока прорабатывается, что-то очевидно будет, но может на каждый конкретный вопрос хватит и вики.
Где придётся упомянуть наличие и размеры кэшей в процессоре и оптимизацию под них - не знаю, как пойдёт, где понадобится, там и будет. Вообще собираюсь рассказывать про процессор (а без этого никуда) постепенно, только нужные на каждом этапе вещи. И половина (или больше) внутреннего устройства процессора останется вообще за кадром - в данном классе задач оно программисту не нужно, на скорость счёта не влияет.

Пишется это всё для тех 5-ти человек что выбрали второй вариант ответа в опросе (поспрашиваю). Отдельно буду благодарен выбравшему третий вариант (поотвечаю). Выбравшие первый вариант (почитаю) вряд ли найдут для себя что-то новое и полезное, я собираюсь превратить это не в лекцию, а наверное в семинар (рассказ кусочка с примерами и вопросы/обсуждение по нему). Впрочем надеюсь и эти 10 человек примут участие содержательными вопросами или ответами в процессе обсуждения. Двери открыты.
А пока жду критики и пожеланий по существу.

[Yadryara]

Честно говоря, голова закружилась. Мне бы конкретику увидеть.

Dmitriy40 в сообщении #1626119 писал(а):

1. Разумеется сразу в бой - покажу тестовую программу (вычисление 45-го числа Фибоначчи) и подробно расскажу что, как, зачем и почему она считает. И как вообще записываются команды и прочее.

Может быть пока 7-е число, то бишь 13 ? А затем дать задание поправить прогу, чтоб она посчитала 21 и 34.