Перевести код С++ в код на Ассемблере (Ассемблерная вставка для С++)

@bedvit · Регистрация: 20.05.2016

Студворк — интернет-сервис помощи студентам

Приветствую знатоков!
Трудоемко ли перевести код функции Func под ассемблерную вставку (в Visual Studio через __asm (?))
Код на С++ прилагаю. Будет ли прирост производительности?

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 unsigned long long n=0; //глобальные переменные
    unsigned long long an=0;
    unsigned long long lim=0;
    unsigned int k=1;
    vector<unsigned long long> a;
    int threadsN; 
 
    void Func(int start)
    {
        unsigned long long m = n;
        for (unsigned long long x = start; x <= lim; x = x + threadsN)
        {
            unsigned long long ax = a[x];
            unsigned long long r = an - ax - 1;
            while (a[m] > r) m--;
            unsigned long long z = x * 12599/10000;
 
            for (unsigned long long y = x; y <= m; y++)
            {
                unsigned long long z3 = ax + a[y] + 1;
 
                for (unsigned long long az = a[z]; az <= z3; z++, az = a[z])
                {
                    if (az == z3) printf("%u  %llu  %llu  %llu\n", k++,x,y,z);
                }
            }
        }
 
    }

Благодарю.

ФедосеевПавел · 19.04.2017, 23:03

Если вопрос

Сообщение от bedvit

Будет ли прирост производительности?

То ответ - незначительный.
Т.к. современные компиляторы (особенно от MicroSoft и в большей степени от Intel) оптимизируют код до неузнаваемости. И в реалии могут не создавать переменные в памяти, используя регистры. Т.е. то, на чём можно было получить ускорение раньше.

Прирост может получиться при использовании расширенных команд процессора SIMD - для обработки массивов одной командой - т.е. удалением циклов.

Но наибольший прирост даёт изменение алгоритма.

Обработка целочисленного массива: заполнение по формуле, вычисление суммы, изменение элементов по правилу.

Ну и вообще, поискать по разделу AVX, SSE и прочее.

@Manowar · 20.04.2017, 00:48

Сообщение от ФедосеевПавел

Но наибольший прирост даёт изменение алгоритма.

Здесь на мой взгляд алгоритм очень оптимальный. Делал его в лоб, получилась голимая шняга. А вообще ТС не мешало бы дать ссылку на раздел C++ где эта тема разбиралась, это намного упростило понимание проблемы.

Сообщение от ФедосеевПавел

SIMD - для обработки массивов одной командой - т.е. удалением циклов.

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

Сообщение от ФедосеевПавел

Ну и вообще, поискать по разделу AVX, SSE и прочее.

