| Ticket UUID: | 2981677 | |||
| Title: | Shrink TEBC Activation Record | |||
| Type: | Patch | Version: | None | |
| Submitter: | dkf | Created on: | 2010-04-03 23:42:51 | |
| Subsystem: | 47. Bytecode Compiler | Assigned To: | dkf | |
| Priority: | 5 Medium | Severity: | ||
| Status: | Closed | Last Modified: | 2010-04-28 17:53:42 | |
| Resolution: | Accepted | Closed By: | dkf | |
| Closed on: | 2010-04-28 10:53:42 | |||
| Description: |
The attached patch shrinks the size of the activation record (stack frame size) of TclExecuteByteCode. This should make it a bit less unfriendly. It also shortens that function quite a bit in terms of number of lines of source code. (Note that it keeps math operations on pairs of longs directly in TEBC if it can; I've not studied whether that is worth it.) Benchmarking with tclbench is inconclusive on this machine at least, but with the state of my sandboxes I could be way off base. | |||
| User Comments: |
dkf added on 2010-04-28 17:53:42:
allow_comments - 1 Some slight tinkering lead to overall speed improvements with tclbench across all global measures (arithmetic, geometric and harmonic means) so now committed. One other benefit: TEBC is now a shorter function in terms of general source code length. Still scarily full of gotos, but now with only 4700 lines in total... :-) dkf added on 2010-04-23 20:51:20: Find an updated version. This gets TEBC down to a stack size of 524 bytes, which is a lot closer to being reasonable. Again, the results from tclbench are rather difficult to interpret. dkf added on 2010-04-23 20:48:02: File Deleted - 370064: dkf added on 2010-04-23 20:47:01: File Added - 371637: tebc.stacksize.patch 2.zip dkf added on 2010-04-10 05:41:59: File Added - 370064: tebc.stacksize.patch dkf added on 2010-04-10 05:41:33: File Deleted - 369947: dkf added on 2010-04-09 06:04:02: File Added - 369947: tebc.stacksize.patch dkf added on 2010-04-09 06:03:22: File Deleted - 369946: dkf added on 2010-04-09 05:53:00: File Added - 369946: tebc.stacksize.patch dkf added on 2010-04-09 05:52:14: File Deleted - 369350: ferrieux added on 2010-04-04 22:30:00: To get a more "runtime" view, I tend to extract the address of locals in a caller and a callee of the function of interest. In the TEBC case, a breakpoint in some library func like [socket] yields a stack with TclNRRunCallbacks TclExecuteByteCode NRCallTEBC and extracting "&iPtr" under gdb in both TclNRRunCallbacks and NRCallTEBC yields: (gdb) frame 2 (gdb) print &iPtr $1 = (Interp **) 0xbffff194 (gdb) frame 4 (gdb) print &iPtr $2 = (Interp **) 0xbffff65c so here the offset is 0x4C8. Of course this may also include some contribution from the caller's and callee's activations records, but in this specific case they should be small (neither big local arrays nor alloca). dkf added on 2010-04-04 21:51:00: BTW, gdb can take apart tclExecute.o directly for this information. You can skip the linking step. dkf added on 2010-04-04 21:50:01: There is a way. Use gdb to disassemble TEBC and look for a line like:
add $0x2fc,%esp
It's near the very end of the function. That 0x2fc is the activation record size. (There's an equivalent 'sub' near the start of the function too.) I know of no more direct way to get this information.
msofer added on 2010-04-04 19:42:45: Do we have any way to measure the size of the stack frame? dkf added on 2010-04-04 06:42:51: File Added - 369350: tebc.stacksize.patch | |||
Attachments:
- tebc.stacksize.patch 2.zip [download] added by dkf on 2010-04-23 20:47:01. [details]