www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Another compile-time perversion. Or not?

reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
The idea for another perversion I got from Knud Sørensen when he 
mentioned mandelbrot:

The result is when running dmd like this:

dmd -c ctmand.d

it produces:

11111111111111111111111111111100011111111111111111
11111111111111111111111111111100111111111111111111
11111111111111111111111111111000011111111111111111
11111111111111111111111111110000001111111111111111
11111111111111111111111111110000001111111111111111
11111111111111111111111001100000000011111111111111
11111111111111111111111000000000000000001111111111
11111111111111111111111000000000000000001111111111
11111111111111111111110000000000000000011111111111
11111111111111111111100000000000000000011111111111
11111111111101110111100000000000000000000111111111
11111111111100000001000000000000000000001111111111
11111111111110000000000000000000000000001111111111
11111111111100000000000000000000000000001111111111
11111111110000000000000000000000000000001111111111
11111111100000000000000000000000000000011111111111
00000000000000000000000000000000000000011111111111
11111111100000000000000000000000000000011111111111
11111111110000000000000000000000000000001111111111
11111111111100000000000000000000000000001111111111
11111111111110000000000000000000000000001111111111
11111111111100000001000000000000000000001111111111
11111111111101110111100000000000000000000111111111
11111111111111111111100000000000000000011111111111
11111111111111111111110000000000000000011111111111
11111111111111111111111000000000000000001111111111
11111111111111111111111000000000000000001111111111
11111111111111111111111001100000000011111111111111
11111111111111111111111111110000001111111111111111
11111111111111111111111111110000001111111111111111
11111111111111111111111111111000011111111111111111
11111111111111111111111111111100111111111111111111
11111111111111111111111111111100011111111111111111

Which is if you look at it from a little distance a Mandelbrot
set (only two colors 0 and 1), unfortunately in a very little resolution
because of the limiting execution times.

Actually dmd produces one more line:
Internal error: ..\ztc\cgobj.c 395
but that isn't a part of the fractal.

Code is attached. (I hope Tom S will not be angry because i borrowed his
itoa and sqrt template).
Aug 30 2006
next sibling parent reply Tom S <h3r3tic remove.mat.uni.torun.pl> writes:
Ivan Senji wrote:
 Code is attached. (I hope Tom S will not be angry because i borrowed his
 itoa and sqrt template).
How could you ! I demand satisfaction ! Hehhehe, good job, Ivan :-D
Aug 30 2006
parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Tom S wrote:
 Ivan Senji wrote:
 Code is attached. (I hope Tom S will not be angry because i borrowed his
 itoa and sqrt template).
How could you ! I demand satisfaction ! Hehhehe, good job, Ivan :-D
:-D Thanks! I know it isn't a raytracer but it's a start.
Aug 30 2006
prev sibling next sibling parent Kristian <kjkilpi gmail.com> writes:
Nice!! Heheh, is a new programming language/method devoloping here? ;)


On Wed, 30 Aug 2006 17:06:41 +0300, Ivan Senji  
<ivan.senji_REMOVE_ _THIS__gmail.com> wrote:
 The idea for another perversion I got from Knud Sørensen when he
 mentioned mandelbrot:

 The result is when running dmd like this:

 dmd -c ctmand.d

 it produces:

 11111111111111111111111111111100011111111111111111
 11111111111111111111111111111100111111111111111111
 11111111111111111111111111111000011111111111111111
 11111111111111111111111111110000001111111111111111
 11111111111111111111111111110000001111111111111111
 11111111111111111111111001100000000011111111111111
 11111111111111111111111000000000000000001111111111
 11111111111111111111111000000000000000001111111111
 11111111111111111111110000000000000000011111111111
 11111111111111111111100000000000000000011111111111
 11111111111101110111100000000000000000000111111111
 11111111111100000001000000000000000000001111111111
 11111111111110000000000000000000000000001111111111
 11111111111100000000000000000000000000001111111111
 11111111110000000000000000000000000000001111111111
 11111111100000000000000000000000000000011111111111
 00000000000000000000000000000000000000011111111111
 11111111100000000000000000000000000000011111111111
 11111111110000000000000000000000000000001111111111
 11111111111100000000000000000000000000001111111111
 11111111111110000000000000000000000000001111111111
 11111111111100000001000000000000000000001111111111
 11111111111101110111100000000000000000000111111111
 11111111111111111111100000000000000000011111111111
 11111111111111111111110000000000000000011111111111
 11111111111111111111111000000000000000001111111111
 11111111111111111111111000000000000000001111111111
 11111111111111111111111001100000000011111111111111
 11111111111111111111111111110000001111111111111111
 11111111111111111111111111110000001111111111111111
 11111111111111111111111111111000011111111111111111
 11111111111111111111111111111100111111111111111111
 11111111111111111111111111111100011111111111111111

 Which is if you look at it from a little distance a Mandelbrot
 set (only two colors 0 and 1), unfortunately in a very little resolution
 because of the limiting execution times.

 Actually dmd produces one more line:
 Internal error: ..\ztc\cgobj.c 395
 but that isn't a part of the fractal.

 Code is attached. (I hope Tom S will not be angry because i borrowed his
 itoa and sqrt template).
