[antlr-interest] C++ beginner questions

[Akhilesh Mritunjai]

Hi Ivan

--- Ian Kaplan <iank at bearcave.com> wrote:
>   If the customer's perception of a compiler is that
> it is slow, they
>   may not buy it.  So the speed of a "run once"

Yes, rather they *will not* buy it if the slow
compiler means that their developers sit around
twiddling fingers for a long time.

But to come at that, lets defines 'slow'. If the
compilation time is insignifant compared to other
overheads, then its not an issue. OTOH, in spaces like
databases, you'll end up seeing SQL interpreter taking
a significant part total time if end users are not
careful enough (eg. not using prepared statements).

A lot of that comes through proper compiler design.
eg. one of the prime reasons why Java, and to some
extent MS C++ and C# compilers, are taking lead
because they allow incremental compilation. Thus a
frontend can give an illusion of code-run-debug-code
cycle with compiler being invisible. Eclipse's java
compiler is written in Java (so is Sun's) and its
beauty is that it gets out of the way. Thus the
perception of time 'wasted' is reduced... a win-win
situation.

>   Your argument seems also revolve around "I can
> find a bunch of Java
>   programmers, but C++ programmers are harder to
> find".  I'm

Nope. My argument is that 'good' programmers are hard
to find, and when I actually get them, why should I
waste their time on petty issues like, for example,
finding memory leaks. About the languages, my
perception is that good programmers can be good in any
language they code in. They are not tied to a specific
language. Smart people are not afraid of learning new
things and they learn damn fast.

>   processors.  For example, although parsing a query
> language is relatively straight forward, optimizing 
> it can be non-trivial. The sort of people that can
do 
> this are not easy to find either.

*grin* so why waste their time on obvious and petty
things ? I'm working on a well known DSL too! And I'd
rather have my team work on solving complex and fun
problems rather than doing menial tasks.

>   I have found that because of the huge Java class
> libraries available, some Java programmers I've 
> worked with do not understand algorithms and data
> structures as well as they should.

Oh, you forgot STL. Its far... far... richer than
Java's algorithm collection. Again, why blame the
tools ? Should I complain that because eclipse handles
compilation transparently, my team may not know all
compiler options... no I shouldn't! That's not in
their KRA and if and when they'd require it, they're
smart enough to learn in & out of it in hours.

>  For example,
>   I've seen some gross misuse of the Java HashMap. 

Oh please. Don't tell me you haven't seen any of
pointers, hash_map<char*, SomeType>, etc etc.

I've seen people using a hammer on screws. Should we
start blaming the hammer ? Or should we be straight
and call the 'human' holding it a prime evidence
against Darwin's law of evolution and survival for the
fittest ?

> http://www.bearcave.com/misl/misl_other/economics.
> html. We can correspond via email.

Interesting link. Reading it.

>   If you're developing a software product there will
> be, you hope, a few developers and many users.  So 
> the extra effort that goes into development to 
> produce a better product is something that is
>   amortized over your user base.

Oh sure. But also factor in things like support.
Coders are fallible. So, what if the product crashes
and burns ? Can you ask them a log file and ship the
patch by monday ? Can you code upgrades fast enough to
keep pace with time and competition 50x your company's
size ?

Also, in a complex project, by the time product ships
(12-18 months), the harware is about 2x faster
overall. So in my opinion going for a 20% increase in
performance at the cost of above points is wrong
unless speed is the make-or-break situation.


>   powerful.  Because of the interpretive overhead of
> Java (and as others have pointed out, the JVM
startup 
> cost) you need to think carefully when choosing to 
> use Java in some performance intensive applications.
 

Well, Java at least has come a long way since 1.1
days.  And for some reasons I think writing a compiler
in Java makes sense. The prime reason is the 'input'.

Input to compilers is not white-noise. It is
structured and generated by either humans or machines
- both exhibiting clear patterns in whatever they
generate. The only difference is that it is situation,
person and machine dependant that what pattern will be
there.

Static compilers (C/C++) do static optimizations. Can
they make optimizations with regard to these patterns
? Nope! JVM (hotspot VM) now has a run-time profiler
that provides feedback to JIT. It can at run time find
critical portions and optimize them through a number
of ways implemented right now and in time to come. So
the speed of execution on any non-trivial amount of
input will increase over time... something that static
compilers will never be able to do.

(That is exactly how java version of my compiler beat
the C++ version. The input was 8MB script generated
code. The JVM figured it out and optimized the
particular code path while C++ one just kept fighting
branch mispredictions and RefCount'ed GC overheads).

- Akhilesh



		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com