[antlr-interest] Re: build issues: bytecode assembly generation

[Don Caton]

Michael:

Yes, support for using ANTLR with MSVC.  But I hope I don't sound like I'm
whining.  I did track down enough info to finally get it all working, and
the amount of effort that was required pales in comparison to the benefits
that Antlr provides.  But nevertheless, it isn't a straightforward sequence
of steps to get up and running with Antlr on Windows.  Java isn't present on
many, if not most Windows installations and it isn't something that most
Windows folks are familiar with.  And even if you find your way to java.com
and figure out what to d/l, who really wants to d/l a huge runtime
environment just to run a single tool?  The average Windows programmer
probably never heard of Cygwin or other emulators either.  The barrier to
entry is high enough on Windows that it may discourage people from using
Antlr, and that would be a real shame.

Perhaps when I have time to come up for air, I'll package the antlr stuff up
in a Windows installer and submit it to the antlr site, along with MSVC
project files and such.

Far as the studies you cite go, all they prove is that Java appears to be
the proper tool for those particular projects, and I don't doubt that at
all.  There's no question Java offers many benefits and it is a good choice
for many types of programming.  I just don't think parsing is something
you'd want to do in a language with the runtime overhead of Java.  I
probably wouldn't write a parser in a .NET language for the same reason.
Maybe a prototype, but not production code.

Regarding Antlr lexers, they do seem a bit sluggish, but with full
optimizations enabled in MSVC, I'm seeing at least a 10-fold increase in
performance, to the point where any increases in performance would not be
noticeable.  And this is on a non-trivial grammar.

Which brings me back to my original question of "why Java?" for this type of
thing?  I suppose for light duty parsing requirements it might be ok, but I
can't imagine that an Antlr-generated Java lexer/parser could ever approach
the speed of a fully optimized C++ one.  I'm rarely in favor of sacrificing
runtime efficiency for programmer convenience.

Regards,
 
Don Caton
Shoreline Software, Inc.
 

> -----Original Message-----
> From: micheal_jor [mailto:open.zone at virgin.net] 
> Sent: Friday, October 22, 2004 8:30 PM
> To: antlr-interest at yahoogroups.com
> Subject: [antlr-interest] Re: build issues: bytecode assembly 
> generation
> 
> 
> 
> --- In antlr-interest at yahoogroups.com, "Don Caton" 
> <dcaton at s...> wrote:
> >  And to be honest, there's no "official"
> > support for Antlr on Windows platforms to speak of.  It took quite a
> bit of
> > trial and error to get Antlr to even run under Windows. 
> 
> I presume you mean support for "using the ANTLR C++ code 
> generator and runtime library with MSVC++ on Windows". If so, 
> all I can say is that the support has gotten much better 
> since 2.7.4 was released (Ric now has MS's compiler I 
> believe). There has been a lot of useful discussion on this 
> list about ANTLR/C++ on Windows.
> 
> > > Given developers with the same level of proficiency and 
> experience 
> > > with C++ and Java, most will be able to produce an 
> application like 
> > > ANTLR much more quickly and easily with Java than C++.
> > 
> > Well, with all due respect I'm not sure how you can make 
> that assertion.
> 
> I based it on my experience, that of many colleagues and 
> employers (past and present) and, on the findings of quite a 
> few published studies including: 
> - http://www.wellscs.com/robert/java/productivity.htm
> - http://www.mind2machine.com/gb/openmind/index.php
> - http://page.mi.fu-berlin.de/~prechelt/Biblio/jccpprtTR.pdf
> - http://www.spirus.com.au/papersAndPresentations.shtml
> 
> > IMO, it depends to a large degree on the individual programmer.
> 
> Yes, productivity is generally more affected by individual 
> programmer skill than choice of implementation language.
> 
> > If any
> > particular language was significantly easier to use, everyone would
> be using
> > it.
> 
> True. Of course no language is best at *everything* so we 
> still get to cherry pick...
> 
> > In any case, this is a philosophical issue on which we may simply 
> > disagree.
> 
> Not really. Productivity can be measured.
> 
> > >           There are of course some applications where the need to 
> > > optimize memory usage and/or speed aggressively suggest C++ (or 
> > > perhaps C or assembly
> > > language) might be a better choice.
> > 
> > Yes, like parsers <g>.  In a debug build, it takes my
> antlr-generated (C++)
> > parser about 15 seconds to parse a 77k source file.  With full
> optimizations
> > enabled, the same code finishes in slightly under 2 
> seconds.  I'm not 
> > kidding.  I was sweating bullets when got my parser to work and
> found it was
> > so slow.
> 
> There are some efficiency issues with ANTLR lexers 
> (especially if you use the more advanced ANTLR lexer options) 
> which ANTLR3 should fix.
> The distribution has a sample showing how to couple Flex 
> lexers to ANTLR parsers. Search the list for past discussions.
> 
> Micheal
> 
> 
> 
> 
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 
> 
> 




 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/antlr-interest/

<*> To unsubscribe from this group, send an email to:
    antlr-interest-unsubscribe at yahoogroups.com

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/