too early for D2 and too late for D1

[Paulo Pinto]

Not sure about the sometimes, but nowadays they can be very fast.

Regarding .Net/CLR, the bytecode only exists as portable assembly. When a
an assembly (.dll/.exe )file is loaded the complete code is JITed before 
execution
starts. Another possibility is to use ahead of time compilation and thanks 
to ngen,
already deploy the assembly in native code.

If you think that the JIT is not doing a good work compiling your code, you 
can
step down to C++/CLI which is able to blend native code and managed.

On the Java world, usually the methods are only compiled after a certain 
threshold
has been reached, most JVMs allow to customize this threshold via a non 
standard
parameter. if you set it to zero, you get the same behavior as in .Net.

If you are also not happy with the JITed code, you can turn to a real 
compiler like the
Excelsior JET.

http://www.excelsior-usa.com/jet.html


--
Paulo

"Russel Winder" <russel at russel.org.uk> wrote in message 
news:mailman.24.1304493198.14074.digitalmars-d at puremagic.com...
On Tue, 2011-05-03 at 23:14 -0400, dsimcha wrote:
[ . . . ]
> BTW, yes, I know Java and C# can be pretty fast sometimes.  The problem
> is that they both have abstractions you can't get beneath in your most
> performance-critical code.  If you're writing code from scratch (as
> opposed to something that would benefit from tons of libraries that D
> doesn't have yet), I also think they're not as productive because they
> don't make metaprogramming easy.

I don't know about C#/CLR (no experience of knowledge) but for
Groovy/Scala/Java/Clojure on the JVM, and indeed Python on the PVM, if
there is a small piece of code that is truly performance critical and
you can't get the JVM/JIT to make it fast enough and native code can
then you call out to C or C++ -- real performance data not speculation
is required here though.  Of course this is far, far easier with Python.
Much of the "need flexibility"/"developer time is more important than
run time because I am just using APIs that are already optimized"
HPC-ish stuff is now happening in Python with C/C++/Fortran libraries,
cf. NumPy, SciPy.

Why is D not an up-front contender here more widely than it is?  Ease of
creating GUIs and rendering data mostly I would suggest.  It's so much
about data visualization rather than computation these days.  Python has
easy connection to Qt, GTK, wxWidgets, etc.  QtDesigner, Glade, and
wxGlade make laying out the UI easy, generating XML specification.  Then
the dynamic aspects of Python make it trivial to read in XML and
instantiate all the widgets and connect up the events.  C, C++, Go, and
D are not even in the race except for systems such as games where the
timings are so critical, assembly language is a real contender.

I wonder if D could get more traction by adding dataflow to the evolving
actor and data parallelism stuff.  With Groovy/GPars (dynamic languages
make metaprogramming really trivial btw) we are seeing a take up of
dataflow as well as actor model and data parallelism.  There are even
commercial Java dataflow frameworks that are storming the analytics
using JVM world.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: 
sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder