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.