Как раз здесь и есть куча циклов без которых никак, иначе весь оптимальный алгоритм напрочь рушится.
Пробовал как и обещал ТС перевести это все на AVX (с горяча, когда еще не разбирался в алгоритме), но с таким количеством циклов и проверок приходится все делать через такие костыли что вся прелесть AVX махом улетучивается. Становится еще хуже, да и программа увеличится до неизвестных размеров.
bedvit, Вы же не зря компилировали ее (прога в C#) в "Сборка Debug x64" и получили самый быстрый результат. То же самое получается (чуть быстрее работает) если компилировать прогу c++ в "Release x64". Только в плюсах она получается в 32 кило, а у Вас в 7. Лазить по ним отладчиком что бы узнать в чем разница и что там компилятор напихал вряд ли кто будет.
Единственное что при отладке, как и советовал nmcf, пробежался по дизассемблированному коду. Как и ожидалось компилятор использовал 64 битные регистры (не FPU, mmx, sse и т.д), а именно 64 разрядные, так как посчитал, что для переменных long long это будет самый оптимальный вариант. Единственное чтобы предложил - это написать данную функцию на ассемблере для 64 регистров и присоединить получившийся объектник к проекту. (Читал, что использовать 64 битные регистры в ассемблерных вставках нельзя, но сам еще не сталкивался). Но думаю, как и сказал ФедосеевПавел, прирост в производительности будет незначительный. Да и объектник в проект C#, наверное вставить можно. Если да, то сравнивать эти два языка на данном примере вообще будет лишено смысла.

@bedvit · 20.04.2017, 10:52 **[ТС]**

мановар, благодарю за проделанную работу!
Ссылка на тему проекта. В текущей теме нет цели сравнивать языки, здесь ТС хотелось бы понять эффективность ассемблерной вставки на конкретном примере, заодно и получить новые знания в этом направлении.
Ассемблерную вставку вставить в С++ - можно, в С# - нельзя, но можно подключить неуправляемую dll (ИМХО)

Сообщение от мановар

использовать 64 битные регистры в ассемблерных вставках нельзя

это печально, надо почитать.
Какой профит тогда от ассемблерных вставок? если можно на С++ указать компилятору на макс. оптимизацию в настройках проекта, а в С# работать через небезопасный код (unsafe) .

Добавлено через 11 минут
ФедосеевПавел, а компилятор Microsoft Visual Studio 2017 для С++ насколько хорошо оптимизирует код, в сравнении с вами описанными (возможно у вас есть информация)? судя по результатам мановар, используются 64 разрядные регистры, но в не оптимальном виде?

@Ol44 · 20.04.2017, 16:51

Какая-то мелкая программулинка и если указанные выше компиляторы выдают 7 и даже 32 кб, остаётся только громко улыбнуться таким оптимизациям

@Manowar · 20.04.2017, 19:36

Сообщение от Ol44

остаётся только громко улыбнуться таким оптимизациям

Дык все уж от Майкрософт давно ржут.

@bedvit · 21.04.2017, 10:08 **[ТС]**

Выходит ассемблер здесь мало может помочь в оптимизации (в виде вставки), работы много, толку мало?

ФедосеевПавел · 21.04.2017, 22:14

А я правильно понимаю, что в тексте a[i] - это отсортированный массив кубов целых чисел. Может быть организовать поиск в нём не последовательным просмотром (строка 15), а бинарным поиском. Помню, на задаче "ожерелье" при помощи перебора - это кардинально сокращало время.

Добавлено через 2 минуты
А на размер итогового exe не смотрите. Сам код в этом файле может занимать не очень много места (при маленьких программах).

Добавлено через 6 минут
Да и в строках 22-25 вижу последовательный перебор - опять напрашивается двоичный поиск.

Причём, если можно до начала поиска оценить левую и правую границы - можно это использовать.

@Jin X · 22.04.2017, 13:30

bedvit, хорошо бы посмотреть листинг получаемого кода на ассемблере, тогда, вероятно, будет проще найти места, которые можно оптимизировать.
Например, вот это: unsigned long long z = x * 12599/10000; наверняка можно оптимизировать через замену на unsigned long long z = x * 82570/65536; (или unsigned long long z = x * 82570 >> 16;). Да, именно 82570, а не 82569, так будет даже точнее.

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

Добавлено через 9 минут
Кстати, участок деления на асме можно написать ещё точнее и с меньшим кол-вом сдвигов (т.е. быстрее):

Assembler
1
2
3
4
mov eax,2705659852
mul X
shld edx,eax,1
mov Y,edx  // а если бы edx использовался как Y, можно было бы эту инструкцию и не выполнять

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

Добавлено через 3 минуты
А ещё быстрее будет, если между mov и mul, а также между mul и shld + между shld и mov будет что-то вставлено, не меняющее eax и edx, тогда эти инструкции могут быть спарены с другими. Скажем, разбавить этот код предыдущими строками (ax = , r = , while...)

@bedvit · 24.04.2017, 13:13 **[ТС]**

ФедосеевПавел, все правильно понимаете.
Для лучшего понимания, поясню для чего всё это

Первичная задача - рассчитать переменные для решения уравнения x ^ 3 + y ^ 3 = z ^ 3 - 1
в задаваемом диапазоне (натуральные числа).
Реализация: Мах. границу диапазона вводит пользователь - только натуральные числа (минимальная всегда 1). Далее строится массив (вектор) степеней этих чисел (до макс.границы). Далее в отдельных потоках (зависит от количества лог. ядер ЦП), запускается числодробилка -Func(), которая из этого массива/вектора подбирает варианты когда они удовлетворяют уравнению и выводит в консоль (в main() переменные не возвращаются, но есть глобальные переменные - общие для потоков)
Ветка с зеркальными вариантами х,у обрезается. Обрезаются итерации - которые заведомо не дадут нужного результата.
Каждый поток считает с шагом по массиву/вектору числа самих потоков - threadsN (очень хорошо и равномерно парраллелится).
вот алгоритм на С++

Кликните здесь для просмотра всего текста

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
//поиск переменных для решения уравнения x^3 + y^3 = z^3 - 1
#include "stdafx.h"
#include <string>
#include <vector>
#include <iostream>
#include <thread>
#include <stdio.h>
using namespace std;
        unsigned long long n=0;
    unsigned long long an=0;
    unsigned long long lim=0;
    unsigned int k=1;
    vector<unsigned long long> a;
    int threadsN; //задать количество потоков
 
    void Func(int start)
    {
        unsigned long long m = n;
        for (unsigned long long x = start; x <= lim; x = x + threadsN)
        {
            unsigned long long ax = a[x];
            unsigned long long r = an - ax - 1;
            while (a[m] > r) m--;
            unsigned long long z = x * 12599/10000;
 
            for (unsigned long long y = x; y <= m; y++)
            {
                unsigned long long z3 = ax + a[y] + 1;
 
                for (unsigned long long az = a[z]; az <= z3; z++, az = a[z])
                {
                    if (az == z3) printf("%u  %llu  %llu  %llu\n", k++,x,y,z);
                }
            }
        }
    }
 
int main()
{
    string s;
    threadsN = thread::hardware_concurrency();
    wcout << wstring(L"Enter the maximum value of the variables for equation (x ^ 3 + y ^ 3 = z ^ 3 - 1), followed by <Enter>:\n") << endl;
    getline(cin, s);
    n = stoll(s);
    unsigned int start_time = clock(); // начальное время
    an = n * n * n;
    
    a = vector<unsigned long long>(n + 1);
    lim = static_cast<unsigned long long>(pow((an - 1) / 2, 1.0 / 3));
 
    for (unsigned long long j = 1; j <= n; j++) a[j] = j * j * j;
 
    vector<thread> thr(threadsN);
    for (int i = 1; i <= threadsN; i++) thr[i-1] = thread(Func, i);
    for (int i = 1; i <= threadsN; i++) thr[i-1].join();
    
    unsigned int end_time = clock(); // конечное время
    unsigned int search_time = end_time - start_time; // искомое время
    printf("Time, sec (min): %f (%f)\n", search_time / 1000.0, search_time / 60000.0);
    system("pause");
    return 0;
    }

т.к. 99% вычислений - это числодробилка (функция Func), то её и решил оптимизировать с помощью ассемблерной вставки (пишу в visual studio)

Сообщение от Jin X

листинг получаемого кода на ассемблере

, мало знаний на данный момент, как это сделать в студии (?).
unsigned long long z = x * 12599/10000 - отсекает заведомо лишние ветви вычислений (сжимая область поиска в массиве/векторе).
Jin X, по причине своих небольших знаний в данном направлении, понял в вашем сообщении не всё

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

Добавлено через 20 минут
Могу написать комментарии построчно к коду.

@Jin X · 24.04.2017, 20:06

Сообщение от bedvit

Могу написать комментарии построчно к коду.

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

Скажем, замена деления (12599/10000) заметно скорость не увеличит, т.к. это самый внешний цикл, он выполняется относительно малое кол-во раз.

Оптимизировать тут можно, скорее, алгоритм. Например, придумать такой вариант, когда можно использовать SSE2, чтобы работать сразу с несколькими числами параллельно. Или сделать так, чтобы память использовалась небольшими участками (может, и сейчас так, не знаю, надо углубляться в алгоритм). Т.е. у нас массив, скажем, из 100 000 чисел. Если мы будет обращаться к нему хаотично, то очень часто будут возникать промахи процессорного кэша (т.к. весь массив в 800 Кб просто не уместится в него... по крайней мере, в L1 и L2). А если обработать сначала 1000 элементов (и больше к ним никогда не возвращаться!), затем ещё 1000 и т.д. (причём, всеми потоками, а не каждым обращаться к разной памяти... ну или раздробить на меньшие блоки, по 256 чисел... хотя для 32 Кб кэша 4 потока по 1000 чисел - это 32000 + ещё немного на всякие переменные и другие приложения, возможно, и хватит, но я бы сделал поменьше, тем более, можем попасться 8-ядерник с 32 Кб кэшем... по 200-400 нормально), то в кэш загрузятся сначала первые 1000 чисел (и при многократном использовании эти 1000 чисел будут читаться из массива гораздо быстрее, чем при хаотичном обращении ко всему массиву... под хаотичном я подразумеваю и последовательное), затем следующие 1000. И работа будет идти быстрее.
По-другому ещё объясню. Если прочитать большой массив последовательно 1000 раз подряд, это будет медленнее, чем прочитать каждое число 1000 раз подряд, а потом переходить к следующему числу. Ну или читать порциями: сначала 1000 чисел 1000 раз подряд, затем следующие 1000 чисел 1000 раз подряд. Это будет быстрее, чем читать весь массив последовательно 1000 раз подряд

По алгоритмам можно кинуть тему в Алгоритмы, например...

Но самый большой прирост скорости будет от перехода на 64 бита (если сейчас прога работает на 32-х). Ну и от перехода с конфигурации Debug на Release (если вдруг...).
Остальное существенного прироста не даст.

@bedvit · 25.04.2017, 13:19 **[ТС]**

Решил глянуть файл ассемблерного кода, который компилятор студии сделал.
25 тыс. строк (с машинным кодом - 35 тыс.строк). Не профессионалу (как мне) полжизни разгребать.
Какие-то куски опознаю, какие-то нет.

Сообщение от Jin X

на 64 бита

- так точно

unsigned long long - это и есть int64 без знаковый, что бы больший диапазон влез. Понятное дело Release, оптимизация в С++ компиляторе - максимальная.
На данном алгоритме максимальная граница диапазона (2^64)^(1/3)-1 = 2 642 245
Посчитал, получил - 93 решения.

Кликните здесь для просмотра всего текста

1	6	8	9
2	71	138	144
3	135	138	172
4	372	426	505
5	426	486	577
6	242	720	729
7	566	823	904
8	791	812	1010
9	236	1207	1210
10	575	2292	2304
11	1938	2820	3097
12	2676	3230	3753
13	1124	5610	5625
14	2196	5984	6081
15	1943	6702	6756
16	1851	8675	8703
17	1943	11646	11664
18	7676	11903	12884
19	3318	16806	16849
20	10866	17328	18649
21	3086	21588	21609
22	3453	24965	24987
23	17328	27630	29737
24	4607	36840	36864
25	28182	31212	37513
26	10230	37887	38134
27	25765	33857	38239
28	31212	34566	41545
29	7251	49409	49461
30	34199	46212	51762
31	6560	59022	59049
32	15218	66198	66465
33	29196	66167	68010
34	54101	56503	69709
35	32882	69479	71852
36	51293	64165	73627
37	17384	78244	78529
38	8999	89970	90000
39	58462	87383	95356
40	75263	94904	108608
41	84507	89559	109747
42	99800	104383	128692
43	11978	131736	131769
44	81404	130119	139974
45	86103	153422	161976
46	93066	152526	163297
47	15551	186588	186624
48	146996	204290	227033
49	105570	237095	243876
50	19772	257010	257049
51	152526	249972	267625
52	120039	275616	283006
53	57055	339590	340126
54	24695	345702	345744
55	113208	342719	346788
56	289511	331954	393316
57	315750	340623	414082
58	151499	434305	440365
59	293999	403346	449846
60	30374	455580	455625
61	36863	589776	589824
62	257118	664572	677161
63	197144	708282	713337
64	44216	751638	751689
65	309874	746831	764206
66	283896	815498	826809
67	658625	743413	886447
68	375703	902654	923848
69	52487	944730	944784
70	311999	1052540	1061600
71	386559	1076664	1093024
72	61730	1172832	1172889
73	926271	951690	1183258
74	342648	1240119	1248778
75	595815	1224516	1269838
76	294241	1298345	1303363
77	971298	1159352	1352601
78	71999	1439940	1440000
79	942902	1309108	1455241
80	1150782	1388672	1613673
81	1077936	1568978	1722969
82	664572	1717710	1750249
83	83348	1750266	1750329
84	1557846	1724442	2073025
85	95831	2108238	2108304
86	270036	2174679	2176066
87	585335	2198374	2212120
88	1724442	1908852	2294713
89	717383	2345915	2368067
90	802863	2342519	2373543
91	1460926	2185247	2384230
92	126384	2418902	2419017
93	109502	2518500	2518569

Размер массива/вектора - 2 642 245 элементов.
Количество итераций - 346 331 120 300
Время выполнения 15,9 мин.
ПК:

Кликните здесь для просмотра всего текста

Тип ЦП QuadCore Intel Core i7-3770, 3700 MHz (37 x 100)
Системная память 8156 МБ (DDR3-1333 DDR3 SDRAM)

Добавлено через 1 час 34 минуты
8 логических ядер - 8 потоков.

@Jin X · 25.04.2017, 13:49

Ну, может, тогда просто забить это всё в массив и выдавать результат в нужном диапазоне?
Это будет самая лучшая оптимизация скорости

@bedvit · 25.04.2017, 16:12 **[ТС]**

Сообщение от Jin X

просто забить это всё в массив и выдавать результат в нужном диапазоне

Так же хотел запилить вычисления числа "Пи", до миллионного знака, но .exe весить стал неприлично много.

Не по теме:

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

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

Добавлено через 11 минут
Можно конечно и дальше считать, но тогда нужно подключать длинную арифметику. Есть и библиотеки mpir, но это сразу снизит скорость вычисления, да и никто не оценит.

@Jin X · 25.04.2017, 18:09

Дальше замучаешься ждать просто...

Сообщение от bedvit

Так же хотел запилить вычисления числа "Пи", до миллионного знака, но .exe весить стал неприлично много.

Загрузить в интернет и качать оттуда, типа вычисляет

А вообще, млн знаков можно в ≈400 Кб (с небольшим) запросто засунуть. Если каждые 3 цифры запихивать в 10 бит (число от 0 до 1023) или 12 цифр в 40 бит (равно 5 байт). Будет сжатие даже лучше, чем у 7z и rar5

Добавлено через 27 минут
У меня есть число Пи до 1 млрд знаков после запятой, числа Фи и e с точностью до 500 млн+1 знаков (вычислено с помощью Wolfram Mathematica 9.0). Если что, обращайтесь!

@Manowar · 25.04.2017, 18:23

Сообщение от Jin X

У меня есть число Пи до 1 млрд знаков после запятой,

1 011 196 691 знаков — братья Чудновские, США, 1989 г. (IBM 3090, на базе формулы С. Рамануджана)

@Jin X · 25.04.2017, 19:29

мановар, ну вот... как теперь жить дальше?

Скажи, что это неправда!

@bedvit · 25.04.2017, 19:42 **[ТС]**

мановар, Jin X, к сожалению так:
19 октября 2011 года Александр Йи и Сигэру Кондо рассчитали последовательность с точностью в 10 триллионов цифр после запятой персональном ПК!
см.здесь

Кликните здесь для просмотра всего текста

НА персональном ПК - два шестиядерных процессора Intel Xeon X5680 (3,33 ГГц). Также были установлены 96 гигабайт оперативной памяти и 30 жестких дисков общим объемом 59 терабайт. Для нового рекорда пришлось добавить 10 жестких дисков.
Оригинал новости находится в интернет-журнале «iScience» (iScience.ru): http://iscience.ru/2011/10/20/... ya-%CF%80/

Не по теме:

Голландский математик Брауэр в первой половине XX века привёл в качестве примера бессмысленной задачи поиск в десятичном разложении ПИ последовательности 0123456789 — по его мнению, нужная для этого точность никогда не будет достигнута. В конце XX века эта последовательность была обнаружена, она начинается с 17 387 594 880-го знака после запятой. Википедия

@Manowar · 25.04.2017, 19:46

Сообщение от Jin X

ну вот... как теперь жить дальше?

Копить на процессоры, оперативку и жесткачи. И вперед, к новым рекордам.

@bedvit · 25.04.2017, 20:24 **[ТС]**

А так же купить кондей и готовится к счетам за свет ))

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Web (WebAssembly): Реализация движения на Box2D v3 - трение и коллизии с повёрнутыми стенами 8Observer8 20.02.2026 Содержание блога Box2D позволяет легко создать главного героя, который не проходит сквозь стены и перемещается с заданным трением о препятствия, которые можно располагать под углом, как верхнее. . .	Конвертировать закладки radiotray-ng в m3u-плейлист damix 19.02.2026 Это можно сделать скриптом для PowerShell. Использование . \СonvertRadiotrayToM3U. ps1 <path_to_bookmarks. json> Рядом с файлом bookmarks. json появится файл bookmarks. m3u с результатом. # Check if. . .	Семь CDC на одном интерфейсе: 5 U[S]ARTов, 1 CAN и 1 SSI Eddy_Em 18.02.2026 Постепенно допиливаю свою "многоинтерфейсную плату". Выглядит вот так: https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11617&stc=1&d=1771445347 Основана на STM32F303RBT6. На борту пять. . .	Камера Toupcam IUA500KMA Eddy_Em 12.02.2026 Т. к. у всяких "хикроботов" слишком уж мелкий пиксель, для подсмотра в ESPriF они вообще плохо годятся: уже 14 величину можно рассмотреть еле-еле лишь на экспозициях под 3 секунды (а то и больше),. . .
И ясному Солнцу zbw 12.02.2026 И ясному Солнцу, и светлой Луне. В мире покоя нет и люди не могут жить в тишине. А жить им немного лет.	«Знание-Сила» zbw 12.02.2026 «Знание-Сила» «Время-Деньги» «Деньги -Пуля»	SDL3 для Web (WebAssembly): Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 12.02.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами и вызывать обработчики событий столкновения. . . .	SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 11.02.2026 Содержание блога Библиотека SDL3 содержит встроенные инструменты для базовой работы с изображениями - без использования библиотеки SDL3_image. Пошагово создадим проект для загрузки изображения. . .

