VecTcl was designed to be a linear algebra package for Tcl resembling other concepts of Tcl as much as possible. In contrast to most, if not all, other vector packages it provides value semantics by implementing a proper Tcl_ObjType for the data storage. This has the advantage that other code (Tcl or C) knowing nothing of VecTcl can use the data directly, though the exchange is more efficient with adapted packages. Since the values are first-class objects using this approach, the data can be passed to and returned from Tcl procs with no additional code involved. Collecting the data in lists or dicts, returning multiple values from a proc, automatic memory management by the interpreter, extending the mathematical language by writing a Tcl proc, all of this comes naturally along with the approach taken by VecTcl.
The overall performance of the current implementation is quite satisfying, especially compared to other competing packages for Tcl. In some cases, there is still a large performance gap to bridge to native code. Some limitations in performance can only be resolved by compiling to native code. Since the VecTcl language definition is more strict than Tcl itself, compiling to native code is a feasible task and some experiments will be performed using tcc4tcl as a JIT backend.
Of equal importance for the overall performance is the shimmering itself, i.e. passing the data back and forth between VecTcl’s internal representation and the Tcl native data types. The linear regression benchmark including the setup time shows that VecTcl beats the competitors with ease in this field, still the actual computation is 5× faster in VecTcl than the shimmering. Reaching this performance requires a few tricks to be played, at least one of them crossing the border of intruding into the innards of the Tcl core. It would be good, if the Tcl core, possibly Tcl 9, could provide a clean way to access the necessary bits without dirty hacks. For a fast vector extension in the spirit of VecTcl, especially a method to examine the type of the internal representation without causing shimmering would be needed, as well as an analogue to the updateStringProc which converts a Tcl_ObjType to a list. Further on the wishlist could be found extended support for NaNs, exposing all functions which parse and print arithmetic types, exposing the functions which parse lists, maybe inclusion of the complex number type into the core, and faster command dispatch.
Read more about