View mode: basic / threaded / horizontal-split · Log in · Help
August 30, 2006
Another compile-time perversion. Or not?
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).
August 30, 2006
Re: Another compile-time perversion. Or not?
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
August 30, 2006
Re: Another compile-time perversion. Or not?
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.
August 30, 2006
Re: Another compile-time perversion. Or not?
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).
>
>
August 30, 2006
Re: Another compile-time perversion. Or not?
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.
August 31, 2006
Re: Another compile-time perversion. Or not?
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?
August 31, 2006
Re: Another compile-time perversion. Or not?
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 :)
August 31, 2006
Re: Another compile-time perversion. Or not?
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?
September 01, 2006
Re: Another compile-time perversion. Or not?
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.
September 01, 2006
Re: Another compile-time perversion. Or not?
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.
« First   ‹ Prev
1 2
Top | Discussion index | About this forum | D home