Aug 30 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Ivan Senji wrote:
 Actually dmd produces one more line:
 Internal error: ..\ztc\cgobj.c 395
 but that isn't a part of the fractal.
That is caused by the compiler writing all the const values out to the object file, and overflowing the counters in the object module format because there are so many. Unfortunately, it isn't fixable, it's an artifact of the format. The slowness is also caused by the generation of stupendous object files.
Aug 30 2006
parent reply Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:
 Ivan Senji wrote:
 Actually dmd produces one more line:
 Internal error: ..\ztc\cgobj.c 395
 but that isn't a part of the fractal.
That is caused by the compiler writing all the const values out to the object file, and overflowing the counters in the object module format because there are so many. Unfortunately, it isn't fixable, it's an artifact of the format. The slowness is also caused by the generation of stupendous object files.
Why do all of the const values need to be written to object file? I would expect that once a template has been constant folded, it should be possible to discard that reference to it. If it is not used elsewhere, it shouldn't need to be included at all. As I understand it, the use of modules makes the situation fundamentally different to C++, where an entirely different file could define a specialisation of the template -- in C++, the linker has a lot of work to do. Have I missed something?
Aug 31 2006
next sibling parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Don Clugston wrote:
 Walter Bright wrote:
 Ivan Senji wrote:
 Actually dmd produces one more line:
 Internal error: ..\ztc\cgobj.c 395
 but that isn't a part of the fractal.
That is caused by the compiler writing all the const values out to the object file, and overflowing the counters in the object module format because there are so many. Unfortunately, it isn't fixable, it's an artifact of the format. The slowness is also caused by the generation of stupendous object files.
Why do all of the const values need to be written to object file?
I was wondering the same thing. The only reason I could think of is for speed efficiency.
 I 
 would expect that once a template has been constant folded, it should be 
 possible to discard that reference to it. If it is not used elsewhere, 
 it shouldn't need to be included at all.
 As I understand it, the use of modules makes the situation fundamentally 
 different to C++, where an entirely different file could define a 
 specialisation of the template -- in C++, the linker has a lot of work 
 to do.
 Have I missed something?
Me too looking for an answer :)
Aug 31 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Don Clugston wrote:
 Walter Bright wrote:
 Ivan Senji wrote:
 Actually dmd produces one more line:
 Internal error: ..\ztc\cgobj.c 395
 but that isn't a part of the fractal.
That is caused by the compiler writing all the const values out to the object file, and overflowing the counters in the object module format because there are so many. Unfortunately, it isn't fixable, it's an artifact of the format. The slowness is also caused by the generation of stupendous object files.
Why do all of the const values need to be written to object file? I would expect that once a template has been constant folded, it should be possible to discard that reference to it. If it is not used elsewhere, it shouldn't need to be included at all.
There's a bit of chicken and egg problem with it - can't tell if it's referenced or not until code generation, which is intimately wrapped up with object file generation.
 As I understand it, the use of modules makes the situation fundamentally 
 different to C++, where an entirely different file could define a 
 specialisation of the template -- in C++, the linker has a lot of work 
 to do.
 Have I missed something?
Aug 31 2006
parent reply Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:
 Don Clugston wrote:
 Walter Bright wrote:
 Ivan Senji wrote:
 Actually dmd produces one more line:
 Internal error: ..\ztc\cgobj.c 395
 but that isn't a part of the fractal.
That is caused by the compiler writing all the const values out to the object file, and overflowing the counters in the object module format because there are so many. Unfortunately, it isn't fixable, it's an artifact of the format. The slowness is also caused by the generation of stupendous object files.
Why do all of the const values need to be written to object file? I would expect that once a template has been constant folded, it should be possible to discard that reference to it. If it is not used elsewhere, it shouldn't need to be included at all.
There's a bit of chicken and egg problem with it - can't tell if it's referenced or not until code generation, which is intimately wrapped up with object file generation.
But isn't it true that a template consisting only of 'const' and 'static if' will *never* result in code generation? After it has been constant folded, it will always be safe to discard it. That might not cover all of the theoretically discardable templates, but it would give almost all of the practical benefits.
Sep 01 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
Don Clugston wrote:
 Walter Bright wrote:
 There's a bit of chicken and egg problem with it - can't tell if it's 
 referenced or not until code generation, which is intimately wrapped 
 up with object file generation.
But isn't it true that a template consisting only of 'const' and 'static if' will *never* result in code generation?
There can be: template Foo(T) { static if (...) const T x; } int* p = &Foo!(int).x;
 After it 
 has been constant folded, it will always be safe to discard it.
 
 That might not cover all of the theoretically discardable templates, but 
 it would give almost all of the practical benefits.
Sep 01 2006
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Walter Bright wrote:
 Don Clugston wrote:
 Walter Bright wrote:
 There's a bit of chicken and egg problem with it - can't tell if it's 
 referenced or not until code generation, which is intimately wrapped 
 up with object file generation.
But isn't it true that a template consisting only of 'const' and 'static if' will *never* result in code generation?
There can be: template Foo(T) { static if (...) const T x; } int* p = &Foo!(int).x;
Yes, because there are two very different meanings for "const" in D : there's "compile-time constant", and there's "variable that can only be assigned once", for which the keyword 'final' is used in every other modern C-like language, which is how it should be done in D as well (or with some other keyword). (Not that that would be required for or even helpful to the compiler to be able to differentiate the two meanings of 'const', in order to see which templates can be discarded) -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 01 2006
parent reply Don Clugston <dac nospam.com.au> writes:
Bruno Medeiros wrote:
 Walter Bright wrote:
 Don Clugston wrote:
 Walter Bright wrote:
 There's a bit of chicken and egg problem with it - can't tell if 
 it's referenced or not until code generation, which is intimately 
 wrapped up with object file generation.
But isn't it true that a template consisting only of 'const' and 'static if' will *never* result in code generation?
There can be: template Foo(T) { static if (...) const T x; } int* p = &Foo!(int).x;
Yes, because there are two very different meanings for "const" in D : there's "compile-time constant", and there's "variable that can only be assigned once", for which the keyword 'final' is used in every other modern C-like language, which is how it should be done in D as well (or with some other keyword).
Bruno, I agree that 'final' would be much better for 'write-once' values; but the compiler can tell the difference anyway, based on whether it has an =. If you change the line to const T x = 6; then the problematic line won't compile. By the time the compiler has finished instantiating the template, it should know if it contained 'const=' or 'write-once const'. I really think that it is worth putting some thought into making this early discarding possible. If all else fails, one possibility would be to allow 'const' in front of 'template' to signify that the template should be discarded. But I don't think that's necessary. The refined rule is: Templates with only 'const =' and 'static if' can always be discarded.
Sep 06 2006
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Don Clugston wrote:
 Bruno Medeiros wrote:
 Walter Bright wrote:
 Don Clugston wrote:
 Walter Bright wrote:
 There's a bit of chicken and egg problem with it - can't tell if 
 it's referenced or not until code generation, which is intimately 
 wrapped up with object file generation.
But isn't it true that a template consisting only of 'const' and 'static if' will *never* result in code generation?
There can be: template Foo(T) { static if (...) const T x; } int* p = &Foo!(int).x;
Yes, because there are two very different meanings for "const" in D : there's "compile-time constant", and there's "variable that can only be assigned once", for which the keyword 'final' is used in every other modern C-like language, which is how it should be done in D as well (or with some other keyword).
Bruno, I agree that 'final' would be much better for 'write-once' values; but the compiler can tell the difference anyway, based on whether it has an =. If you change the line to const T x = 6; then the problematic line won't compile. By the time the compiler has finished instantiating the template, it should know if it contained 'const=' or 'write-once const'. I really think that it is worth putting some thought into making this early discarding possible. If all else fails, one possibility would be to allow 'const' in front of 'template' to signify that the template should be discarded. But I don't think that's necessary. The refined rule is: Templates with only 'const =' and 'static if' can always be discarded.
I know that, I did say it in the post: Bruno Medeiros wrote:
 (Not that that would be required for or even helpful to the compiler to
 be able to differentiate the two meanings of 'const', in order to see
 which templates can be discarded)
;) -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 07 2006