Consolidating Delphi solutions/submissions

[rbergen]

At the moment, in relation to Delphi, we have:

• An existing solution (PrimeDelphi/solution_1, written by @JackTrapper
• PR Update PrimePas.dpr #264, opened by @KimMadsen, that seeks to change that existing solution
• PR 3 new optimized solutions using Delphi #281, opened by @KimMadsen, that seeks to add 2 additional solutions
• PR Delphi, Multi-Threaded, Based on JakeTapper's Delphi code submission #306, opened by @nmadani, that seeks to change PrimeDelphi/solution_1

Stating first that it is completely logical to have multiple submissions for Delphi after last weekend's video, it does put us in a place where:

• the combination of PRs cannot be merged due to a merge conflict
• we're heading towards having 3 separate solutions, which is suboptimal if it can be prevented

I would therefore like to suggest that the mentioned contributors discuss how we can combine what is mentioned above into one new PR, keeping the number of solutions to the minimum necessary. As it is possible to combine multiple implementations in one solution if their build and execution can be combined in one Dockerfile, I think it may well be possible to end up with one solution that demonstrates multiple implementations. In fact, I think there may be a unique opportunity to do so in this case, as we're waiting for the Dockerfile that @jimmckeeth is working on to become available.

[JackTrapper]

Well...someone just update my code with the faster version.

I don't know how to turn GitHub into a wiki: where anyone can edit the code i originally created - but edit the code i originally created.

From my perspective it wasn't about the race, it was about being more of a code Rosetta Stone.

I tried to stay true to the original (i.e. not multi-threaded, etc). But if someone wants to go all out with parallelism that's file. I do think it should remain "pure pascal" though (i.e. no assembly).

But in the end, everyone decided that Delphi is out - since Delphi costs money.

[rbergen]

Well...someone just update my code with the faster version.

That's a clear answer on your part, thank you. :) That means that the rest of the merge puzzle can basically be solved with @KimMadsen and @nmadani.

But in the end, everyone decided that Delphi is out - since Delphi costs money.

No, Delphi is not out. It's in the collection of languages, and as soon as we have a Docker image that we can use to build and run without getting into trouble legally, we'll pull it into the benchmark as well.

[glenkleidon]

I also contributed some tweaks and I made a pull request against @KimMadsen patch here. As Dave Plummer suggested in the recent video, that the History array should be static and does not need to be re-created each time the class is created. Secondly the BitArray initialization was slow so I managed to remove the need to initialize FBitArray to true first eliminating the last bottleneck.

This delphi version now runs as fast as the C++ version.

From a purely language standpoint, the bytebool solution is fine and remains true to Daves original solution and was highlighted as a neat feature. (identical to the latest Vector in the CPP version).

Kims solution to halve the Array size is an awesome optimisation BUT that is not implemented in other languages so we're not strictly apples for apples now.

[glenkleidon]

Oh, another point. The other implementations (c++ and Csharp at least) use 5 seconds - but somehow we had pushed that to 10 for the delphi version. I put it back to 5.

[glenkleidon]

I suggest we do the following:

• Have @KimMadsen complete my pull request against his patch_1 and then make a new solution_2 from the result.
• @KimMadsen can then do a Pull request for his new solution_2 against drag-race

The alternative is that I create a solution_2 directly in my path-1_gk branch and I do the pull request against drag-race.

@nmadani's solution is cool, but I am not sure its ready for release yet. others have suggested it has some issues at this point. Maybe solution 3? Also, I am not so sure how multithreading is viewed by other language contributors and I have some reservations about employing it here.

@jimmckeeth may also have some idea about licensing a docker for the benchmarks.