@Ol44 197 / 89 / 15 Регистрация: 10.07.2016 Сообщений: 146
	20.04.2017, 16:51
	Какая-то мелкая программулинка и если указанные выше компиляторы выдают 7 и даже 32 кб, остаётся только громко улыбнуться таким оптимизациям 0

@bedvit 1209 / 260 / 22 Регистрация: 20.05.2016 Сообщений: 1,139 Записей в блоге: 22
	21.04.2017, 10:08 [ТС]
	Выходит ассемблер здесь мало может помочь в оптимизации (в виде вставки), работы много, толку мало? 0

ФедосеевПавел Модератор 8659 / 4494 / 1669 Регистрация: 01.02.2015 Сообщений: 13,905 Записей в блоге: 12
	21.04.2017, 22:14
	А я правильно понимаю, что в тексте a[i] - это отсортированный массив кубов целых чисел. Может быть организовать поиск в нём не последовательным просмотром (строка 15), а бинарным поиском. Помню, на задаче "ожерелье" при помощи перебора - это кардинально сокращало время. Добавлено через 2 минуты А на размер итогового exe не смотрите. Сам код в этом файле может занимать не очень много места (при маленьких программах). Добавлено через 6 минут Да и в строках 22-25 вижу последовательный перебор - опять напрашивается двоичный поиск. Причём, если можно до начала поиска оценить левую и правую границы - можно это использовать. 1

@Jin X Asm/C++/Delphi/Py/PHP/VBA 6812 / 2052 / 238 Регистрация: 14.12.2014 Сообщений: 4,305 Записей в блоге: 12
	25.04.2017, 13:49
	Ну, может, тогда просто забить это всё в массив и выдавать результат в нужном диапазоне? Это будет самая лучшая оптимизация скорости 0

@Jin X Asm/C++/Delphi/Py/PHP/VBA 6812 / 2052 / 238 Регистрация: 14.12.2014 Сообщений: 4,305 Записей в блоге: 12
	25.04.2017, 19:29
	мановар, ну вот... как теперь жить дальше? Скажи, что это неправда! 0

@bedvit 1209 / 260 / 22 Регистрация: 20.05.2016 Сообщений: 1,139 Записей в блоге: 22
	25.04.2017, 19:42 [ТС]
	мановар, Jin X, к сожалению так: 19 октября 2011 года Александр Йи и Сигэру Кондо рассчитали последовательность с точностью в 10 триллионов цифр после запятой персональном ПК! см.здесь Кликните здесь для просмотра всего текста НА персональном ПК - два шестиядерных процессора Intel Xeon X5680 (3,33 ГГц). Также были установлены 96 гигабайт оперативной памяти и 30 жестких дисков общим объемом 59 терабайт. Для нового рекорда пришлось добавить 10 жестких дисков. Оригинал новости находится в интернет-журнале «iScience» (iScience.ru): http://iscience.ru/2011/10/20/... ya-%CF%80/ Не по теме: Голландский математик Брауэр в первой половине XX века привёл в качестве примера бессмысленной задачи поиск в десятичном разложении ПИ последовательности 0123456789 — по его мнению, нужная для этого точность никогда не будет достигнута. В конце XX века эта последовательность была обнаружена, она начинается с 17 387 594 880-го знака после запятой. Википедия 1

@bedvit 1209 / 260 / 22 Регистрация: 20.05.2016 Сообщений: 1,139 Записей в блоге: 22
	25.04.2017, 20:24 [ТС]
	А так же купить кондей и готовится к счетам за свет )) 0