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 think you can stub out the runtime functions defining few empty extern(C) functions, but I've never had to do it (saving 0.015 seconds is not important for my needs), so if you don't know how to do it, you have to ask to others.

Bye,
bearophile

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.

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.

Surely no matter what programming language you use you would not want to work like this?

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 linking.

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 electrical consumption, size of hardware, heat and so on.
>
> 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.
>
> Surely no matter what programming language you use you would not want to work like this?

@John : A new process ? Where ?
Or maybe I got you wrong on this one John

I am writing libraries and before going further I wondered if
there were alternatives that I could have a grab on. The idea is
to have an homogeneous software so we were ready to switch to d
for the whole tasks/asset.

No new process involved.

I was seaking for maybe a python like programming language that
offers c-like perfs, without so much writing as in c. Exit
Cython. Debugging it is a real pain. And executable size is..
well..

I am becoming lazy and seek for the Holy Grail. Java not welcome.
D seemed like a very good choice and maybe it is, or more
certainly will.

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. At the microsecond level(even nano) it counts because of electrical consumption, size of hardware, heat and so on.
>>
>> 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.
>>
>> Surely no matter what programming language you use you would not want to work like this?
>
> @John : A new process ? Where ?
> Or maybe I got you wrong on this one John
>
> I am writing libraries and before going further I wondered if
> there were alternatives that I could have a grab on. The idea is
> to have an homogeneous software so we were ready to switch to d
> for the whole tasks/asset.
>
> No new process involved.
>
> I was seaking for maybe a python like programming language that
> offers c-like perfs, without so much writing as in c. Exit
> Cython. Debugging it is a real pain. And executable size is..
> well..
>
> I am becoming lazy and seek for the Holy Grail. Java not welcome.
> D seemed like a very good choice and maybe it is, or more
> certainly will.

I wouldn't give up on D (as you've already signalled). It's getting better with each iteration. BTW, have you measured the power consumption yet? Does it make a big difference if you use D or C?

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. At the microsecond level(even nano) it counts because of electrical consumption, size of hardware, heat and so on.
>>
>> 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.
>>
>> Surely no matter what programming language you use you would not want to work like this?
>
> @John : A new process ? Where ?
> Or maybe I got you wrong on this one John

process == program in this case. Launching a new process == running the program

The startup cost of the D runtime is only paid when you start the program. If the amount of work done per execution of the program is more than a trivial amount then the startup cost will only be a small part of the total running time and power consumption etc.

> I am writing libraries and before going further I wondered if
> there were alternatives that I could have a grab on. The idea is
> to have an homogeneous software so we were ready to switch to d
> for the whole tasks/asset.
>
> No new process involved.
>
> I was seaking for maybe a python like programming language that
> offers c-like perfs, without so much writing as in c. Exit
> Cython. Debugging it is a real pain. And executable size is..
> well..
>
> I am becoming lazy and seek for the Holy Grail. Java not welcome.
> D seemed like a very good choice and maybe it is, or more
> certainly will.

I think D could be a good choice for you.

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 is my first class coding language. Hope it will not be any kind of barrier (c++ is my.. third best coding buddy anyway (after python, excellent for managing systems)).

Many thanks to all the community. I will stick with you and see what I can bring (or cannot).

:)

Bye

@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 lasting a bit longer and economies have proven to be in the order of thousands $$ thanks to a redefined coding strategy.

Not even mentionning hardware usage which is related to heat and savings you can pretend to have over a long run.

By changing some hardware a few monthes after their theorical obsolescence, you can save a bit further.

And the accountant is very happy because he can optimize the finance further (staggered repayment)

It enabled us to hire more engineers/hardware.

Of course, the saving is not only on this loop but on the whole chain. And it definitely adds up $$$.

And there are a lot more things involved that benefit it (latency and so on).

Yep. :)

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 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 :)

But you are absolutely right Ali the mileage will vary in a completely different scenario.