mayton2019

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

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

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

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

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

$ time yourapplication

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

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

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

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

Haskell-style.

int numLen(long long num) {
  return numLen(num, 1, 10);
}

int numLen(long long num,int cnt,long long threashold) {
  return 0 + num < threashold ? cnt : numLen(num, cnt + 1, threashold * 10);
}

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

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

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

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

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

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

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

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

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

d3*=d3

Да тут не вопрос, а целое задание для фриланса. Не знаю чем автор занят, репостом ли чужих задач или решением своих но тут надо просто готовить котлету денег.

Или сильно сильно упростить вопрос чтобы он хотябы был осязаем для вопросника.

В программе имеется работа с сетевыми сокетами. Можно ли отделить чистый код шифрования от сетевых задач? Убежден что это поможет отвечающим сконцентрироваться на решении главного и отбросить вероятность того что автор ещё где то наделал других ошибок по стеку.

Разделение кода на слои также является нужным скилом для c++ ника.

Любое значение менять нельзя. Только те что принадлежат твоему процессу. Это - краеугольный камень инфо-безопасности для современных ос.

Для своей памяти - это работа с указателем. Выделяешь себе кусочек памяти через mallox/new и меняешь что надо.

Это видимо учебная задача. Практического смысла параллелизма здесь мало.

Обычная дисковая подсистема на домашнем ноутбуке состоит из 1 HDD/SDD. И он не параллелится. Тоесть это такое жлобское устройство которое в 1 момент времени может обслуживать чтение и запись 1 блока файловой системы (или сектора или кластера неважно). Поэтому параллелизм толком ничего не дает. Однако если у вас какие-то RAID массивы или сеть хранения данных то она может обеспечить такие действия.

Что еще в задаче плохо.

while(!InputFile.eof())
    {
      getline(InputFile, tmpString);
    }

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

Вот если-бы автор решал задачи наподобие map-reduce где работают с большими файлами тогда параллелизм был бы понятен. Там чтение блока файла чередуется в вычислениями.

Здесь вычисления - мелкие. И большая часть процессорного времени зря сгорит в старт-стопах потоков и в финальном join потоков (которые я кстати не вижу).

Поскольку номер кадра для real-time не имеет смысла то надо поискать такую нумерация которая этот смысл принесет.

Пиши текущий timestamp в качестве имени.

Эта тема не про иерархию и ООП.

А про алгоритмы и структуры данных. На их языке вопрос должен звучать так.

- Дано дерево объектов {Car}/{Box}/{Bomb}
- И при возникновении события в листовом уровне дерева - должна удаляться вся цепочка Parents вплоть до уровня Car.

Поскольку С++ - это объектный язык то обсуждение того как что-то передать надо вести в терминах объектов.
Этож не ассеблер. Смотрите на шапку функции по созданию треда.

HANDLE CreateThread(
  LPSECURITY_ATTRIBUTES   lpThreadAttributes,
  SIZE_T                  dwStackSize,
  LPTHREAD_START_ROUTINE  lpStartAddress,
  __drv_aliasesMem LPVOID lpParameter,
  DWORD                   dwCreationFlags,
  LPDWORD                 lpThreadId
);

В ней lpParameter должен быть указателем на структуру из вашего массива и длины. Или просто вектор целых чисел в терминологии STD (std::vector)