Added a much faster cpp version

[br1b0]

I added basic pruning so recursion won't be called if the best path using the rest of unvisited nodes cannot possibly improve the current solution.

[arthurprs]

The idea is to measure the same implementation in different languages, adding pruning is clearly defeats the point.

[codygman]

"Feel free to submit improvements to the implementations! Just one rule: the graph must be read in at runtime; reading it in and generating the result at compile-time is not allowed."

According to the above "rules" this version is valid. So if this isn't valid, the writeup.md should be changed to mention "the idea is to measure the same implementation in different languages".

Also, how would measuring the same implementation in different languages be fair, when semantics are different. For instance to me "same implementation" means same machine code generated, which would mean all code ran in the same time of those that generate to machine code.

[logicchains]

Could you submit it as a separate file, e.g. cpppruned.cpp, and I'll include that. Makes it clear that it's using a different algorithm to the other implementations. On 21/12/2014 1:56 pm, "codygman" [email protected] wrote:

"Feel free to submit improvements to the implementations! Just one rule: the graph must be read in at runtime; reading it in and generating the result at compile-time is not allowed."

According to the above "rules" this version is valid. So if this isn't valid, the writeup.md should be changed to mention "the idea is to measure the same implementation in different languages".

Also, how would measuring the same implementation in different languages be fair, when semantics are different. For instance to me "same implementation" means same machine code generated, which would mean all code ran in the same time of those that generate to machine code.

— Reply to this email directly or view it on GitHub https://github.com/logicchains/LPATHBench/pull/22#issuecomment-67758325.

[gasche]

I like the current benchmarked methodology, and I find the idea to implement algorithmic optimizations disappointing in this case. The result in practice would be to have people hunting for more algorithmic sophistication (for a NP-hard problem the search is endless...) and copying each other innovations, rather than a stable point of view of how language implementations compare on one similar algorithm.

I think it all depends on what kind of benefits we hope to get from this experiment. If having people compete to make the language they like look good is seen as a strategy to the produce of a solid algorithm to solve the problem, then I guess that would be a good move. I'm personally more interested in the idea of a fair comparison of the idiomatic styles of various programming languages when trying to write efficient yet maintainable code.

Also once you start encouraging algorithmic sophistication you will have large issues of correctness. It will happen that people write code that is wrong, fast, and happens to return the right result on your dataset. Testing speed is easy, verifying the correctness of submitted programs much less so.

Also, how would measuring the same implementation in different languages be fair, when semantics are different. For instance to me "same implementation" means same machine code generated, which would mean all code ran in the same time of those that generate to machine code.

The current algorithm is very easy to summarize: explore all possible non-cyclic paths to compute the one of maximal cost. This does not impose any particular programming paradigm (I would be interested in seeing how example how a good Prolog implementation would fare), and easily distinguishes between implementation improvements and algorithm improvements. Pruning search means than not all non-cyclic paths are searched, it's a different algorithm.

PS: I've seen the JavascriptWitHCache submission. I think it's fine to have it, as it highlights the important point that algorithmics generally beat constant factors (which is an argument to write clean code that is easy to maintain and evolve, an idea everybody agrees is important). I think it should remain one single submission instead of starting another arm's race.