D documentaton says,
"The garbage collector's algorithms depend on pointers being pointers and not
pointers being not pointers. "

but this feature isn't impremented now.
so, when you use big data, such as:
ubyte[] buffer = new ubyte[BIGSIZE];
GC think it may include pointer and scan whole data.

I've added atomic data allocation.
currently supports 1byte(char,byte,ubyte) or 2byte(wchar,short,ushort) type
array.

benchmark:
small array: same or bit slow
large array: about 50% fast

import std.gc;
import std.c.time;

int main(char[][] args) {
clock_t start = clock();

for(int i=0;i<1000000;i++) {
char[] tmp = new char[20];
}
std.gc.fullCollect();
printf("%d:",clock()-start); start=clock();
for(int i=0;i<100;i++) {
char[] tmp = new char[1000000];
}

std.gc.fullCollect();

printf("%d\n",clock()-start);

return 0;
}

1312:1142  orig	>dmd test.d
1312:530   new	>dmd test.d gc.obj gcx.obj

why bit slow? I think:
when new char[n],
original version get memory from pointer area
separete version allocate new 4K block even if pointer area has free area.

inside D,
new Type[n]
fall into
_d_new(n,Type.size)   * except bit array
ex:
new char[n]
->	d_new(n,1)

new int[n]
new float[n]
new pointer[n]
->	d_new(n,4)

so if Type.size < pointer.size(4), it should be atomic value.
if Type.size is same or larger than 4, I can't decide it pointer or value.
Compiler know it. In the feature, D complier may generate another _new runtime
function call for atomic data.

the other side,
new Class
fall into
_d_newclass(ClassInfo ci)

Classinfo has flags.
in the feature, D complier may generate flags the class has pointer or data
only.

----
This code is based on phobos code.
in my view, only dmd frontend is under Artistic and others are "Digital mars
Licence".
so I don't release in this point.

Some interesting stuff!

<berobero@users.sourceforge.net> wrote in message news:bvmoeb$2qtn$1@digitaldaemon.com...
> D documentaton says,
> "The garbage collector's algorithms depend on pointers being pointers and
not
> pointers being not pointers. "
>
> but this feature isn't impremented now.
> so, when you use big data, such as:
> ubyte[] buffer = new ubyte[BIGSIZE];
> GC think it may include pointer and scan whole data.
>
> I've added atomic data allocation.
> currently supports 1byte(char,byte,ubyte) or 2byte(wchar,short,ushort)
type
> array.
>
> benchmark:
> small array: same or bit slow
> large array: about 50% fast
>
> import std.gc;
> import std.c.time;
>
> int main(char[][] args) {
> clock_t start = clock();
>
> for(int i=0;i<1000000;i++) {
> char[] tmp = new char[20];
> }
> std.gc.fullCollect();
> printf("%d:",clock()-start); start=clock();
> for(int i=0;i<100;i++) {
> char[] tmp = new char[1000000];
> }
>
> std.gc.fullCollect();
>
> printf("%d\n",clock()-start);
>
> return 0;
> }
>
> 1312:1142  orig >dmd test.d
> 1312:530   new >dmd test.d gc.obj gcx.obj
>
> why bit slow? I think:
> when new char[n],
> original version get memory from pointer area
> separete version allocate new 4K block even if pointer area has free area.
>
> inside D,
> new Type[n]
> fall into
> _d_new(n,Type.size)   * except bit array
> ex:
> new char[n]
> -> d_new(n,1)
>
> new int[n]
> new float[n]
> new pointer[n]
> -> d_new(n,4)
>
> so if Type.size < pointer.size(4), it should be atomic value.
> if Type.size is same or larger than 4, I can't decide it pointer or value.
> Compiler know it. In the feature, D complier may generate another _new
runtime
> function call for atomic data.
>
> the other side,
> new Class
> fall into
> _d_newclass(ClassInfo ci)
>
> Classinfo has flags.
> in the feature, D complier may generate flags the class has pointer or
data
> only.
>
> ----
> This code is based on phobos code.
> in my view, only dmd frontend is under Artistic and others are "Digital
mars
> Licence".
> so I don't release in this point.
>
>

Heres a link for ya ;) http://www.netbsd.org/Ports/dreamcast/

Sounds interesting , any plans on making it public ?

<berobero@users.sourceforge.net> wrote in message news:bvmoeb$2qtn$1@digitaldaemon.com...
> D documentaton says,
> "The garbage collector's algorithms depend on pointers being pointers and
not
> pointers being not pointers. "
>
> but this feature isn't impremented now.
> so, when you use big data, such as:
> ubyte[] buffer = new ubyte[BIGSIZE];
> GC think it may include pointer and scan whole data.
>
> I've added atomic data allocation.
> currently supports 1byte(char,byte,ubyte) or 2byte(wchar,short,ushort)
type
> array.
>
> benchmark:
> small array: same or bit slow
> large array: about 50% fast
>
> import std.gc;
> import std.c.time;
>
> int main(char[][] args) {
> clock_t start = clock();
>
> for(int i=0;i<1000000;i++) {
> char[] tmp = new char[20];
> }
> std.gc.fullCollect();
> printf("%d:",clock()-start); start=clock();
> for(int i=0;i<100;i++) {
> char[] tmp = new char[1000000];
> }
>
> std.gc.fullCollect();
>
> printf("%d\n",clock()-start);
>
> return 0;
> }
>
> 1312:1142  orig >dmd test.d
> 1312:530   new >dmd test.d gc.obj gcx.obj
>
> why bit slow? I think:
> when new char[n],
> original version get memory from pointer area
> separete version allocate new 4K block even if pointer area has free area.
>
> inside D,
> new Type[n]
> fall into
> _d_new(n,Type.size)   * except bit array
> ex:
> new char[n]
> -> d_new(n,1)
>
> new int[n]
> new float[n]
> new pointer[n]
> -> d_new(n,4)
>
> so if Type.size < pointer.size(4), it should be atomic value.
> if Type.size is same or larger than 4, I can't decide it pointer or value.
> Compiler know it. In the feature, D complier may generate another _new
runtime
> function call for atomic data.
>
> the other side,
> new Class
> fall into
> _d_newclass(ClassInfo ci)
>
> Classinfo has flags.
> in the feature, D complier may generate flags the class has pointer or
data
> only.
>
> ----
> This code is based on phobos code.
> in my view, only dmd frontend is under Artistic and others are "Digital
mars
> Licence".
> so I don't release in this point.
>
>

> Sounds interesting , any plans on making it public ?
> 

Say again, it is based on phobos,
so I don't know I can make it public.
I'm asking to Walter.

bero