Language speed [was Good TK book]

Language speed [was Good TK book]

Post by Rober » Thu, 30 Dec 2004 12:07:29


On 12/28/04 1:06 PM, in article 41d1a0a5$0$1688$ XXXX@XXXXX.COM ,


<snip>
I would have to disagree about Pythons speed. Of the big four, (Ruby Python
Perl Tcl), "generally" Python is about the quickest depending on what
strengths you play to. That doesn't mean I like Python, I am Perl fan first
and then a Tcl one, and I am trying to change that order. :-)

That is just my opinion of course, it would be interesting to see an updated
shootout using: Perl 5.8.6, Python 2.4, Tcl 8.4.9 and Ruby 1.8.2

Maybe a small site dedicated to just that may be in order. I could get code
samples from the actual people groups that use the languages themselves.

Robert
 
 
 

Language speed [was Good TK book]

Post by Rober » Thu, 30 Dec 2004 12:27:00

Spoke to soon...another site is updating a shootout.

http://www.yqcomputer.com/
ort=cpu

Robert

 
 
 

Language speed [was Good TK book]

Post by Eckhard Le » Thu, 30 Dec 2004 20:02:31

Robert schrieb:

Well, that are algorithm benchmarks. Usually users of a program don't
recongize the execution speed of particular algorithms (or they don't
care), the first speed lacks they mention are GUI and IO related.

It would be interesting how the different languages perform in this
areas. Some time ago I have seen benchmarks including IO and Python was
orders of magnitude behind the other languages (I don't remember the
link). Okay that was before Python 2.2, it is possible that this has
changed in the last 3 releases.
But still there is the question of GUI performance. When I remember
right Python executes Tcl code to get Tkinter working, doesn't it? I
have done some things in Tkinter and as long as I remember, it is
horrible slow.


Eckhard
 
 
 

Language speed [was Good TK book]

Post by John Perr » Fri, 31 Dec 2004 00:45:49


Looking at the way they score, a "no program" or "error" in a benchmark
results in a zero for that benchmark. Any other score is weighted and
added to the total.

Looking at the detailed scores of perl, python, tcl, and lua, tcl has
much higher individual scores, but many more "no program" scores. Tcl's
score is artificially low because it just isn't tested in so many
benchmarks.

jp
 
 
 

Language speed [was Good TK book]

Post by Bob Techen » Fri, 31 Dec 2004 02:28:37

"John Perry" < XXXX@XXXXX.COM > wrote

http://www.yqcomputer.com/



I looked at these too, and I don't quite understand how their
benchmarking works. I tried downloading their whole package (from
CVS), but it requires some perl module that isn't on my system. :-(

But when *I* run wc.tcl and wc.perl, they seem to run about 2x
different, instead of the 6x different that they report.

Hm. Looking at wc.tcl, it uses regexp to count words and lines. That
can be done faster with split. I think I'll submit an update.

Bob
--
Bob Techentin XXXX@XXXXX.COM
Mayo Foundation (507) 538-5495
200 First St. SW FAX (507) 284-9171
Rochester MN, 55901 USA http://www.yqcomputer.com/
 
 
 

Language speed [was Good TK book]

Post by david » Fri, 31 Dec 2004 02:34:00

John Perry < XXXX@XXXXX.COM > writes:


High in 'cpu time' benchmark isn't good, unfortunately.

In most of the ones I looked at, Tcl is just a tad slower than Perl,
and more or less faster than PHP...

--
David N. Welton
Personal: http://www.yqcomputer.com/
Apache Tcl: http://www.yqcomputer.com/
Free Software: http://www.yqcomputer.com/
Linux Incompatibility List: http://www.yqcomputer.com/
 
 
 

Language speed [was Good TK book]

Post by Stefan Fin » Fri, 31 Dec 2004 05:52:06

Is it legal to change the code to the specific strengths of language
implementations while comparing programming languages and scripts?

Prefering real live algorithmens over theory meets our needs for
programming.

Of cause, this would change the raw algorithmen. But each algorithmen
has to deal with its coding or executable representation.

E.g. caching can be very helpful within recursions to save memory and
speed up applications.

The original code at this site
( http://www.yqcomputer.com/ )

proc fib {n} {
if {$n < 2} {
return 1
} else {
return [expr {[fib [expr {$n-2}]] + [fib [expr {$n-1}]]}]
}
}

requires really a lot of time:

% time {fib 32} 100
5789520 microseconds per iteration

The modified proc uses tcl dynamic array strength for caching and
requires almost no time (250 milliseconds) compared to above.

proc fib {n} {
global cache_fib
if {$n < 2} {
return 1
} elseif {[info exists cache_fib($n)]} {
return $cache_fib($n)
} else {
return [set cache_fib($n) [expr {[fib [expr {$n-2}]] + [fib\
[expr {$n-1}]]}]]
}
}

catch {array unset cache_fib}
% time {fib 32}
242 microseconds per iteration

% time {fib 32}
14 microseconds per iteration

At least the Ackermann benchmark at this site is another example for Tcl
to glance like this. See http://www.yqcomputer.com/
 
 
 

Language speed [was Good TK book]

Post by david » Fri, 31 Dec 2004 06:07:07

Stefan Finzel < XXXX@XXXXX.COM > writes:


Yes and no, I think. In some cases, they just want to see how quickly
a language can get something done. In others, they want to test a
particular feature of a language. It's all a bit unscientific in any
case, but do write them if you feel you can speed up some of the Tcl
code!

--
David N. Welton
Personal: http://www.yqcomputer.com/
Apache Tcl: http://www.yqcomputer.com/
Free Software: http://www.yqcomputer.com/
Linux Incompatibility List: http://www.yqcomputer.com/
 
 
 

Language speed [was Good TK book]

Post by Bob Techen » Fri, 31 Dec 2004 06:29:17

"David N. Welton" < XXXX@XXXXX.COM > wrote
language
quickly
any

The Ackermann benchmark is supposed to exercise the call stack with a
viscously recursive procedure. So there might be trickier ways to get
the same answer, but they won't match what the benchmark is trying to
accomplish. I noticed that many interpreters crash on Ackermann,
including Tcl. I just submitted an update to the mailing list with a
recursionlimit set, so it should work for them now.

The word count benchmark is also interesting, because it must meet the
constraint of only reading 4k characters at a time. That makes
counting complete lines a lot trickier. Of course, the "proper" Tcl
way to code such a task exploits Tcl's strength as a glue language.
Just this single line does the trick, and it runs pretty fast, too.
:-)

puts [exec wc <@ stdout]

Bob
--
Bob Techentin XXXX@XXXXX.COM
Mayo Foundation (507) 538-5495
200 First St. SW FAX (507) 284-9171
Rochester MN, 55901 USA http://www.yqcomputer.com/
 
 
 

Language speed [was Good TK book]

Post by david » Fri, 31 Dec 2004 06:51:51

"Bob Techentin" < XXXX@XXXXX.COM > writes:



Well, where wc exists, at least. I don't think they really allow that
sort of thing though - it's not like other languages don't have 'exec'
of some kind.

Along those lines, the original great language shootout had shell
scripting as a language... I managed to write the fastest file
reverser:

----
#!/bin/sh

tac
----

:-)

--
David N. Welton
Personal: http://www.yqcomputer.com/
Apache Tcl: http://www.yqcomputer.com/
Free Software: http://www.yqcomputer.com/
Linux Incompatibility List: http://www.yqcomputer.com/
 
 
 

Language speed [was Good TK book]

Post by neuman » Fri, 31 Dec 2004 07:01:17

