[challenge] Extremely inefficient SELF-TEST DIAGNOSTIC solutions

[__m__Yn_F_onY__d]

The challenge is to create an extremely high cycle solution for the SELF-TEST DIAGNOSTIC puzzle, going way above the requirement for the related achievement.

Sources are being posted below, so if you want to attempt it unspoiled then don't peek. ;)

I've estimated cycle counts manually for the code that's been posted thus far. Listed are the best cycle counts from each person. Note that I may not update the OP very often, or at all, but new solutions are of course always welcome.

_monad	~2.85*10^36 cycles	code
TheVoiid	~2.21*10^36 cycles	code
ShadouFireborn	~8.90*10^34 cycles	code
djdragonboy	~4.95*10^33 cycles	code
Vardis	~1.16*10^32 cycles	(deleted)
DaDementedOne	~9.57*10^24 cycles	code
Sio	~9.94*10^18 cycles	code
chrisdubz	~1.98*10^18 cycles	code
deljr15	~6.98*10^17 cycles	code
dl80aeg	1559844467370 cycles	code
Cornelia Xaos	1214518995 cycles	code
xCROOKEDx	635443280 cycles	code
Zaflis	233805082 cycles	code [i.imgur.com]
AvantGuard	680177 cycles	code

[Zaflis]

I noticed it should be possible to run loops inside loops for 999 times in 5 codeblocks, if you SWP the counter. Just 1 loop in a single codeblock put me over 100k cycles and it took a long time in fast.

[__m__Yn_F_onY__d]

Originally posted by Zaflis:

I noticed it should be possible to run loops inside loops for 999 times in 5 codeblocks, if you SWP the counter. Just 1 loop in a single codeblock put me over 100k cycles and it took a long time in fast.

True. My current solution just came to me as I was dozing off last night, so I haven't dedicated much consious thought to it yet. Your reminder just gave me an idea that would likely "improve" it quite a bit. I might try to calculate cycles too, I was thinking of implementing the language myself so I could run the simulation faster and perhaps get more accurate values.

[Zaflis]

This in top right block:

MOV 999, ACC
L: SUB 1
SWP
MOV 999, ACC
L2: SUB 1
JGZ L2
SWP
JGZ L
MOV UP, LEFT

Just quick and dirty for roughly 70 million cycles :p

Here's screen of it taken a bit further. I don't know how long it would take
http://i.imgur.com/et1cCEh.png

edit2: If i counted at all correctly this would take almost 11 days on fast. I can imagine some sort of interactions with jump commands that bounce back and forth codeblocks too. But that's for the devious minds.

[__m__Yn_F_onY__d]

Originally posted by Zaflis:

Just quick and dirty for roughly 70 million cycles :p

That ended up helping much more than I initially thought it would, so thanks for mentioning it.

[Vardis]

http://steamcommunity.com/sharedfiles/filedetails/?id=493065187

It could definitely be made a little more inefficient by adding NOPs in the innermost loop, and maybe I could do something to make them not sub 1 right off the bat, but I'd be surprised if the general structure could be improved.

This was over 15 million cycles with each of the 10 counters set to 4. Should hit somewhere around 10^31 or so with them all set to 999, although that's obtained just by multiplying by 250^10 and not using more precise calculations. I might be off by a couple orders of magnitude.

[__m__Yn_F_onY__d]

Okay, sources are being shared anyway, I'll do the same.

This was my first attempt, based on the code that gave me the related achievement:
http://steamcommunity.com/sharedfiles/filedetails/?id=493112889
This was my second, heavily influenced by Zaflis' comment:
http://steamcommunity.com/sharedfiles/filedetails/?id=493113466
The basic strategy here is to have each node rely the following one in order to complete. Each following node acts as an inner loop for the previous.

I have some other ideas in mind that I'll try later and I have yet to estimate cycle counts.

Edit:
Last night (as I was dozing off, hehe) I realized that in the second program, lines 11-14 of the top-right node should have been placed inside the inner loop.

[DaSourcerer]

Originally posted by Vardis:

