Компилятор создающий самый быстрый код

Значит, у тебя плохая архитектура и ты плохой программист.

 

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

--- Сообщение объединено, 1 июл 2023 ---

Попробуй создать чистый проект, и постепенно 'перенести' все из старого решения в него.
Есть хорошая вероятность, что увидишь много нового по улучшению/оптимизации

--- Сообщение объединено, 1 июл 2023 ---

Зависит от твоих знаний/мотивации, свободного времени

 

Идея то хорошая, только боюсь не получится Там настолько всё запутано, что если что-то уберёшь, что весь алгоритм перестанет работать. Фактически это единая математическая формула Но как разберусь с компиляторами, подумаю что можно в этом плане сделать.

 

Llirik, лямбды применяете?

 

Если ты надеешься на оптимизацию твоего кода компиляторами, то априори считаешь, что "по другому" можно... Оптимизированный код - это и есть твой код, но "по другому". Есть так называемые "zero cost" абстракции - они помогают лучше структурировать код без добавления каких-то оверхедов по производительности. Некоторые из них на самом деле не "зиро кост", но не суть. От того, что у тебя всё свалено в одной функции на несколько сот строк - алгоритм не станет существенно быстрее, в сравнении с грамотно структурированным кодом. Если ты сам пишешь, что твой алгоритм настолько сложный, чтобы его переписать нормально слишком сложно, то ты сам столкнулся с проблемой собственного гуанокода, тк не можешь его поддерживать: надеешься, что какой-то из компиляторов поймет твой код лучше тебя и сделает его быстрее.

 

У нево очень сложный движок, если что-то уберешь то весь алгоритм перестанет работать. Дабавте в ваш алгоритм немного многопоточности и все будет гуд !

 

да, добавь в свой олологоритм немного ануса, пёс, и, глядишь - всё зафунцыклирует. тут тебе не курорт, придурок, хочешь разобраццо - забивай стрелу в адресном пространстве, но не забывай, что на любом месте уже будут НАШИ шеллкоды, а, сталобыть, и экспло1йты - тоже. АЛЛОХА, НУБ

 

Код C++ Builder

, но неужели нельзя

? Вот о каких простых оптимизациях я говорю. Или самому нужно переписывать весь код на ассемблере?

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

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

 

Ваш код использует активным образом 1МБ или более памяти данных ?
Если да, этот дурацкий код Builder`а, может почти не повлиять на быстродействие.
Ну, в смысле, этот и миллионы таких же фрагментов в других местах, могут почти не повлиять.

 

Чтобы кланг не портил якобы бесконечные циклы, я использовал примерно вот такой приём:

Что ж......... Вот результаты:
Visual studio 5+ мин
C++ Builder 1 мин 7,9 сек
C++ Builder с оптимизациями в исходнике 1 мин 8,2 сек
Clang (Visual studio) 23,9 сек
Clang (Visual studio) с оптимизациями в исходнике 34,2 сек
OneApi 24,3
OneApi с оптимизациями в исходнике 27 сек

Пошёл разбираться, почему упразднение циклов в моём случае имеет обратный эффект))

 

Llirik, можешь для сравнения mergesort от 10000 интов замерить?

 

https://www.google.com/search?chann...#fpstate=ive&vld=cid:119c4ecf,vid:y7nSzu3RZQo

--- Сообщение объединено, 4 июл 2023 ---

https://learn.microsoft.com/en-us/windows-hardware/test/wpt/graphs

 

Да, я примерно тоже самое и делаю

 

Ты задаешь вопросы быстрого и медленного Кодо для себя лично? Просто декомпилируйся, Лирик

 

Я чёт не понял, а исходник алгоритма выкладывался? Аппеляции к компилятору надо делать только тогда, когда понимаешь, что на высоком и на среднем уровнях оптимизации выжато всё по максимуму.

 

Код (Text):

1. Unit1.cpp.49: if (pDataAnalizind->MutexR == 0)
2. 0000000000405BEF 488B8424E0000000 mov rax,[rsp+$00e0]
3. 0000000000405BF7 8A4850 mov cl,[rax+$50]
4. 0000000000405BFA 80E101 and cl,$01
5. 0000000000405BFD 0FB6D1 movzx edx,cl
6. 0000000000405C00 81FA00000000 cmp edx,$00000000

Код хоть местами и бредовый, но очевидно MutexR 1-битовое поле внутри байта. Целиком этот байт с нулем сравнивать нельзя. (я бы предложил test BYTE[rax + 0x50],1b) Та же паттерновая шляпа что и в (наверное) любом цэ-компилере, в некоторых такое (почти) лечится флагом про оптимизацию кода.

--- Сообщение объединено, 5 июл 2023 ---

ЗЫ: то есть паттерн выборки поля (байта), паттерн преобразования типа, паттерн сравнения битового поля. Потому что компиляторы надмозги делают. Все это по идее должно сворачиваться флагом -O, если ты попросишь компилер это сделать. Выхлоп тоже будет не без бреда, но больше похож на человеческий.

 

Нет. Это байт целиком. Я не стал тут заморачиваться с битами), иначе в условии вместо == поставил бы &

 

В приведенном коде проверяется только младший бит, это проверка байта на четность, но не на равенство нулю.

 

Это, наверно, потому, что MutexR тип bool. Надо же. Не задумывался, что так компилируется bool. Надо поменять тип. Спасибо, f13nd !