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 way the code is expressed cannot be changed much
we need
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
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
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
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
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
@Bearophile: just tried. No dramatic change.
import core.memory;
void main() {
GC.disable;
...
}
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
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.
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
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
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.
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,
@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
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
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
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
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
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
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
22 matches
Mail list logo