It could definitely be made a little more inefficient by adding NOPs in the innermost loop

Heh, I were just about to post this

[__m__Yn_F_onY__d]

Made this into a challenge thread, keep the ideas flowing. =]

[Vardis]

Originally posted by DaSourcerer:

Originally posted by Vardis:

It could definitely be made a little more inefficient by adding NOPs in the innermost loop

Heh, I were just about to post this :B1:

Yeah, my example isn't really optimized to eek out the last bit of inefficiency, I just wanted to see if I could get the nodes communicating with each other and so nest the loops. I was just happy that the necessary code fit in the nodes and works for any input. ;)

[__m__Yn_F_onY__d]

I decided to look at this again, found some nice unoptimizations.

http://steamcommunity.com/sharedfiles/filedetails/?id=524446775

[chrisdubz]

Here is my entry. It is basically running as serially as possible with effectively 7 nested for loops. If each loop iterates 1,000 times and we have 39 test inputs, I should be at about 3.9e^22 iterations.

@0
##BURN
MOV UP, DOWN

@1
ST:MOV 999, ACC
IN:SUB DOWN
NOP
NOP
NOP
JLZ END
MOV 0, DOWN
JMP IN
END:MOV 1, RIGHT
MOV RIGHT, ACC
JEZ CALL
MOV 1, DOWN
MOV RIGHT, DOWN
JMP ST
CALL:MOV 0 DOWN

@2
ST:MOV 999, ACC
SAV
IN:SUB LEFT
NOP
JLZ END
MOV 0, LEFT
JMP IN
END:SWP
SUB 1
JLZ EN2
SWP
MOV 0, LEFT
JMP IN
EN2: MOV 1, LEFT
MOV UP, LEFT

@3
MOV UP, DOWN

@4
ST:MOV 999, ACC
IN:SUB DOWN
NOP
NOP
NOP
JLZ END
MOV 0, DOWN
JMP IN
END:MOV 1, UP
MOV UP, ACC
JEZ CALL
MOV 1, DOWN
MOV UP, DOWN
JMP ST
CALL:MOV 0 DOWN

@5
MOV UP, DOWN

@6
ST:MOV 999, ACC
IN:SUB RIGHT
NOP
NOP
NOP
JLZ END
MOV 0, RIGHT
JMP IN
END:MOV 1, UP
MOV UP, ACC
JEZ CALL
MOV 1, RIGHT
MOV UP, RIGHT
JMP ST
CALL: MOV 0, RIGHT

@7
ST:MOV 999, ACC
SAV
NEX:JLZ IN
SUB 1
JMP NEX
IN:MOV 1, ACC
SWP
JLZ END
SUB 1
SWP
JMP NEX
END:MOV 1, LEFT
MOV LEFT, ACC
JEZ ST
MOV LEFT, DOWN

[__m__Yn_F_onY__d]

http://steamcommunity.com/sharedfiles/filedetails/?id=527254206
It's pretty tight now, I'm thinking this may be optimal for this technique. There are still potentially other techniques that could do better.

[__m__Yn_F_onY__d]

I estimated cycle counts for the code that's been posted. chrisdubz, I figured that the sixth line of your bottom-right node was intended to be 'IN:MOV 999, ACC'. If not, then I'll fix the count.

[chrisdubz]

monad, good catch.

I had intended to use 'IN:MOV 999, ACC' and had forgot to change back from 1 during my testing. Not that it matters I'm pretty handily beaten at this point :)

If the input contained any value between -999 and 999 I believe Vardis's solution would still beat me and I see little reason to improve my own solution as Vardis figured out how to manage dual loops first.

That said. Kudos again to monad as while your terribly inefficient function isn't as safe as the others, once you wrap your head around it, it's a very simple and efficient design. I'm very afraid to see an alternative that could best you.

[__m__Yn_F_onY__d]

http://steamcommunity.com/sharedfiles/filedetails/?id=532653144
Now featuring: only 1 nop! an input-dependant cycle count!

I messed around a bit with trying to double those 999s, but I didn't find anything imediately that would increase the cycle count. Then I stumbled upon this today.