Re:Extending Tcl
by gaius on Sunday May 13, 2018 @11:35AM
(#17059423)
Really, it flies compared to Ruby...
[ Parent
| on HN ]
Not really. I did some prime number crunching and it's the slowest of them all. Maybe for simple scripts working with strings, but otherwise I'd pick Lua any day. LuaJIT just runs circles around other dynamic languages, only compiled stuff is able to beat it.
Tcl - or Ruby, Python without NumPy (which is an extension) or most scripting languages are not the right tool for the job for number crunching.
Re:Extending Tcl
by ptrott2017 on Sunday May 13, 2018 @04:13PM
(#17060801)
As DavidW points out Out of the box Tcl (like most scripting languages) was never designed for numeric processing. If you want to do numerics and number crunching in Tcl use one of the extensions such as Vectcl or the Mathemtcl. Tcl's C APi makes writing extensions (or wrapping existing libs) pretty straight forward too.
Right - both Python and Tcl/Tk are intended to offload heavy processing to C functions that they stitch together with high level controls.
Note that the toplevel link is to a page full of simple techniques for enhancing base Tcl with C, Fortran, Lua etc. code, suggesting that Tcl offers the shortest path from dynamic language to serious number crunching power when it is needed.
Is that right ? I have never used Ruby. I should have my expectations on running time in check in case I do try Ruby out -- I have been meaning to.
I don’t dislike Ruby - you can do some very clever things in very little code with it. But it is far from high-performance!
Early Tcl was slow - but it was being compared to pure C. Recent Tcl is as snappy as any HLL.
Early (pre-8.0) Tcl was also literally string-processing the scripts. 8.0 brought a byte-compiler and the TclObj internal structure that maintained “native” values for types (I.e: a value “1.2” used as a floating-point value had its value cached as a float/double, versus reconstituting it from the string “1.2” every time it was needed. Note too this conversion happened nearly 20 years ago[0]. These days there’s some excitement surrounding the byte-compiling targeting LLVM[1], so faster still...