From: Twylite <tw...@cr...> - 2008-04-29 21:32:55
|
> > From: "Alexandre Ferrieux" <ale...@gm...> > Subject: Re: [TCLCORE] [SPAM] [6.0] Re: base64 in the core? > > Now this part is clarified, may I ask about the strength of the motivation ? > Are there compelling examples of a need for [string foreach] except > for toy Huffmann encoders, toy base64-again, or even toy-parsers ? > Greased lightning for toys ? > > -Alex > Why toy? I understand your suggestion that all of these examples are "toys" to mean that you would consider a Tcl implementation of any of this functionality to be a "toy", further implying that a "real" implementation would be in C as an extension. What about those of us that use Tcl as a fully functional language and don't intend to drop to C every time we need to do something that vaguely resembles byte- or number-crunching in a reasonable period of time? For example many of the crypto primitives implemented in pure Tcl are around two orders of magnitude slower than a C equivalent, making them unusable in many applications. To sign a mail with 1Mb attachment in pure Tcl takes 16s for the SHA1 alone. Improving that by one order of magnitude - which a function like "string foreach" may be able to do - would make SHA1 usable for real-world applications. Bignum support has already brought pure-Tcl RSA performance to around 50% that of C (basic square-and-multiply algorithm) showing that a bit of framework support can make all the difference. I like Donal's suggestion of a scripted mock-up - I've already started looking at it and noticed that some algorithms favour a character representation for the iteration variable while others favour an int - an immediate API complication. Regards, Trevor |
From: Alexandre F. <ale...@gm...> - 2008-04-30 13:03:28
|
On 4/29/08, Twylite <tw...@cr...> wrote: > > > > From: "Alexandre Ferrieux" <ale...@gm...> > > Subject: Re: [TCLCORE] [SPAM] [6.0] Re: base64 in the core? > > > > Now this part is clarified, may I ask about the strength of the motivation ? > > Are there compelling examples of a need for [string foreach] except > > for toy Huffmann encoders, toy base64-again, or even toy-parsers ? > > Greased lightning for toys ? > > > > -Alex > > > Why toy? I understand your suggestion that all of these examples are > "toys" to mean that you would consider a Tcl implementation of any of > this functionality to be a "toy", further implying that a "real" > implementation would be in C as an extension. Yes, that's the implication. It's no shame, Tcl is a wondeful glue, it's simply not chasing the same part of the spectrum as C or even native-compiled SML. > What about those of us that use Tcl as a fully functional language and > don't intend to drop to C every time we need to do something that > vaguely resembles byte- or number-crunching in a reasonable period of time? Don't get me wrong. I'm even part of this population, see my recent patch for efficient concatenation of byte arrays (I use it for various block-level tasks, like RTP encapsulation). I'm not at all excluding Tcl from any computing domain; but when you get down to these granularities (byte or character level), the contribution of the body of the foreach quickly dominates any overheads in the iterator itself. So of course I'm all in favour of a pure-Tcl [string foreach]. What I'm questioning is the motivation of C-level work to optimize what looks like a minor part of the total time. Hence my question to the list, to identify possible cases of a "lighter weight" body I may have overlooked, that would justify the optimization. To make things clear, the following rough cut would IMO yield appropriate performance set bufsize 1000 set len [string length $s] for {set pos 0} {$pos<$len} {incr pos $bufsize} { foreach c [split [string range $s $pos [expr {$pos+$bufsize-1}]] ""] { BODY } } (Of course a bit more work is needed to properly handle [break] in the body, but you get the idea) -Alex |