Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?

[Georg Bauhaus <rm.dash-bauhaus@futureapps.de>]

Maciej Sobczak schrieb:
> On 23 Mar, 14:24, Georg Bauhaus <rm.dash-bauh...@futureapps.de> wrote:
> 
>> Note: Cherrystonesoftware markets a product that is not available
>> with Java, C#, or other languages.
> 
> Are they supposed to make products for those platforms that they
> consider inferior? Why?

If only it was stated like this.  Anyway, the test cases
are interesting for other reasons: Yes, the language
implementation matters.  E.g., does your JIT compile to MMX or
SQRT hardware instructions when running the prime number
algorithm? Can you share data efficiently across multiple
processors in non-augmented C99 or in Ada?

When deciding for/against a programming language,
based on likely application performance,
it seems equally important to look at some more things.
One example is memory management in muticore programs.
It seems like malloc() is beginning to show its sequential
heritage, with memory management becoming a messy resource
conflict, making multithreaded programs slow.   This is when
VMs using JIT compilers (or programs employing a non-language
allocation library...)
stand a chance of being faster: they may have built in
memory management for multiple processors. Languages
like C don't---Cherrystone offers one example.

Another benchmarks currently shows rather inconclusive,
but instructive results. The same program is run on a single core
and on a multicore CPU
http://shootout.alioth.debian.org/u64/performance.php?test=chameneosredux
http://shootout.alioth.debian.org/u64q/performance.php?test=chameneosredux

Thus, I think, language choice may well depend on considering more
than massive close-to-the-register CPU operation efficiency.
Even when it destroys one's presumptions (that C++, Ada, Eiffel,
Modula-3, Fortran, etc. somehow must always be fastest).