On 07/09/2014 12:47 PM, Larry wrote:

> On Wednesday, 9 July 2014 at 18:18:43 UTC, Ali Çehreli wrote:
>> On 07/09/2014 03:57 AM, Larry wrote:
>>
>> >      struct timeval s,e;
>> [...]
>> >      gettimeofday(&e,NULL);
>> >
>> >      printf("so ? %d %lu %d %d %d",g,e.tv_usec - s.tv_usec,
>> > arr[4],arr[9],pol);
>>
>> Changing the topic a little, the calculation above ignores the tv_sec
>> members of s and e.
>>
>> Ali
>
> Absolutely Ali because I know it is under the sec range. I made some
> test before submitting it :)

I know it did work and will work every time you test it. :)

However, even if the difference is just one millisecond, if s and e happen to be on different sides of a second boundary, you will get a huge result.

Ali

Right

Measure a larger number of loops. I understand you're concerned about microseconds, but your benchmark shows nothing because your timer is simply not accurate enough for this. The benchmark that bearophile showed where C took ~2 nanoseconds vs the ~7000 D took heavily implies to me that the C implementation is simply being optimized out and nothing is actually running. All inputs are known at compile-time, the output is known at compile-time, the compiler is perfectly free to simply remove all your code and replace it with the result. I'm somewhat surprised that the D version doesn't do this actually, perhaps because of the dynamic memory allocation. I realize that you can't post your actual code, but this benchmark honestly just has too many flaws to determine anything from.

As for startup cost, D will indeed have a higher startup cost than C because of static constructors. Once it's running, it should be very close. If you're looking to start a process that will run for only a few milliseconds, you'd probably want to not use D (or avoid most static constructors, including those in the runtime / standard library).

On Wednesday, 9 July 2014 at 13:18:00 UTC, Larry wrote:
>
> You are definitely right, I did mess up while translating !
>
> I run the corrected codes (the ones I was meant to provide :S) and on a slow macbook I end up with :
> C : 2
> D : 15994
>
> Of course when run on very high end machines, this diff is almost non existent but we want to run on very low powered hardware.
>
> Ok, even with a longer code, there will always be a launch penalty for d. So I cannot use it for very high performance loops.
>
> Shame for us..
> :)
>
> Thanks and bye

This to me pretty much confirms that almost the entirety of your C code is being optimized out and thus not actually executing.

The actual code is not that much slower according to the numerous other operations we do. And certainly faster than D version doing almost nothing.

Well it is about massive bitshifts and array accesses and calculations.
With all the optimizations we are on par with fortran numerical code (thanks -std=c11).

There may be an optimization hidden somewhere or just gdc having to mature.

Dunno. But don't get me wrong, D is a fantastic language.