Проблема с makefile при сборке проекта.

Пишет же, что в --prefix нужен полный путь, но там ещё и имя компилятора с жёстко заданой версией 4.8. Должно быть достаточно запускать как-то так:

make BUILDDIR=$PWD/build CXX11=g++ CC_FORCXX=gcc

С такой командой запуска сборки проект несколько минут собирался, но потом вылетает очередная ошибка:

Makefile:83: recipe for target '/home/osboxes/Documents/gb_algs-master/build/obj/ring_z2_simpledegrevlex.o' failed

make: *** [/home/osboxes/Documents/gb_algs-master/build/obj/ring_z2_simpledegrevlex.o]

Error 1

Сообщение об ошибке неинформативно. И проект какой-то мутный, видимо, узко специализированный. Может, попробуй пообщаться с Галкиным В. В?

С такими правками собирается:

diff --git a/libtests/cross_ring_info.cpp b/libtests/cross_ring_info.cpp
index 56a4138..cdadf47 100644
--- a/libtests/cross_ring_info.cpp
+++ b/libtests/cross_ring_info.cpp
@@ -263,7 +263,7 @@ TEST_F(CrossRingInfoTest, IOForMonomialListListWithCoef)
 .       CrossRingInfo::MonomialListListWithCoef<DegRevLex, IntField> local_int_field_basis_info{order_, int_field_};
 
 .       std::istringstream in("{((42)), (), ((-2 x_1^3*x_4^2)+(-2)+(333 x_3^1))}");
-.       in >> local_int_field_basis_info;
+.       // in >> local_int_field_basis_info;
 .       //TODO: add expects
 }
 
diff --git a/utils.h b/utils.h
index 71cda93..5156268 100644
--- a/utils.h
+++ b/utils.h
@@ -807,7 +807,7 @@ DECLARE_FUNCTOR_TEMPLATE_T(std::size_t, SmallCollectionHash, const T& collection
 .       std::size_t result = 0;
 .       if (collection.size() != 0)
 .       {
-.       .       const int rotation_per_value = std::max(1, signed_cast(BIT_SIZEOF(result) / collection.size()));
+.       .       const int rotation_per_value = std::max(signed_cast(static_cast<std::size_t>(1)), signed_cast(BIT_SIZEOF(result) / collection.size()));
 .       .       for(auto i : collection)
 .       .       {
 .       .       .       result = RotateBitsRight(result, rotation_per_value) ^ CallStdHash(i);

Большое спасибо за правки! Исправил 2 строчки, проект собрался, но есть варнинг: make: warning: Clock skew detected. Your build may be incomplete.

Это не серьезная проблема?

Время в системе не менялось? Что-то с часами произошло, или файлы редактировал удаленно. Для полной уверенности можешь сделать make clean и пересобрать.

Добрый день,не могли бы вы объяснить, что за правки вы внесли в мой проект, когда отвечали в моей теме 19.04?

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

Спасибо за разъяснение, у меня остается еще вопрос - мне надо использовать большие числа, которые влезут только в 128-битную арифметику, как её можно «подключить»? http://pastebin.com/tx339Hzp вот файл, в котором упоминается LONG_DOUBLE_128.

Возможно, надо поменять здесь int на __int128 (плюс toInt() и подобное, где оно используется). Вообще, я слабо понимаю, что это за проект, так что если не везде используется этот класс модулярной арифметики, то надо будет менять в других местах. Так чтобы это просто конфигурировалось, я не вижу.

Спасибо большое за помощь, но я внезапно пришел в тупик, нужна конечная характеристика поля для данной реализации алгоритма, а в задаче поле рациональных дробей. Не могли бы вы подсказать, что можно в данном проекте «улучшить», чтобы хотя бы немного быстрее работало, пусть даже миллисекунды. Или что-то где-то оптимизировать. В общем, любая помощь сейчас кстати.

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

Ну замеры я проводил, метод гаусса жрет 90%+ всего времени, в частности прямой ход метода гаусса много ест. Он описан в cmatrix.cpp и называется forwardGaussElimination (backGaussElimination). Думал перевести вектора на массивы, но не знаю, уместно ли тут это.

Думал перевести вектора на массивы, но не знаю, уместно ли тут это.

Что-то это может дать, но вряд ли много (в push_back() проверки на размер разве что, ну и выделение памяти уберёт если VLA массив использовать, но только небольшой).

метод гаусса жрет 90%+ всего времени

Вообще код там нормальный, reserve() (правда, не везде), объекты вне циклов, всё такое. Но много всего вызывается, где-то есть new[]/delete[], другие вектора, может стоит глянуть в сторону замены аллокатора (хотя как-то сомневаюсь, что оно большой вклад даёт). Какое-нибудь разворачивание циклов можно попробовать поагрессивнее включить при компиляции или даже вручную. Может ещё представление матрицы подкачало, как я понимаю это разряжённая матрица типа вектор-векторов; кто знает, может в какой-нибудь Eigen это работало бы быстрее (они вроде как в Фортране хранят по столбцам, для лучшей производительности).

Спасибо большое за советы. А почему здесь (github.com/galkinvv/gb_algs/blob/master/cmatrix.cpp#L110) нужно использовать reserve(), ведь там res(msz) уже выделяет память, или я что-то не уловил?

Тот конструктор инициализирует все элементы нулями и сразу после этого все эти нули перезаписываются в цикле. Конечно, ещё вопрос что быстрее: записать N нулей, а потом из перезаписать или ничего не записывать и потом N раз вызвать push_back(), это уже надо проверять.

Спасибо, понятно, подскажите пожалуйста, как приостановить выполнение на указанное количество наносекунд? Микросекунды не помогают, что 70 мксек, что 2 мксек, результат один и тот же, хотя должен быть разным, ведь с приостановкой на 1000 мксек увеличивается работа программы в 2 раза, значит 70 мксек должны увеличить на 7%, но увеличивается на 37%, 2 мксек тоже на где-то на 35% увеличивают.

70 мксек должны увеличить на 7%

Только млсек для 7%, или 70000 мксек.

как приостановить выполнение на указанное количество наносекунд?

Есть nanosleep(), но он не поможет. Все задержки на t гарантированно выполняются минимум t, но чаще всего больше. Т.е. это всегда минимальное время зареджки и ниже частоты переключения задач (10 или 1 мс., зависит от конфигурации ядра) оно не опустится и будет округляться + время переключения задач. Можно попробовать сделать активный цикл ожидания с gettimeofday() и поднять процессу приоритет, но идеальных результатов не будет всё равно.