Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added a much faster cpp version #22

Open
wants to merge 2 commits into
base: master
Choose a base branch
from
Open

Conversation

br1b0
Copy link

@br1b0 br1b0 commented Dec 20, 2014

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.

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
Copy link
Contributor

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

@codygman
Copy link

"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
Copy link
Owner

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
#22 (comment).

@gasche
Copy link
Contributor

gasche commented Dec 21, 2014

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants