Squeak-dev February 1999

squeak-dev@lists.squeakfoundation.org

148 participants
356 discussions

Re: getting started
by geb＠softworlds.com 25 Feb '99

25 Feb '99

At 2:33 PM 2/23/99, Lex Spoon wrote: >Squeak will be fine with just about anything you can buy in the stores >today. Here's a stab at some comfortable, inexpensive "minimums" -- you >can do with less, but these are really cheap and will definately be >safe: > > - Pentium 166 > - 32 MB of RAM > - a video card that does 800x600 with 64k colors > - a three button mouse > >So why do people bother to sell all these expensive computers in the >store? That would be games, games, and games. Isn't one of the goals of Squeak Central to be able to create animated games with Morphic? Seems to me that the fastest cpu available wouldn't be too fast. Regards, Gary ---- Gary E. Bloom Editor, Softworlds for Children geb(a)softworlds.com

1 0

Heckbert's algorithm
by Andres Valloud 25 Feb '99

25 Feb '99

Hi. Playing with GIFReadWriter I noticed that the bitdepth allowed for forms is 8. This is not correct... the GIF format would allow a ColorForm of 256 true color colors, and #asFormOfDepth: 8 does not provide satisfactory results. So, I'm planning to implement Heckbert's color quantization algorithm, as a replacement for colorReduced. Is anyone already doing it? I wouldn't like this to be done twice as it looks like a big thing to do to me... in fact I haven't found a neat design for the whole thing yet. Andres.

1 0

Speed of SGI VM: 2.3 vs 2.2
by Bill Cattey 25 Feb '99

25 Feb '99

To continue to ponder the performance issue raised by Doug Way, I fetched 2.2 and built it on the SGI. For some reason, the default compilation flags -32 -mips2 build me a VM that core dumps. The compilation flags -n32 -mips3 build me a working one that ends up almost, but not quite as fast as the 2.3VM I have in hand. Average time for the little100 factorial benchmark: 2.2 VM for IRIX 5.3 from Ian: ~34ms 2.3 VM for IRIX 6.3 I built: ~38ms 2.2 VM for IRIX 6.3 I built: ~38ms Do people think this performance is reasonable, or that there are some things I should try to measure whether this performance difference is significant? Are there suggestions about what to try to win back the performance achieved by the old VM build? -wdc

1 0

Re: Optimizing Squeak
by Jeffrey Chapman 25 Feb '99

25 Feb '99

> written such a program for the PPC, but I don't believe there are patchers > for most of the other Squeak platforms. As I recall, patching out the > bounds check speeds up the PPC VM by about 15-20% on bytecode-heavy > benchmarks. Folks maintaining other VM's might want to look into this > technique. (It only takes a few hours of studying assembly code listings to > figure out how to do this for a new architecture. See > > Interpreter class>patchInterp: > > for an example of how to do it. Is it reasonable to assume that the 'official' PPC VM ships with this patch already applied?

2 1

Virtual Machine Worshop at OOPSLA
by johnm＠wdi.disney.com 25 Feb '99

25 Feb '99

I've greatly enjoyed the recent "Optimizing Squeak" thread. Folks interested in Squeak VM optimization might be interested in an OOPSLA workshop that I'm putting together with Antero Tailvalsari of Sun entitled something like "Simplicity versus Performance in Virtual Machine Design". The focus of the workshop will be not simply how to make faster VM's, but how to balance performance against other considerations such as portability, size, maintainability, and simplicity. Participants will have to submit and present a short working paper on some aspect of VM design (such as Jan's bytecode set proposal) for discussion. Unfortunately, attendence will have to be limited in order to keep the group small enough to support discussion. The workshop will not be Squeak-centric; I hope Java, Lisp, and other languages will be represented. OOPSLA workshops are held a day or two before the conference proper. I hope to see some of you there! -- John

2 1

Re: A few low-level Pentium II performance measurements
by johnm＠wdi.disney.com 24 Feb '99

24 Feb '99

