mayton2019

Судя по скриншоту это windows. Если вы делаете бенчмарки под windows - то нужно правильно мерять время. Скорее всего вы меряли не время цикла а время запуска windows процесса + время цикла. Вместе с статическими конструкторами. И эти конструкторы в go оказались удачнее.

Короче вы не втом месте включали секундомер. А то так можно и доказать что PHP быстрее чем C++.

Данный вопрос выходит за рамки C++.

Он касается разработки под конкретную ОС (windows например) и эти вопросы нужно адресовать их API.

int64_t a = b/0

Тут проблема наверное в том что PWSTR - имеет фиксированную разрядность (это широкий символ w_char). А std::string зависит от опций препроцессора UNICODE. Так-то оно конструируется через конструктор string или присвоение.

Вещественные бывают float и double. И у них - разная точность при работе с десятичной системой.
Вообще все они не точно отражают введенную тобой десятичную дробь. Вопрос в том что ты с этого хочешь
получить?

Вот есть онлайн-калькулятор https://www.h-schmidt.net/FloatConverter/IEEE754.html
Понабирай в нем твои числа и понаблюдай во что они превращаются после присвоения. А тогда уже
и вопросы по вычитаню отпадут.

Какое-то время я посвятил играм с простыми числами. В студенчестве еще.
Вот тут не надо каждый раз прибавлять единичку.
if (K % (i + 1) == 0) {
Ее просто надо учесть в условиях цикла.
if (K % i == 0) {
Далее. Если нужно найти первый попавшийся делитель - то не надо перебирать все числа. Достаточно только 2 и все нечетные. Или даже лучше задать хард-кодом таблицу простых чисел до 2^16. Это как раз будет половина разрядной сетки int32.
int primes[] = { 2,3,5,7,11,13,17...... 65521 }
Это даст хорошее ускорение для поиска. Хотя время загрузки executable может увеличится. Кстати у меня много вопросов к бенчмаркам где стоит запредельно короткое время инициализации (0.25 s). Здесь - практически невозможно вычленить где время занимает алгоритм а где - просто запуск процесса операционки. Обычно когда меряют что-то подобное - меряют длительные процессы хотя-бы порядка минут но никак не секунд.

В С++ массивы нумеруются от нуля до (n - 1).

Чтобы просто почитать память процесса - ему можно послать сигнал SIGQUIT и он должен ссыпать самого себя в дамп файла. Это законный метод. Программист пытается понять state процесса.

Все прочие методы должны вызывать настоящий ужас спецов по инфо-безопасности. Кому понадобилось изменять чужие процессы? Какой юзкейс?

Если компиллятор глотает оба варианта и тесты проходят - то я-бы взял просто первый вариант.

Там меньше букв.

Замер i/o это хитрая штука. Тут недостаточно просто программирования. Нужно знать что ОС обычно берет на себя часть функций по управлению (планировщики) вводом-выводом и кеширование.

Тоесть если ты будешь тестить свои программы в порядке 1->2 то вторая будет иметь фору в виде прогретого дискового кеша. И нужно делать хотябы -4-6 экспериментов чередуя 1->2->1->2 несколько раз и собирать кумулятивное время для каждого приложения и потом брать арифметическое среднее.

Данный класс Timer в таком виде не нужен. Он слишком прост и его можно заменить в коносли на вызов

$ time yourapplication

В качестве улучшений таймера я-бы сделал StopWatch. Это таймер который можно вызывать несколько раз и он будет кумулятивно считать время между begin-end и выводить его в конце. Так можно мерять интересующие фрагменты кода которые работают только с диском и игнорировать например вычисления с CPU.

Для хранения матрицы 10000 на 10000 в формате double вам понадобиться кусок памяти порядка 800 Мб.
И это только для хранения исходных данных. А если нужно будет искать всякие определители и обратные матрицы
то сложно себе представить сколько дополнительной памяти будет нужно.

Если курсовая затрагивает разреженные матрицы (это где много дырок или областей без данных) - то можно
посмотреть в сторону сжатых матриц. Не знаю как щас а в 90-е была куча библиотек для этого дела.

Чем заполнить матрицы в данном примере - ХЗ. Надо погружаться в сам курсовой. Если он растет из физики то и исходные данные надо брать оттуда. Там всякие диагональные и треугольные и прочие.

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

Тоесть в условии задачи скорее всего не хватает деталей.

Вопрос поставлен неправильно.
Чтоб оптимизировать odbc - надо 100% знать что именно он является узким местом. Я бы начал с анализа исполнения и извлечения данных локально на сервере. ДБА здесь поможет. И если ваша задаче связана с ETL - почитайте про техники. Может экспорт в csv файл с загрузкой в с++ приложение будет быстрее. Может репликация бд или миграция.

Принты. Или наблюдения.
1. Цикл где идет merge двух векторов - тривиален. Слабым местом может быть функция резерва памяти, которая по разному реализована в win/Linux. Я не утверждаю что в linux она плохая. Возможно просто звёзды сошлись так что page или другие свойства ос по отношению к аллокаций стали неблагоприятны.

2. Что там с разрядностью 32/64? Надо проверить. Что с железом? Не пытается ли автор нас обхитрить, запуская все это на разном железе. Даже ничтожные различия в размере кешей L1 могли тут сработать.

3. Версии STL. Автор использует не сырые указатели а итераторы. Причем хитрые. Какая там логика на инкремент и на разыменование под капотом.

Чтоб отбросить мои предположения полностью - предлагаю этот цикл (предположительно самый горячий код со слов автора) переписать на указатели без STL.

4. Опции GCC надо посмотреть. Оптимизацию подвигать. O1, O2.

Квадрат это умножение на самого себя.

d3*=d3