This is really neat. I changed the quality value to 6: clang took ~20 minutes to compile and it used around 32GB of RAM. The resulting executable is 13KB, and it generates a 4KB image as output.
As someone who doesn't do much C++, could `constexpr` actually do this all on its own? My (limited) understanding of `constexpr` would lead me to think that using it alone you couldn't generate the contents of the array like this. IE. You could define a `constexpr` function to calculate a single entry in the array, but you'd still need to call that function for every entry. In this case, it looks to me like the bulk of the macros here are just to condense declaring the large array by using nested macros to repeat the computations and expand to a large number of array entries.
That said I absolutely don't disagree with you at all. It's really a bit silly C doesn't have it at this point. `gcc` will happily do all of this math for you at compile time even if you do as much of the math as you can in `static` functions. But to make it compile you have to declare `pixels` in `main` because you can't call the functions in the initializer for file-scoped variables - even though the compiler can already optimize them out.
Everything above and including #define C1 returns a single value, and therefore could be done with constexpr.
More to the point, constexpr would be a heck of a lot more efficient - changing M4 to M5 increases the preprocesed size from 80 MB to 240 MB. This is an exponential increase, despite that a Mandlebrot pixel can be computed in linear time. (Linear to the maximum number of steps.)
I suspect that this is because if you write a macro and use your macro argument twice, this doubles the length of whatever your macro argument was.
This is really neat. I changed the quality value to 6: clang took ~20 minutes to compile and it used around 32GB of RAM. The resulting executable is 13KB, and it generates a 4KB image as output.
Here's a link of the output image: https://imgur.com/cUdForu
Case in point: that 4KB output file refers to the size of the uncompressed PNM file, and as such is an inaccurate hint as to the image dimensions.
It's 64x64.
Just as a FYI, this takes a while to compile:
If you're using iTerm, you can pipe the output of the program to imgcat to see the result without leaving your terminal.gcc mandel.c -o mandel 95.84s user 3.99s system 71% cpu 2:18.88 total
thought it was just my notebook :) think it is the longest my machine spent on just 41 lines of code to compile
Can we please have constexpr in C 2x to put an end to this madness?
As someone who doesn't do much C++, could `constexpr` actually do this all on its own? My (limited) understanding of `constexpr` would lead me to think that using it alone you couldn't generate the contents of the array like this. IE. You could define a `constexpr` function to calculate a single entry in the array, but you'd still need to call that function for every entry. In this case, it looks to me like the bulk of the macros here are just to condense declaring the large array by using nested macros to repeat the computations and expand to a large number of array entries.
That said I absolutely don't disagree with you at all. It's really a bit silly C doesn't have it at this point. `gcc` will happily do all of this math for you at compile time even if you do as much of the math as you can in `static` functions. But to make it compile you have to declare `pixels` in `main` because you can't call the functions in the initializer for file-scoped variables - even though the compiler can already optimize them out.
> As someone who doesn't do much C++, could `constexpr` actually do this all on its own?
yes, some people have written entire constexpr raytracers for instance : https://github.com/tcbrindle/raytracer.hpp
Everything above and including #define C1 returns a single value, and therefore could be done with constexpr.
More to the point, constexpr would be a heck of a lot more efficient - changing M4 to M5 increases the preprocesed size from 80 MB to 240 MB. This is an exponential increase, despite that a Mandlebrot pixel can be computed in linear time. (Linear to the maximum number of steps.)
I suspect that this is because if you write a macro and use your macro argument twice, this doubles the length of whatever your macro argument was.
The end to this madness is to move to C++, D, Rust, Swift, ...
$ cc -E cursed_mandelbrot.c | wc 546 8804289 76385728
The pre-processor outputs 76,385,728 chars on 546 lines
The madness is all in the line that defines the pixels[] array (try 'tail' instead).
Off topic but I think some of you fellow math geeks will get a kick out of the Mandelbrot Set song by Jonathan Coulton.
https://youtu.be/ZDU40eUcTj0
I clicked on it and expected an IOCCC contest entry or something...
Getting
"virtual memory exhausted: Cannot allocate memory"
when trying to compile :/
I suggest you buy more virtual memory.
It's virtual, so obviously you can just download more.
Makes me want to start a RAM-as-a-service company.
If you somehow manage to include bitcoins, industry 4.0 and machine learning into that then you'd also get a heap of VC money for the start!
Change the code from M4 to M3:-
>#define C1(x,y) M3(XF(x), YF(y), XF(x), YF(y)),
>// ^- change this to 5 or 6 to increase detail
MSVC 2017 x64 (v19.15.26730) fails with Error C1060: compiler is out of heap space.