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 (tha
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
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 i
Right
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]
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 ab
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
@Chris :
Actually yes. If we consider the device to run 20h a day, by
shaving a few microseconds there and there on billions of
operations a day over a whole machine park, you can enable
yourself to shut down some of them for maintenance more easily,
or pause some of them letting their battery
I may definitely help on the D project.
I noticed that gdc doesn't have profile guided optimization too.
So yeah, I cannot use D right now, I mean for this project.
Ok, I will do my best to have some spare time on Dlang. Didn't
really looked at the code already and I code for years in C,
which
On Wednesday, 9 July 2014 at 15:09:09 UTC, Larry wrote:
On Wednesday, 9 July 2014 at 14:30:41 UTC, John Colvin wrote:
On Wednesday, 9 July 2014 at 13:46:59 UTC, Larry wrote:
The rest of the code is numerical so it will not change by
much the fact that d cannot get back the huge launching time.
On Wednesday, 9 July 2014 at 15:09:09 UTC, Larry wrote:
On Wednesday, 9 July 2014 at 14:30:41 UTC, John Colvin wrote:
On Wednesday, 9 July 2014 at 13:46:59 UTC, Larry wrote:
The rest of the code is numerical so it will not change by
much the fact that d cannot get back the huge launching time.
On Wednesday, 9 July 2014 at 14:30:41 UTC, John Colvin wrote:
On Wednesday, 9 July 2014 at 13:46:59 UTC, Larry wrote:
The rest of the code is numerical so it will not change by
much the fact that d cannot get back the huge launching time.
At the microsecond level(even nano) it counts because of
On Wednesday, 9 July 2014 at 14:30:41 UTC, John Colvin wrote:
You say you are worried about microseconds and power
consumption, but you are suggesting launching a new process - a
lot of overhead - to do a small amount of numerical work.
Not much overhead if you don't use a MMU and use static l
On Wednesday, 9 July 2014 at 13:46:59 UTC, Larry wrote:
The rest of the code is numerical so it will not change by much
the fact that d cannot get back the huge launching time. At the
microsecond level(even nano) it counts because of electrical
consumption, size of hardware, heat and so on.
Y
Larry:
@Bearophile: just tried. No dramatic change.
import core.memory;
void main() {
GC.disable;
...
}
That just means disabling the GC, so the start time is the same.
What you want is to not start the GC/runtime, stubbing it out...
(assuming you don't need the GC in your program).
I thi
@Bearophile: just tried. No dramatic change.
import core.memory;
void main() {
GC.disable;
...
}
Larry:
The rest of the code is numerical so it will not change by much
the fact that d cannot get back the huge launching time. At the
microsecond level(even nano) it counts because of electrical
consumption, size of hardware, heat and so on.
Have you benchmarked the D code without starting
On Wednesday, 9 July 2014 at 13:46:59 UTC, Larry wrote:
Yes you are perfectly right but our need is to run the fastest
code on the lowest powered machines. Not servers but embedded
systems.
That is why I just test the overall structures.
The rest of the code is numerical so it will not change
Yes you are perfectly right but our need is to run the fastest
code on the lowest powered machines. Not servers but embedded
systems.
That is why I just test the overall structures.
The rest of the code is numerical so it will not change by much
the fact that d cannot get back the huge launch
On Wednesday, 9 July 2014 at 13:18:00 UTC, Larry wrote:
On Wednesday, 9 July 2014 at 12:25:40 UTC, bearophile wrote:
Larry:
Now the performance :
D : 12 µs
C : < 1µs
Where does the diff comes from ? Is there a way to optimize
the d version ?
Again, I am absolutely new to D and those are my
Larry:
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.
If you run it on very low po
On Wednesday, 9 July 2014 at 12:25:40 UTC, bearophile wrote:
Larry:
Now the performance :
D : 12 µs
C : < 1µs
Where does the diff comes from ? Is there a way to optimize
the d version ?
Again, I am absolutely new to D and those are my very first
line of code with it.
Your C code is not e
Larry:
Now the performance :
D : 12 µs
C : < 1µs
Where does the diff comes from ? Is there a way to optimize the
d version ?
Again, I am absolutely new to D and those are my very first
line of code with it.
Your C code is not equivalent to the D code, there are small
differences, even th
On Wednesday, 9 July 2014 at 10:57:33 UTC, Larry wrote:
Hello,
I extracted a part of my code written in c.
it is deliberately useless here but I would understand the
different technics to optimize such kind of code with gdc
compiler.
it currently runs under a microsecond.
Constraint : the w
24 matches
Mail list logo
