I tried a timing experiment to compare C, Java, Visual Basic, Perl and Tcl for
a simple calculation-intensive task - generating the first
n primes using the well-known Sieve of Eratosthenes.
The timings (in seconds) were as follows :
Number of primes | C Java VBasic Perl Tcl | Java/C VB/C Perl/C Tcl/C
2,000 | 0.2 0.9 2.0 4.0 41 | 4.5 10.0 20 205
10,000 | 1.6 6.8 14.0 33.0 355 | 4.2 8.7 20.6 222
20,000 | 3.7 16.7 34.0 85.0 885 | 4.5 9.2 22.9 239
100,000 | 25.0 139.5 # 786.0 5319* | 5 # 31.4 212*
* The last Tcl example failed with a segmentation fault, and
may not have run to completion. I have no idea why.
# The 16-bit version of VB couldn't allocate enough storage
I expected that Tcl and Perl would be similar, and was surprised that
this is not correct. Roughly speaking, Perl is twenty times slower
than C, and Tcl is two hundred times slower - for this kind of
calculation. (This kind of calculation is an abuse of Tcl;
it is definitely not what it was designed to do!)
Different algorithms, such as those that are I/O
dependent, would show very different results. Java is much faster
than Perl; about the geometric mean of Perl and C. Visual Basic
is about twice as slow as Java, and twice as fast as Perl.
I had thought that I wouldn't bother to learn Perl, as I like
Tcl/Tk for its clean design and regularity. Now I am not so
sure. I shall certainly learn more about Java, as it provides
a clean and elegant alternative to Tcl/Tk for building GUI interfaces
quickly, with much better performance for raw calculation. But it
still seems rough around the edges - Tk interfaces seem to look
much better than Java ones.
Results were on a Pentium 120, using FreeBSD, with the exception of Visual Basic,
which was run under Windows NT.
Tcl is not tcl is not tcl any more; particularly with the 8.0 bytecode
precompile. What version of tcl did you use? I would heartily
recommend two entries for tcl; pre8.0 and 8.0. In particular, I presume
your sieve algorithm uses an array ("list"); these are quite a bit
faster in 8.0--and it'd be interesting to see how it scales against
others in your sample.
What's the versions of each of those languages & compilers/interpreters?
What options did you use in compiling & running each test?
What's the code that you wrote in each of those languages?
Etc.
For Java, given the FreeBSD platform, I would assume that you're using the
Sun JDK but there's also the Kaffe JIT.
For Tcl, there's the purely interpreted versions before the current v8.0
and the new bytecode compiler in v8.x. Big difference. Even in the
pre-8.0 release there are tricks to speeding up the intrepretation.
For Tcl, it's nearly trivial to write up any time critical code in, la
bing!, C and have a nice hybrid solution which is fast *and* easy. Given
your relative numbers I expect that solution to have be between C & Java
but to scale like the C solution.
Of course, if you're wanting to write "applets" your only choices out of
that list are Java & Tcl.
Take care,
John
: Etc.
: Take care,
: John
Versions used were:
C GCC 2.7.2.1
PERL 5
Java Sun 102 JDK for FreeBSD
Tcl 7.6
VB 3.0
I didn't specify any optimization parameters; it seemed 'fair' to
go with the defaults in each case. Nor did I make any attempt to
hand-optimize the code in any language; I just transliterated the
code from the original version in C.
I will get a copy of TCL 8.x and try it; it sounds like a significant
improvement.
What do you mean by writing applets in Tcl? Is there any way to
get them executed in a browser?
Thanks for the comments!
Mike Jeays wrote:
>
> -------------------------------------------------------T
> TIMING EXPERIMENT - C, JAVA, Visual Basic, PERL and TCL
> -------------------------------------------------------
[results deleted]
It's commonly admitted that Tcl prior version 8 is slow for
CPU-intensive
operation - about 10 times slower than Perl for the same task. Now that
Tcl8
has a bytecode compiler, Tcl and Perl perform quite the same (sometimes
slower,
sometimes faster).
> I had thought that I wouldn't bother to learn Perl, as I like
> Tcl/Tk for its clean design and regularity. Now I am not so
> sure. I shall certainly learn more about Java, as it provides
> a clean and elegant alternative to Tcl/Tk for building GUI interfaces
What? AWT is clean and elegant! BLEUAAAAARGHHHHH!!!!!!!!
Ahem, sorry for the carpet ;-)
Seriously, AWT is the most bloated and self-confused GUI toolkit I've
ever seen.
It's a shame that Sun didn't choose Tk instead. With AWT, forget Tk's
power
as for binding definition and geometry management. What d'ya mean, no
callbacks? ;-)
And forget about interactive/incremental development.
> quickly, with much better performance for raw calculation. But it
> still seems rough around the edges - Tk interfaces seem to look
> much better than Java ones.
That's because AWT sucks ;-)
You can have a look at the following alternatives, depending on your
taste (or your manager's :) (I've just listed those involvingeither Tcl
or Tk, or both):
1 Tcl + Tk
2 Perl + Tk
3 Scheme + Tk
4 Jacl (Tcl written in Java) + Tcl-AWT bindings
5 Python + Tk
AFAIK, only (1) and (4) allow Web browser applet development. with (5)
they only
work with the Grail web browser.
See you, Fred
--
Frederic BONNET fbo...@irisa.fr
Ingenieur Ecole des Mines de Nantes/Ecole des Mines de Nantes Engineer
IRISA Rennes, France - Projet Solidor/Solidor Project
------------------------------------------------------------------------
Tcl: can't leave | "Theory may inform but Practice convinces."
$env(HOME) without it! | George BAIN
Yes, just like Java applets (although you have to install the plugin
yourself). See:
http://sunscript.sun.com/products/plugin.html
Oddly enough (or rather not so odd), both Java and Tcl are developed at
Sun (although they had radically different roots).
--
Jeffrey Hobbs jeff....@acm.org|jho...@or.cadix.com
Software Engineer, Oregon R&D office: 541.683.7891
CADIX International, Inc. fax: 541.683.8325
URL: http://www.cs.uoregon.edu/~jhobbs/