Re: HardBound and SoftBound

On 2009-08-19, Wilco Dijkstra <Wilco.removethisDijkstra@xxxxxxxxxxxx> wrote:
My bet is on a new C-like language that has the same expressiveness as
C/C++ but which has clearly defined semantics which can be automatically

Both Java and C# are attempts at doing this. How well do you think they are doing?

checked. However we need an approach like Eiffel in the C world, rather
than hoping static or runtime checks can catch all mistakes by inexperienced
programmers. It's telling all so-called "safe" languages focus on productivity
rather than on quality.

:-)

I said same expressiveness, and neither C# nor Java come close to C/C++.
The fact that the runtime and libraries of both are implemented in C++ is a clue
that neither is a believable replacement for C/C++. D is interesting, but also

The Jikes RVM is a java implementation of the jvm and it is reported to
perform pretty well, see http://jikesrvm.org/.

As for C# I can only give some insight regarding the Mono
implementation. The fundamental reason for which the runtime is written in C
as opposed to C# is that you need a runtime in the first place to run C#
(really CIL) code, so the runtime _had_ to be written in a language
different from C#.
Since we are a very small team, rewriting the code in C# at this time just to
prove a point would be idiotic, so it won't happen. There are some parts
though of the runtime/library code that get converted to managed code
from time to time when changes are required or for speed reasons.
On the other hand, our C# compiler is written in C# and compiles at
speeds comparable with the C++ C# compiler from MS.
If you count the lines of code written in C in the runtime and libraries
vs the number of lines of C# code, the percentage is likely not much
different than the lines of asm code vs the lines of C code is some
libraries like ffmpeg.

This is just to say that a language's runtime implementation may be
written in a different language for lots of different reasons and being a
"believable replacement" is _never_ a consideration in the design of a
runtime.

I would also add that C# shouldn't be considered in the same ballpark as
Java regarding expressiveness:
*) C# has unsigned ints and pointer-sized integers:)
*) C# has structures as opposed to just heap-allocated classes
*) C# can pass arguments by ref
*) C# has (safe) unions and explicit layout of structs
*) you can drop down to unsafe code and use pointers if needed (though
in this mode you get out of the safety net, of course)
*) C# has other constructs like delegates (mostly equivalent to function
pointers), multi-dimensional arrays etc. that people can research in
some of the web pages that compare the two languages

So it may not exactly be at the same level of C/C++, but it is close
(and miles ahead of Java).

To be honest, given my experience in writing a good chunk of the Mono
runtime in C and a fair chunk of C# code in the libraries and
applications, if there wasn't the chicken and egg issue of bootstrapping
I'd still use C anyway for large parts of the runtime for the following
reasons:

*) interfacing with the operating system still requires C code, C
headers to be included and parsed etc. It would be a waste of time to
replicate all this and not just let the C compiler deal with it. Again,
doing something just to make a point, even if it's possible, would be
idiotic. This is an issue that is unrelated to C# but related just to
being non-C.
*) a significant part of the runtime deals with circumventing the safety net
of C#. Some of it can be circumvented by unsafe code, but some other
invariants can't be broken (for example you can't union an integer and a
reference). For speed and/or memory usage reasons we use those kind of
patterns in the runtime.
*) the code generated by the Mono jit is still not as fast as the code
generated by a compiler like gcc that has been tuned for decades and has
basically no compilation time and memory constraints. With time the code
generation will improve, so this is not a C# limitation but just a
temporary issue.

So in the end the design decision of using C or C++ vs using C# to
implement the runtime has very little to do with the (mostly perceived)
lesser expressiveness of C#. Saying that C# is not a believable
replacement for C because the runtime was not written in C# is like
saying that C is not a believable replacement for asm because libs like
openssl or ffmpeg contain asm-optimized versions of some routines.
What counts is that C could replace 90+% of the usage of asm and that C#
could replace 90+% of the usage of C. Of course the latter didn't happen
yet (and likely never will because in the foreseable future it will be a
mixture of C#, Java, python, ruby, javascript etc that
will replace most of the current and earlier uses of C/C++).

jumped on the garbage collection hype. It's funny how people believe that
creating a complex system with a huge overhead is somehow an improvement...

I think we need to consider things in context and in the proper
perspective. What you call huge overhead (likely because you're mostly
involved with the small system embedded world and underpowered ARM cpus)
is not huge at all in many other cases, like most PC applications.
I think Terje put it well when he said something to the tune of:
I almost wouldn't notice a 2x slowdown in most of the apps.

There are certainly cases where the GC would cause a 2x or bigger
slowdowns, but this is not common and many reasonable people consider GC
a good tradeoff for the other benefits it provides so much that garbage
collected languages are increasingly used also on small embedded systems
(from j2me to dalvik/java apps to the use of Mono in hundreds of apps
for the iphone etc).

We need a RISC revolution in programming languages!

In practice RISC wasn't such a big change, so your wishes may
eventually be met with just a better GC algorithm/implementation:)
RISC brought more registers: time will bring more cache/memory which
is well known to help GC
RISC brought 1-cycle instruction execution: oops, it was GC that brought
bump-pointer allocations to the programming masses, scratch this one:)
RISC and load/store instructions: it is the GC that removes the calls to
free () from all over the code just like loads and store were
disconnected from ALU ops on them. It's harder to also remove the
allocations:)

Joking aside, the concepts of RISC could thrive because programs were
mostly easily portable. Teaching millions of programmers new programming
paradigms (whatever they might be) has much bigger inertia and latency.

lupus

--
-----------------------------------------------------------------
lupus@xxxxxxxxxx debian/rules
lupus@xxxxxxxxxx Monkeys do it better
.

Relevant Pages

  • Re: Cpp Considered Harmful
    ... >> programming language, the compiler, the IDE, the libraries, etc. ... source file, the implementation shall locate the declaration, (and ... to name one of the defining source files on the command line that initiates ... The counterpart to this in Java is accomplished using the following: ...
    (comp.lang.cpp)
  • Re: wie Array für statische Methoden
    ... > auf gar keinen Fall Java empfehlen;) ... Ich hab mal mit virtuellen Methoden auf einem Microkontroller experimentiert und bin zu dem Schluss gekommen: ... > Es ist ja gerade der Vorteil bei Java einen Compiler ... > Dinge zu optimieren, ...
    (de.comp.lang.java)
  • Re: What is the fastest method of parsing scheme?
    ... These issues can be eliminated by the use of custom memory allocators ... Any other ideas why Scheme would be faster than C++ and Java for heap ... For example, in my compiler, the procedure ) ...
    (comp.lang.scheme)
  • Re: A 21st Century Apple II?
    ... Java 6 -Xms64m 24.00s ... Which is actually 9.6% better than the C++ Intel compiler. ... I'm sure in some cases the GNU compiler produces better results. ...
    (comp.sys.apple2)
  • Re: C to Java Byte Code
    ... > Java) cannot do, and you cannot write a compliant Java engine that can ... "I think you would agree with me that a C compiler that directly ... compliant ANSI C compiler are described in MPC's product description." ... these "minor differences" include this requirement: ...
    (comp.programming)
Loading