Re: some suprises with different languages

On Sat, 05 Jan 2008 10:35:32 +0100, Friedrich Dominicus
<just-for-news-frido@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

I hope this is not understood as yet another flamewar. I'm just
suprised by few findings. I have a very simple problem which just
extracts some numbers from files adds it. Well the number of files to
be searched currently are around 1600. I implemented this extraction
in nearly every language I've used before and got some suprising
results.

The fastest wasn't C with the "wrong" library although. The "wrong"
library in this case was pcre, which provides regular expressions as
one is used to from Perl. Ocaml was quite fast constantly and among
the "fastest" solutions. That's not such a bit suprise because OCaml
seems to be quite fast in general. Another suprise to me was that the
Shell solution was among the fastest also. It really seems they have
spend a lot of time making this tools blazingly fast (especially for
text and file handling)

The so called "scripting languages" like Tcl and Ruby were quite fast
also and indeed they were faster then the C solution while using
libpcre, not that a big suprise because scripting languages are
somewhat optimized for text handling.

However I still would expect the compiled languages to be faster then
the scripting languages. But in this area this is not "generally"
true.

As written before using libpcre was much slower then the scripting"
solutions using the Unix Shell was faster then every other solution.

Now I tried my luck with Java also, but found it to be considerably
slower than the scripting languages, and expectedly slower then the "native"
compilations. I guess I should not be suprised that much, but was.

What was interesting also was the amount of code needed:
In reverse order
101 C
80 Ocaml
67 Java
59 Haskell
56 Erlang
49 Tcl
45 Common Lisp
26 Ruby
5 Shell

Yes I know LOC can be tweaked very much. But I do not even have
tried. Just tried to wrote it down as readable as I usual. I'm not
that firm in every language then I'm in C. So the "effort" for me was
quite different and "not" very much depend on the LOCS. Shell was
written down in a few minutes. The Ruby and Tcl stuff in the same amount of
time, then C then Common Lisp has took a bit shorter than Ocaml, same time for Java
(I'm not very used to that language) and Haskell and Erlang.

Ocaml was a bit less difficult because the programming model for
"sequential" actions is not that different from other "imperative
object-oriented" languages. The Erlang stuff is a bit more complex
because of its single time assignment to variables. The Monads in
Haskell are yet another world ;-)

As written I'm not that suprised with all the results, but some really
have left me puzzling. In the end I just can confirm what others have
written before
1) Use the right tool for the job at hand
2) don't underestimate the power of small tools and the strange SHELL
stuff ;-)
3) if you do administration tasks on Unices the so called Scripting
languages are a really good tool
4) knowing a tool quite well makes up quite a lot for building a
solution
5) machines are unbelievable fast these days, just imagine the files
contain 1 555 755 lines and 86 MB data and the fastest solution does a malloc/free
combination on every match and runs in just 0,378 seconds.

Just imagine every file has to be opened and closed, and it is read
line-by-line. And it's still done in just a third second...., and just
the CPU knows what other task are done in between ;-) At least I can
browse, write, download and do wahtever I like and do not even
"recoginze" that 86 MB of data are scanned

As written before I can understand a few results but have problems
with others.
1) why wasn't Java a bit better then the scripting languages?
2) what's the problem with the following regular expression with
libpcre
char *findRegexp = "(\\d+) Windows executable";
neither Ruby, nor Tcl nor Ocaml were that bad on this regular
expression

It's just one backreference.



Regards
Friedrich

Friedrich,

Have you tried (icon,unicon) or (snobol, spitbol) or awk, all of which
are string processing languages?
Ed
.

Relevant Pages

  • some suprises with different languages
    ... That's not such a bit suprise because OCaml ... The so called "scripting languages" like Tcl and Ruby were quite fast ...
    (comp.lang.misc)
  • Scripting 101
    ... automation environment and it allows me to quickly create software to ... although somewhat primitive compared to scripting languages ... However, unlike most programming languages of the time, these scripts ...
    (comp.home.automation)
  • Re: Registry free COM for VBScript Clients
    ... By "VBScript client" you mean a running .vbs file? ... could be any computer language including scripting languages, .NET languages, regular VB, C++. ... The least powerful of these languages are the scripting languages. ...
    (microsoft.public.scripting.vbscript)
  • Re: Newbie Looking for a Language
    ... I have heard mixed reviews of PHP and I ... wonder if it's the best one to invest in learning as a first language. ... May impression so far is that non-scripting languages can do everything ... scripting languages can not do. ...
    (comp.lang.php)