On Monday, 8 April 2013 at 06:35:27 UTC, Paulo Pinto wrote:
On Monday, 8 April 2013 at 03:13:00 UTC, Manu wrote:
On 7 April 2013 20:59, Paulo Pinto <pj...@progtools.org> wrote:
I am not giving up speed. It just happens that I have been
coding since
1986 and I am a polyglot programmer that started doing system
programming
in the Pascal family of languages, before moving into C and
C++ land.
Except for some cases, it does not matter if you get an
answer in 1s or
2ms, however most single language C and C++ developers care
about the 2ms
case even before starting to code, this is what I don't
approve.
Bear in mind, most remaining C/C++ programmers are realtime
programmers,
and that 2ms is 12.5% of the ENTIRE AMOUNT OF TIME that you
have to run
realtime software.
If I chose not to care about 2ms only 8 times, I'll have no
time left. I
would cut off my left nut for 2ms most working days!
I typically measure execution times in 10s of microseconds, if
something
measures in milliseconds it's a catastrophe that needs to be
urgently
addressed... and you're correct, as a C/C++ programmer, I DO
design with
consideration for sub-ms execution times before I write a
single line of
code.
Consequently, I have seen the GC burn well into the ms on
occasion, and as
such, it is completely unacceptable in realtime software.
I do understand that, the thing is that since I am coding in
1986, I remember people complaining that C and Turbo Pascal
were too slow, lets code everything in Assembly. Then C became
alright, but C++ and Ada were too slow, god forbid to call
virtual methods or do any operator calls in C++'s case.
Afterwards the same discussion came around with JVM and .NET
environments, which while making GC widespread, also had the
sad side-effect to make younger generations think that safe
languages require a VM when that is not true.
Nowadays template based code beats C, systems programming is
moving to C++ in mainstream OS, leaving C behind, while some
security conscious areas are adopting Ada and Spark.
So for me when someone claims about the speed benefits of C and
C++ currently have, I smile as I remember having this kind of
discussions with C having the role of too slow language.
Walter's claim is that D's inefficient GC is mitigated by the
fact that D
produces less garbage than other languages, and this is true
to an extent.
But given that is the case, to be reliable, it is of critical
importance
that:
a) the programmer is aware of every allocation they are
making, they can't
be hidden inside benign looking library calls like
toUpperInPlace.
b) all allocations should be deliberate.
c) helpful messages/debugging features need to be available to
track where
allocations are coming from. standardised statistical output
would be most
helpful.
d) alternatives need to be available for the functions that
allocate by
nature, or an option for user-supplied allocators, like STL,
so one can
allocate from a pool instead.
e) D is not very good at reducing localised allocations to the
stack, this
needs some attention. (array initialisation is particularly
dangerous)
f) the GC could do with budgeting controls. I'd like to assign
it 150us per
16ms, and it would defer excess workload to later frames.
No doubt D's GC needs to be improved, but I doubt making D a
manual memory managed language will improve the language's
adoption, given that all new system programming languages
either use GC or reference counting as default memory
management.
What you need is a way to do controlled allocations for the few
cases that there is no way around it, but this should be
reserved for modules with system code and not scattered
everywhere.
Of course I think given time D compilers will be able to
achieve C++ like
performance, even with GC or who knows, a reference counted
version.
Nowadays the only place I do manual memory management is when
writing
Assembly code.
Apparently you don't write realtime software. I get so
frustrated on this
forum by how few people care about realtime software, or any
architecture
other than x86 (no offense to you personally, it's a general
observation).
Have you ever noticed how smooth and slick the iPhone UI
feels? It runs at
60hz and doesn't miss a beat. It wouldn't work in D.
Video games can't stutter, audio/video processing can't
stutter. ....
I am well aware of that and actually I do follow the game
industry quite closely, being my second interest after
systems/distributed computing. And I used to be a IGDA member
for quite a few years.
However I do see a lot of games being pushed out the door in
Java, C# with local optimizations done in C and C++.
Yeah most of they are no AAA, but that does make them less
enjoyable.
Correction:
Yeah most of they are no AAA, but that does not make them less
enjoyable.
