Tcl Source Code

Enclosing an alternative implementation for the
bytecoded {expand} functionality - this is the update
of tip157.patch.2 of [Patch 827119]. It builds the
expanded command as a list at stacktop,instead of
expanding into the stack (or malloc'ed mem if not
enough stack present).

This is likely to be slower than the version in HEAD in
the worst case (more ckalloc and copying), but it is
somewhat simpler:
  - no instructions with variable number of operands
  - the maximal stack required by the bytecode is still
known at compile time

File Added - 87354: expand-inplace-commit.patch

Logged In: YES 
user_id=148712

Committed the inplace version while still in alpha -
committed path attached.

The advantages are:
  - faster
  - no changes to INST_INVOKE(1|4)
  - simpler compilation code
  
Another difference, with pros and cons, is that the
execution stack is grown when needed, instead of allocating
a temporary buffer. Pro: faster execution  for subsequent
{expand}, where the probability of not having enough stack
is lower. Con: memory is allocated forever after, not
returned to the OS.

Logged In: YES 
user_id=79902

Speed vs. Simplicity?  Err, hard choice.

File Added - 68307: expand.bench

File Deleted - 68269: 



File Added - 68306: expand.result

Logged In: YES 
user_id=148712

New, expanded benchmark. Summarizing the results when
expanding lists of up to 10 elements (typical case?):
H: HEAD, I: Inplace, L: list, timings in usecs/call:
- for [{expand}$cmd]:  H7, I6, L5 (pure list opt: 6)
- for [$cmd A {expand}$lst B]: H7, I6, L9
- as before, but A and B longer expanded lists: H18, I15, L22
Amazingly, the list version seems to be faster when
expanding long lists (100 to 1000 elements).

Given the very slight differences, I'm inclined to opt for
the list-based version: it is much simpler and it does not
interfere with the evaluation stack mechanics. Other opinions?

File Deleted - 68267: 



File Added - 68269: expand.bench

File Deleted - 68266: 



File Added - 68268: expand.result

Logged In: YES 
user_id=148712

Oops - that was a wrong benchmark, not measuring much.
Updated files,not definitive yet.

The results are similar - except that both head and inline
show nonlinear behaviour in the list size.

File Added - 68267: expand.bench

File Added - 68266: expand.result

Logged In: YES 
user_id=148712

Attached a benchmark script and timing results: results show
that
  - t(list) < t(inplace) < t(eval) < t(head)
        for [{expand}$cmd] (resp. [eval $cmd])
  - t(inplace) < t(head) < t(list)
       for [cmd A {expand}$lst B]

File Deleted - 67809: 



File Added - 68032: expand-inplace.patch

Logged In: YES 
user_id=148712

Patches updated so that they apply to HEAD

File Deleted - 67546:

File Added - 68031: expand-list.patch

File Deleted - 67792: 



File Added - 67809: expand-inplace.patch

Logged In: YES 
user_id=148712

Updated expand-inplace, corrected compile time stack depth
estimation:
  - fix thread-safety (spotted by dkf)
  - added detailed comments

File Deleted - 67706: 



File Added - 67792: expand-inplace.patch

Logged In: YES 
user_id=148712

who put it there?

Logged In: YES 
user_id=80530

BTW, the expandLinkList
declaration is in the wrong place.

Logged In: YES 
user_id=80530


looks like it should work.

File Deleted - 67604: 



File Added - 67706: expand-inplace.patch

Logged In: YES 
user_id=148712

Inplace patch revised: better stack estimation, fix for
compile-debug that bypasses the stack depth check when an
expansion is in progress.

Logged In: YES 
user_id=79902

expand-inplace.patch is faster than HEAD on short expansions
but blows up when built with --enable-symbols=all due to
failing the max-stack-depth check.

expand-list.patch is slower than HEAD on short expansions,
and like the HEAD it is safe with --enable-symbols=all

Test code used for this evaluation:
   proc foo args {llength [list {expand}$args]}

File Added - 67604: expand-inplace.patch

Logged In: YES 
user_id=148712

Attached expand-inplace.patch that expands directly to the
stack, without copying non-expanded arguments. The execution
stack is grown at run time if it is not large enough to
accomodate this command.
It is simpler IMHO than the implementation at HEAD, and
should be slightly faster too. It does not require
instructions with variable number of arguments (+).
Assigned to dgp for comment.

File Added - 67546: expand-list.patch