Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

kind of expected gcc to see right through the 300 gigs of code and compile it down to the tenish instructions.




They disabled optimisations:

> Lets compile the code, disabling optimizations with /Od to make sure that the pesky compiler doesn’t interfere with our algorithm


I would have wanted to see them look at the assembly from various optimization levels to see if the compiler really did. Ideally o1 or something wouldn't see through this but would generate better code in other ways. Disabled optimizations often are really stupid about how they code gen.

I'm curious what GCC would do if it wasn't purposely lobotomised and fed 300 GB of this nuclear waste.

Well I created the 16 bit .c file, because I'm not that curious. gcc -O0 completed immediately and made a 1,5MB executable. -O1 took about 10 minutes for a 1,8 MB executable. -O2 has been running for 1h15m so far... i7-14700K

I'm in too deep now, so I'll let it run while I'm at work.


Keep us updated.

GCC -O2 made a 1,8 MB executable after a bit over four hours. I'm not trying -O3 :D

I don't know enough about compilers to answer why this doesn't get optimised down to something tiny, or why it took so long. I'm not sure what we've learned tonight, but there you go.


> disabling optimizations with /Od

And that weird flag is because it's a windows compiler: cl.exe, not gcc.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: