• Ivan Senji (46/46) Aug 30 2006 The idea for another perversion I got from Knud Sørensen when he
• Tom S (2/4) Aug 30 2006 How could you ! I demand satisfaction ! Hehhehe, good job, Ivan :-D
• Ivan Senji (2/7) Aug 30 2006 :-D Thanks! I know it isn't a raytracer but it's a start.
• Kristian (3/49) Aug 30 2006 Nice!! Heheh, is a new programming language/method devoloping here? ;)
• Walter Bright (6/9) Aug 30 2006 That is caused by the compiler writing all the const values out to the
• Don Clugston (10/21) Aug 31 2006 Why do all of the const values need to be written to object file? I
• Ivan Senji (4/27) Aug 31 2006 I was wondering the same thing. The only reason I could think of is for
• Walter Bright (4/26) Aug 31 2006 There's a bit of chicken and egg problem with it - can't tell if it's
• Don Clugston (6/29) Sep 01 2006 But isn't it true that a template consisting only of
• Walter Bright (8/20) Sep 01 2006 There can be:
• Bruno Medeiros (12/31) Sep 01 2006 Yes, because there are two very different meanings for "const" in D :
• Don Clugston (15/41) Sep 06 2006 Bruno, I agree that 'final' would be much better for 'write-once'
• Bruno Medeiros (7/56) Sep 07 2006 I know that, I did say it in the post:

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).

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

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.

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).

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.

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?

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 :)

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?

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.

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.

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

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.

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