That was fun!
I wrote a Perl program to write a Superhack program.
Otherwise I would have gone mad...
Jeux du Sort Vite
I wrote it by hand as well and I was already mad during it's writing.
A lot of optimisation what would be really hard to generate.
At the end I have decided not to made more difficult challenge and I have not submitted solution faster than cutter did.
I have commented it on the Challenges thread ... only 2 algorithms looked feasible ... both were circuit layouts ... mergesort circuit / bitonic circuit. The winner was mergesort as bitonic circuit would need all threads in every phase, while mergesort gaves pauses to some of them.
I started my design by planning output on 4 turns.
This is why I have organised even threads to work (roughly) on memory in range 00 to 79,
while odd threads far away from others. (Of course the thread invoking the ! instruction neednot be the 1F one so other layouts were possible.)
There was a lot of manual optimization in moving subresults "along wires" ... direct addressing in range 00 to 99 was helpful, several times the pausing thread pulls and pushes to speed up otherwise "overloaded" thread. Even threads were pausing only in early rounds to prepare for addressing, later as there were able to use fast addressing they never more pased. Odd threads must have push and pull to wires so without pausing they would be bottlenecks.
Making 32 threads working on different memory and code as fast as possible was of course important.
(Organisation slightly differed from fast string reversal as there was need of thread "pairing" in the latter, but not the former, and in former we must use higher y coordinates).
To be able to write the code, I wrote "linear schedule" in excell I have switched among three orderings ... one in circuit logic, one in thread order logic and last in geometry logic.
First was used for planning "wires", second for debugging time dependences and third for codding.
Fortunately after few starting phases I have managed "in pauses" to place threads geometrically far from each other such that I neednot solve geometrical problems in later phases.
That would allow automation of rewriting the linear code to the plane code (I was lazy to code it, but that would definitely be good if one would decide continue the optimization).
A lot of optimisation what would be really hard to generate.
At the end I have decided not to made more difficult challenge and I have not submitted solution faster than cutter did.
I have commented it on the Challenges thread ... only 2 algorithms looked feasible ... both were circuit layouts ... mergesort circuit / bitonic circuit. The winner was mergesort as bitonic circuit would need all threads in every phase, while mergesort gaves pauses to some of them.
I started my design by planning output on 4 turns.
This is why I have organised even threads to work (roughly) on memory in range 00 to 79,
while odd threads far away from others. (Of course the thread invoking the ! instruction neednot be the 1F one so other layouts were possible.)
There was a lot of manual optimization in moving subresults "along wires" ... direct addressing in range 00 to 99 was helpful, several times the pausing thread pulls and pushes to speed up otherwise "overloaded" thread. Even threads were pausing only in early rounds to prepare for addressing, later as there were able to use fast addressing they never more pased. Odd threads must have push and pull to wires so without pausing they would be bottlenecks.
Making 32 threads working on different memory and code as fast as possible was of course important.
(Organisation slightly differed from fast string reversal as there was need of thread "pairing" in the latter, but not the former, and in former we must use higher y coordinates).
To be able to write the code, I wrote "linear schedule" in excell I have switched among three orderings ... one in circuit logic, one in thread order logic and last in geometry logic.
First was used for planning "wires", second for debugging time dependences and third for codding.
Fortunately after few starting phases I have managed "in pauses" to place threads geometrically far from each other such that I neednot solve geometrical problems in later phases.
That would allow automation of rewriting the linear code to the plane code (I was lazy to code it, but that would definitely be good if one would decide continue the optimization).