I notice that there was both C and D source in the phobos internal library code.  Anyone know why?

Another thing ... I looked at complex.h and noticed that the functions were passing Complex by value.  That is not as efficient as using references for a data structure with 2 long doubles.  Given that a long double is 80 bits, and each needs to be aligned appropriately, the Complex data structure is at least 8 bytes long.  So it seems that passing by reference would be faster, but maybe I'm missing something.

-Craig

> and each needs to be aligned appropriately, the Complex data structure is
at
> least 8 bytes long.

Oops, I mean 16 bytes.

-Craig

In article <e33at8$2r49$1@digitaldaemon.com>, Craig Black says...
>
>I notice that there was both C and D source in the phobos internal library code.  Anyone know why?
>
>Another thing ... I looked at complex.h and noticed that the functions were passing Complex by value.  That is not as efficient as using references for a data structure with 2 long doubles.  Given that a long double is 80 bits, and each needs to be aligned appropriately, the Complex data structure is at least 8 bytes long.  So it seems that passing by reference would be faster, but maybe I'm missing something.
>
>-Craig
>

I believe its because types such as creal and such are primitives and are allocated on the stack.

Craig Black wrote:
>> and each needs to be aligned appropriately, the Complex data structure is
> at
>> least 8 bytes long.
> 
> Oops, I mean 16 bytes.
> 
Well, (80*2)/8 is actually 20.

#include <stdio.h>

int main()
{
    printf("%d", sizeof(_Complex long double));
}

Compiled with dmc this prints 20, with gcc it prints 24.  Default options, on win32.  So there seems to be varying opinions as to what the best alignment/space compromise is.

"Tydr Schnubbis" <fake@address.dude> wrote in message news:e33dmb$2u9m$1@digitaldaemon.com...
> Craig Black wrote:
> >> and each needs to be aligned appropriately, the Complex data structure
is
> > at
> >> least 8 bytes long.
> >
> > Oops, I mean 16 bytes.
> >
> Well, (80*2)/8 is actually 20.
>
> #include <stdio.h>
>
> int main()
> {
>      printf("%d", sizeof(_Complex long double));
> }
>
> Compiled with dmc this prints 20, with gcc it prints 24.  Default options, on win32.  So there seems to be varying opinions as to what the best alignment/space compromise is.

Oh well.  I'm not that great with doing math in my head.  Thankfully there are calculators. :)

-Craig

"Ben Phillips" <Ben_member@pathlink.com> wrote in message news:e33d7q$2u15$1@digitaldaemon.com...
> In article <e33at8$2r49$1@digitaldaemon.com>, Craig Black says...
> >
> >I notice that there was both C and D source in the phobos internal
library
> >code.  Anyone know why?
> >
> >Another thing ... I looked at complex.h and noticed that the functions
were
> >passing Complex by value.  That is not as efficient as using references
for
> >a data structure with 2 long doubles.  Given that a long double is 80
bits,
> >and each needs to be aligned appropriately, the Complex data structure is
at
> >least 8 bytes long.  So it seems that passing by reference would be
faster,
> >but maybe I'm missing something.
> >
> >-Craig
> >
>
> I believe its because types such as creal and such are primitives and are allocated on the stack.

It doesn't matter whether you are on the stack or on the heap.  If you pass a data structure by value, then you are pushing and popping the entire contents of the data structure onto the stack every time you call the function.  I've run benchmarks and it is much better to pass by reference, especially for large data structures.

-Craig

Which is better inlined? Maybe it's an optimization issue.

In article <e33eoq$2v4p$1@digitaldaemon.com>, Craig Black says...
>
[...]
>
>It doesn't matter whether you are on the stack or on the heap.  If you pass a data structure by value, then you are pushing and popping the entire contents of the data structure onto the stack every time you call the function.  I've run benchmarks and it is much better to pass by reference, especially for large data structures.
>
>-Craig
>
>

"BCS" <BCS_member@pathlink.com> wrote in message news:e33jmu$322$1@digitaldaemon.com...
> Which is better inlined? Maybe it's an optimization issue.

Inlining is ideal for performance but not always practical, especially if the method is large.

-Craig

For inlining, it should not matter, whether the original function was pass-by-value or pass-by-reference. The whole calling process is mangled anyway, so the end result should not differ.

BCS wrote:
> Which is better inlined? Maybe it's an optimization issue.
> 
> In article <e33eoq$2v4p$1@digitaldaemon.com>, Craig Black says... [...]
>> It doesn't matter whether you are on the stack or on the heap.  If you pass a data structure by value, then you are pushing and popping the entire contents of the data structure onto the stack every time you call the function.  I've run benchmarks and it is much better to pass by reference, especially for large data structures.
>>
>> -Craig
>>
>>
> 
> 

Craig Black wrote:
> I notice that there was both C and D source in the phobos internal library code.  Anyone know why?
> 
> Another thing ... I looked at complex.h and noticed that the functions were passing Complex by value.  That is not as efficient as using references for a data structure with 2 long doubles.  Given that a long double is 80 bits, and each needs to be aligned appropriately, the Complex data structure is at least 8 bytes long.  So it seems that passing by reference would be faster, but maybe I'm missing something.

Call by reference may be faster if the value is already stored in memory or is still needed after the function call. Consider, however:

	a = myfunction(b + c);

Here, the value of b + c is calculated and only used for calling the function. Call-by-value allows the compiler to store the value directly in the place where it is needed by the function, which definitely is faster than having to store it in a local variable and then again having to dereference a pointer to that variable.

It really is a trade-off that cannot be decided without looking at given use cases.