Jan Bottorff <janb(a)pmatrix.com> wrote: > The performance of the test machine to '0 tinyBenchmarks' was '12195121 > bytecodes/sec; 671316 sends/sec'. As it's doing 1.1 clocks per machine > instruction, this implies an average of 266,000,000 / 1.1 / 12195121 = > 19.82 machine instructions per bytecode, which seems a bit high to me. > Looking at the generated machine code (thanks to VTune disassembly) I count > around 12 instructions for a really simple bytecode+dispatch, so mabey the > data is correct. A hand crafted assembly interpreter could lose about half > those instructions. Jan, Very interesting! You might want to look at the two 'tiny' benchmarks separately. The "10 benchmark" one is basically a tight loop that does a lot of array accessing but has no full message sends in the loop. The "26 benchFib" one is very send-heavy, with few bytecodes between sends. Message send/return is a few hundred machine instructions. The average bytecode, with dispatch, is, as you discovered, about 12 instructions. I think your figure of "19.82 machine instructions per bytecode" is a weighted average of these two figures. > I'd be interested in seeing the G3 generated assembly fragments for > bytecodes like "push constant 0" and the bytecode dispatching loop. It > would be interesting to decide if the G3 compiler/instruction set generates > better code or if the G3 processor is just much faster at executing similar > code. Here you are, with annotations (which you probably don't need, but may interest other folks)!! Hunk: Kind=HUNK_GLOBAL_CODE Align=4 Class=PR Name=".interpret"(778) Size=13268 00000000: 7C0802A6 mflr r0 00000004: BDA1FFB4 stmw r13,-76(SP) 00000008: 90010008 stw r0,8(SP) 0000000C: 9421FF70 stwu SP,-144(SP) 00000010: 83420000 lwz r26,instructionPointer(RTOC) 00000014: 83020000 lwz r24,theHomeContext(RTOC) 00000018: 83820000 lwz r28,stackPointer(RTOC) 0000001C: 827A0000 lwz r19,0(r26) 00000020: 82C20000 lwz r22,messageSelector(RTOC) 00000024: 82E20000 lwz r23,successFlag(RTOC) 00000028: 81A20000 lwz r13,receiver(RTOC) 0000002C: 83220000 lwz r25,method(RTOC) 00000030: 83620000 lwz r27,argumentCount(RTOC) 00000034: 83A20000 lwz r29,specialObjectsOop(RTOC) 00000038: 829C0000 lwz r20,0(r28) 0000003C: 82B80000 lwz r21,0(r24) ;; The next instruction fetches the bytecode into r18 and increments the PC (r19). 00000040: 8E530001 lbzu r18,1(r19) ;; Here's the start of the dispatch. note the check for the bytecode being > 255 ;; (which is impossible, but the C compiler doesn't realize it). We patch that out ;; on the PPC dispatch, saving 2 instructions, which might explain part of the ;; PPC VM's speed advantage relative to the Pentium VM. 00000044: 281200FF cmplwi r18,$00FF 00000048: 4181FFFC bgt *-4 ; $00000044 0000004C: 80620000 lwz r3,@5762(RTOC) ;; load jump table base address 00000050: 5640103A slwi r0,r18,2 ;; shift bytecode left by 2 bits to form word offset and... 00000054: 7C63002E lwzx r3,r3,r0 ;; ... add it to the jump table base address 00000058: 7C6903A6 mtctr r3 ;; load the jump address in to the jump address register 0000005C: 4E800420 bctr ;; perform the actual indirect jump ;; Here's the first bytecode, pushReceiverVariableBytecode (inst var 1) ;; The first two instructions fetch the next bytecode into r18 and increment ;; the PC (r19), so the real work of this bytecode is done in just two instructions. 00000060: 806D0000 lwz r3,0(r13) 00000064: 8E530001 lbzu r18,1(r19) 00000068: 80030004 lwz r0,4(r3) 0000006C: 94140004 stwu r0,4(r20) 00000070: 4BFFFFD4 b *-44 ; $00000044 ;; Here's the second bytecode, pushReceiverVariableBytecode (inst var 2) 00000074: 806D0000 lwz r3,0(r13) 00000078: 8E530001 lbzu r18,1(r19) 0000007C: 80030008 lwz r0,8(r3) 00000080: 94140004 stwu r0,4(r20) 00000084: 4BFFFFC0 b *-64 ; $00000044 .... -- John

1 0

Re: Optimizing Squeak
by johnm＠wdi.disney.com 24 Feb '99

24 Feb '99

Carl Watts <Carl(a)AppliedThought.com> wrote: > Not if the bytecode is used to index into a 256 element jump-table. In this case there is no need for an array-bounds check and there are no conditional branches so no branch mispredictions can occur. You are right, Carl, most compiler generate an unneeded bounds-check in Squeak's bytecode dispatch loop (which is a 256-way case statement). It is pretty easy to write a small patch program in Squeak that finds the instruction sequence for the bytecode dispatch and patches out the unneeded check. We've written such a program for the PPC, but I don't believe there are patchers for most of the other Squeak platforms. As I recall, patching out the bounds check speeds up the PPC VM by about 15-20% on bytecode-heavy benchmarks. Folks maintaining other VM's might want to look into this technique. (It only takes a few hours of studying assembly code listings to figure out how to do this for a new architecture. See Interpreter class>patchInterp: for an example of how to do it. -- John

1 0

Re: getting started
by ted_creedon＠mentorg.com 24 Feb '99

24 Feb '99

Your first problem is getting linux to run and that depends on which X you use, MetroX or XFree86. My best results are to use logitech 3 button mice and MOST IMPORTANTLY pick a well supported board. I've tried trident cards - beware - there are 3 mfgrs using the trident chip set and the drivers don't work well at all (there are actually different drivers for W98 & NT). Use the Matrox Millenium II AGP dieplay card it you can. It works well and runs under all X implementations. 64 meg of memory is sufficient, more is better IDE drives are fine but adaptec 2940 ultra wide scsi is faster use xcdroast to write CD's use Samba to map your pc's into linux drives the automounter works fine as does NFS I use the red hat version of linux with xfree86 X11R6, I prefer linux to Solaris, AIX, HPUX but the windows API for NT is hard to beat. tedc

1 0

RE: getting started
by Raab, Andreas 24 Feb '99

24 Feb '99

Jerry, > Does Squeak actually use a three button mouse in a Windoze framework? > Yes. > Do you need specific device drivers to make this happen? > First, you have to have the right drivers installed on your machine (e.g., if your Windows mouse driver has to support 3 button mouses). Then, while running Squeak you can choose 'VM preferences' from the system window menu (or simply press F2) and select 'use 3 button mouse mapping'. NOTE: Some of the fancier new mouses give you all sorts of things you may do with the middle mouse button (starting from scrolling to double click simulation). I noticed that if you use any of those features, the middle mouse button gets not reported to the application (e.g., Squeak). So, for using a 3 button mouse you better turn off any of those extra stuff. Hope this helps, Andreas -- PLEASE NOTE NEW EMAIL ADRESS! +===== Andreas Raab ========= (andreasr(a)wdi.disney.com) ==+ | Walt Disney Imagineering Phone: +1 818 544 5016 I I Glendale, CA Fax: +1 818 544 4544 I +======< http://isgwww.cs.uni-magdeburg.de/~raab >========+

1 0

Re: That Linux Squeak 2.3 float error again
by Lex Spoon 24 Feb '99

24 Feb '99

"R. A. Harmon" <harmonra(a)webname.com> wrote: > At 08:41 PM 2/23/99 -0500, David T. Lewis wrote: > >Some further explanation of the behavior of Float>>exp in Squeak: > > > >The Float>>exp method in Squeak is based on the behavior of exp() in > >the C runtime library. The Squeak VM (at least on Unix) assumes that > >the underlying C library behaves reasonably for the boundary conditions > >of negative infinity and positive infinity. In fact, however, > >implementations of the C library vary. > [snip] > > That seems to be a receipt for endless errors without resolution. > Does anyone know what the IEEE standard says about this situation? Is exp(-Inf) required to return 0, or is it allowed to return NaN? I've heard one report that libc6 on linux has it return 0; my libc5 system returns NaN. So recent enough Linux distributions would already have this fixed, assuming Squeak actually uses the normal exp() function. Lex

1 0

← Newer
1
2
3
4
5
6
7
8
...
36
Older →

Jump to page: