I wrote about this before.

There is a well known time/space-tradeoff for the preInitialization of arrays: using about three times the space one can lazy initialize an array.

But this technic is useless within D, because of the automaatic preInitialization, which currently eats up about 3 cycles per byte.

Please awaken to, that on a 3GHz machine the busy preInitalization of one GB then lasts one second. And the coming 64-bit-machine will have up to some TB of main memory. Current mainboards can already hold up to 4GB, which ist the current main memory limit for win32.

Check again, that to preInitialize one TB you have to wait more than 15 minutes only to wait at least another 15 minutes until your videoediting can start, if no precautions are taken.

We need an option to switch automatic preInitialization of arrays off.

-manfred

By the time we have systems that have >1TB RAM, I'm sure the memory bus speeds will be much faster than they are now (And if they aren't, than there's a lot of other things besides initing arrays that would take insanely long as well).  So I don't think it would take nearly as long as 15 minutes. But aside from that, you do raise an interesting point.


"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:ctmtne$2car$1@digitaldaemon.com...
>I wrote about this before.
>
> There is a well known time/space-tradeoff for the preInitialization of arrays: using about three times the space one can lazy initialize an array.
>
> But this technic is useless within D, because of the automaatic preInitialization, which currently eats up about 3 cycles per byte.
>
> Please awaken to, that on a 3GHz machine the busy preInitalization of one GB then lasts one second. And the coming 64-bit-machine will have up to some TB of main memory. Current mainboards can already hold up to 4GB, which ist the current main memory limit for win32.
>
> Check again, that to preInitialize one TB you have to wait more than 15 minutes only to wait at least another 15 minutes until your videoediting can start, if no precautions are taken.
>
> We need an option to switch automatic preInitialization of arrays off.
>
> -manfred
> 

"Nick Sabalausky" wrote:

[...]
> memory bus speeds will be much faster than they are now

The bus speeds can go as fast as they want. One cpu needs at least two cycles to store the next value: one cycle for incrementig the address and one to store the value, i.e. a 4GHZ cannot be faster than 0.5s for initializing one GB of RAM: still more than eight minutes for one TB.

And in standard machinces the amount of RAM  grew in the last ten years by the factor three more than the CPU-frequency.

-manfred

Hi..

I guess you can easily do an OS call is such a case: HeapAlloc (or even better: VirtualAlloc) in Win32. You should use these functions anyway for large blocks of data (dynamic arrays are not meant for that, never were). Or simply call malloc, it doesn't initialize the values either.

This sure is better than any crt_init(bool) or whatever call you're thinking of to turn on/off array initializations. A compile-time option would be even worse: It'd would break a program if compiled with the wrong flag.

Lionello.

"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:ctmtne$2car$1@digitaldaemon.com...
>I wrote about this before.
>
> There is a well known time/space-tradeoff for the preInitialization of arrays: using about three times the space one can lazy initialize an array.
>
> But this technic is useless within D, because of the automaatic preInitialization, which currently eats up about 3 cycles per byte.
>
> Please awaken to, that on a 3GHz machine the busy preInitalization of one GB then lasts one second. And the coming 64-bit-machine will have up to some TB of main memory. Current mainboards can already hold up to 4GB, which ist the current main memory limit for win32.
>
> Check again, that to preInitialize one TB you have to wait more than 15 minutes only to wait at least another 15 minutes until your videoediting can start, if no precautions are taken.
>
> We need an option to switch automatic preInitialization of arrays off.
>
> -manfred
> 

Manfred Nowak wrote:

> I wrote about this before.
> 
> There is a well known time/space-tradeoff for the preInitialization of arrays: using about three times the space one can lazy initialize an array.
> 
> But this technic is useless within D, because of the automaatic preInitialization, which currently eats up about 3 cycles per byte.
> 
> Please awaken to, that on a 3GHz machine the busy preInitalization of one GB then lasts one second. And the coming 64-bit-machine will have up to some TB of main memory. Current mainboards can already hold up to 4GB, which ist the current main memory limit for win32.
> 
> Check again, that to preInitialize one TB you have to wait more than 15 minutes only to wait at least another 15 minutes until your videoediting can start, if no precautions are taken.
> 
> We need an option to switch automatic preInitialization of arrays off.
> 
> -manfred

I was reading documentation of D and found paragraph about initialization of variables. Can somebody tell me what is the point in doing so and if it's done just by setting them after creation (and IMHO wasting cpu cycles) or is it cost free (I don't know how would be that possible, but that is why I'm asking).

Your post just remind me that case. I'm going even further. Why to initialize anything at all? In 99.9% cases variables are initialized one or two lines after creation and default isn't used at all.
-- 
Dawid Ciężarkiewicz | arael
jid: arael@fov.pl

Dawid Ciężarkiewicz wrote:

> Your post just remind me that case. I'm going even further. Why to
> initialize anything at all? In 99.9% cases variables are initialized one or
> two lines after creation and default isn't used at all.