This version seems to need some finishing touch:
i have not looked in details, but found the following strangenesses:
- thread benchmark: LUA seems to create 1000 threads, not 3000
as required
- thread benchmark: Java result failed, but it is counted
- regex for tcl says: "No program", clicking on it shows a
tcl program
- ackermann runs out of stack. It should be possible to fix it
with "interp recursionlimit ..."; the following version
should be somewhat faster than the version with expr.

-gustaf
PS: Google news did not let me follow up, so i had to remove the "re:"
from the subject line.

===================================================================
interp recursionlimit {} 100000
set NUM [expr {[lindex $argv 0] < 0 ? 1 : [lindex $argv 0]}]

proc ack {m n} {
if {$m == 0} { incr n
} elseif {$n == 0} { ack [incr m -1] 1
} else { ack [expr {$m - 1}] [ack $m [incr n -1]]
}
}

puts "Ack(3,$NUM): [ack 3 $NUM]"
 
 
 

Language speed [was Good TK book]

Post by Bob Techen » Fri, 31 Dec 2004 07:51:08

"Gustaf Neumann" < XXXX@XXXXX.COM > wrote

Gustaf,

I just submitted a new ackermann.tcl setting recursion limit. I tried
replacing [expr {$m-1}] and friends with [incr m -1]. Small positive
difference for [incr n], and no difference, or perhaps even a penalty
for [incr m -1].

Bob
--
Bob Techentin XXXX@XXXXX.COM
Mayo Foundation (507) 538-5495
200 First St. SW FAX (507) 284-9171
Rochester MN, 55901 USA http://www.yqcomputer.com/
 
 
 

Language speed [was Good TK book]

Post by clair » Fri, 31 Dec 2004 08:08:10

In article < XXXX@XXXXX.COM >,

.
.
.
.
.
.
From a Tcl perspective, other languages' "exec"-s can be *quite* clumsy.

I'm far enough off-topic that I'll close now.
 
 
 

Language speed [was Good TK book]

Post by david » Fri, 31 Dec 2004 08:12:41


XXXX@XXXXX.COM (Cameron Laird) writes:


Where Tcl gets it right (socket is another example), its abstractions
are beautiful, IMO. Things like Python kind of plod along with
something close to the C interface of whatever library functions,
whereas Tcl cuts to the heart of the matter with a quick, simple,
incisive command like 'socket'.

--
David N. Welton
Personal: http://www.yqcomputer.com/
Apache Tcl: http://www.yqcomputer.com/
Free Software: http://www.yqcomputer.com/
Linux Incompatibility List: http://www.yqcomputer.com/
 
 
 

Language speed [was Good TK book]

Post by Stefan Fin » Fri, 31 Dec 2004 18:07:35

The real question is not to test a specific implementation of an
algorithmen but to compare the usefullness of languages.

As for me I do not want to test the algorithmen itself, but its
representation and runtime behaviour. (My customers are not interested
in true programmers they like a true solution.)


Benchmarks should never force a way to write a code of its solution.
Maybe Ackermann/Fibonacci are good examples of testing the call stack
but "cheating" is appropiate.

No one of us would write bad, inefficient code if it can be avoided. The
availablity and simplicity of "cheating" is a major part of a languages
flexibility and has to be evaluated too.

Ok. There should be a limit of cheating. It should be done in raw Tcl
(the exec example make me really lol) and not to clumpsy like

array set ack { 0,4 5 1,3 5 4,0 13 3,1 13 2,2 7 0,5 6 1,4 6 2,3 9 3,2 29
0,6 7 1,5 7 2,4 11 3,3 61 0,7 8 1,6 8 2,5 13 3,4 125 0,8 9 1,7 9 2,6 15
3,5 253 0,10 11 0,9 10 1,8 10 2,7 17 3,6 509 1,9 11 2,8 19 3,7 1021 2,10
23 2,9 21 3,8 2045 0,0 1 1,0 2 0,1 2 1,10 12 2,0 3 1,1 3 0,2 3 0,3 4 3,0
5 2,1 5 1,2 4 }
puts $ack($M,$N)