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

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

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.

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

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.

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?

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

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?

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.

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.