It's for the other 0.1% percent, where forgetting to initialize
a variable causes a subtle bug ? In other languages, such as
Objective-C for instance, these are separate events altogether:

>   NewObject *newObject; // newObject will be an instance of the NewObject class
>   newObject = [[NewObject alloc] init]; // create and initialize the object
>   [newObject doSomethingWith: anotherObject];

But in D, both will be performed when using the "new" keyword.

http://www.digitalmars.com/d/class.html#constructors:
> Members are always initialized to the default initializer for their
> type, which is usually 0 for integer types and NAN for floating point
> types. This eliminates an entire class of obscure problems that come
> from neglecting to initialize a member in one of the constructors.


Of course, in Objective-C you also have to retain/release or use
Autorelease Pools, which is more fuss than D's garbage collection...
(since it uses a simpler manual method of reference counting)

You can still just kill it, of course, similar to "delete" in D:
>  [newObject dealloc];
Which has all of the double-free and dangling pointer fun, too.


PreInitializing and GarbageCollecting are a whole lot easier to use.


And for local variables, a reasonably good compiler should be able
to optimize out the .init value, if it's just replaced right away...

If not, then your code probably have other performance problems ;-)

You can still write critical parts in C or even asm, and link them in ?
(or write D code using C-standard functions or DMD inline X86 assembler)

--anders

"Lionello Lunesu" wrote:

> I guess you can easily do an OS call

But that is not portable between OS's.

[...]
> large blocks of data (dynamic arrays are not meant for that, never
> were).

From where do you have this wisdom? If so please explain the prereqiesites for the usage of dynamic arrays and for fixed arrays as well.

> Or simply call malloc, it doesn't initialize the values either.
[...]

I would use malloc, if arrays at all are not to be used for large
amounts of memory. Which seems to be a contradiction to the fact that
memory cells are laid out like an array.

-manfred

Anders F Björklund wrote:

> You can still write critical parts in C or even asm, and link them in ? (or write D code using C-standard functions or DMD inline X86 assembler)

This definitely is not an excuse for any limitation in D. Assembler is important for systems programming, but trying to beat a modern compiler with hand-written assembler will work only in very special cases. Simple code can usually be optimized be the compiler anyway and complicated code will become a mess written in assembler.

For C - of course, one should be able to bind in existing C code, but in the long term, there should not be any reason to write new code in C if you have a D compiler at hand.

This issue should not need any measurements for justification. It is clear that preinitializing causes some overhead.

Personally, I believe there needs to be some way to deactivate it. One cannot expect the compiler to optimize away all unnecessary initializations. Especially for array, where initialization really becomes an issue, the initialization might not happen in one simple loop.

As I understand the philosophy of D, it does allow the user to shoot himself in the foot if he really wants to. It is ok to default to a safe behaviour, but experts should be able to deactivate the safety measures by some explicit command. (A global compiler option is not a good idea! I has to be specified right in the code in some way. Any ideas for a possible syntax specifying "This variable should not be initialized"? It should be possible both for variables as well as for dynamically allocated memory or class members.



Manfred Nowak wrote:

> I wrote about this before.
> 
> There is a well known time/space-tradeoff for the preInitialization of arrays: using about three times the space one can lazy initialize an array.
> 
> But this technic is useless within D, because of the automaatic preInitialization, which currently eats up about 3 cycles per byte.
> 
> Please awaken to, that on a 3GHz machine the busy preInitalization of one GB then lasts one second. And the coming 64-bit-machine will have up to some TB of main memory. Current mainboards can already hold up to 4GB, which ist the current main memory limit for win32.
> 
> Check again, that to preInitialize one TB you have to wait more than 15 minutes only to wait at least another 15 minutes until your videoediting can start, if no precautions are taken.
> 
> We need an option to switch automatic preInitialization of arrays off.
> 
> -manfred

"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:ctmtne$2car$1@digitaldaemon.com...
>I wrote about this before.
>
> There is a well known time/space-tradeoff for the preInitialization of arrays: using about three times the space one can lazy initialize an array.
>
> But this technic is useless within D, because of the automaatic preInitialization, which currently eats up about 3 cycles per byte.
>
> Please awaken to, that on a 3GHz machine the busy preInitalization of one GB then lasts one second. And the coming 64-bit-machine will have up to some TB of main memory. Current mainboards can already hold up to 4GB, which ist the current main memory limit for win32.
>
> Check again, that to preInitialize one TB you have to wait more than 15 minutes only to wait at least another 15 minutes until your videoediting can start, if no precautions are taken.
>
> We need an option to switch automatic preInitialization of arrays off.
>
> -manfred

The ironic part is that the GC itself has malloc but the D interface to it
always clears the result. See src/phobox/internal/gc.d routine _d_newarrayi.
It would be really nice to have the following added to the GC interface:
  void* malloc(size_t len) { return _gc.malloc(len); }
Ah, to have something so close and yet so far away...

And while I'm at it how about exposing _gc.realloc, _gc.free and _gc.capacity, too. oh, now I'm just dreaming I know.

-Ben