Closed DanielAtCosmicDNA closed 6 months ago
@DanielAtCosmicDNA There's a couple of problems with this PR:
The resulting code is what I intended it to be, the addition of solution 5 with a more aggressive optimization switch than the original solution. I just rebased it to make it easier for the project to merge considering most recent updates that were not present when I started working on the base of this PR.
This solution is supposed to be statistically faster than the version with mtune. That is the reason why I added it as a separate solution, it would be nice to see how they fare when running dude by side in different machines.
I can only see 7 different files on my end.
Yes, now there are only 7 files. I commented on the PR as it stood before your last commit, and at that time there were 28.
I compared the actual implementation (i.e. the .cpp file) in C++ solution 3 and your proposed solution 5, and they are identical - except for you changing the ownership of the solution in the latter. Which still boils down to the solution you propose to add being a duplicate of solution 3, and we simply won't merge that.
If there is a compile flag optimization you think would make PrimeCPP/solution_3 execute faster, then you can open a PR to modify that flag in said solution, as I indicated in my previous comment. I will handle such a PR as I also indicated - as I have similar ones in the past.
Yes, now there are only 7 files. I commented on the PR as it stood before your last commit, and at that time there were 28.
I compared the actual implementation (i.e. the .cpp file) in C++ solution 3 and your proposed solution 5, and they are identical - except for you changing the ownership of the solution in the latter. Which still boils down to the solution you propose to add being a duplicate of solution 3, and we simply won't merge that.
If there is a compile flag optimization you think would make PrimeCPP/solution_3 execute faster, then you can open a PR to modify that flag in said solution, as I indicated in my previous comment. I will handle such a PR as I also indicated - as I have similar ones in the past.
That is perfectly reasonable and understandable. The only drawback is we will not be able to statistically compare version 3 with version 5.
That's a fair point in itself, but this project is not about running a drag race between different versions of identical implementations. The drag race primarily concerns different languages, and secondarily different approaches within each of those. If you can improve the execution speed of PrimeCPP/solution_3 then you're doing that approach in that language a favor, in comparison with all the other languages(' approaches). That in itself is a contribution to the goal of the project.
If the compiler flag makes a difference, please add it to solution_3 if it makes a measurable improvement!
If the other changes -also- improve it further, then it makes sense for them to be their own solution, along with the switch. But all CPP projects that benefit from it where it can be trivially added should have it, since we're racing languages and not flags :-)
I am closing this pull request as the -march=native switch might be used to strengthen all present solutions being compiled by Clang++. This way we might be able to strengthen the C++ language horse. It would be nice to reach consensus before such this change is merged though.
Description
Based on PrimeCPP solution 3 but with
-march=native
instead of-mtune=native
compiler switch.Contributing requirements
drag-race
as the target branch.