[fonc] Stephen Wolfram on the Wolfram Language
Interesting talk by Stephen Wolfram at the Strange Loop conference: https://www.youtube.com/watch?v=EjCWdsrVcBM He goes in the direction of creating a “big” language, rather than a small kernel that can be built upon, like Smalltalk, Maru, etc. — tim ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Circularity [was: Show Us The Code!]
On Dec 24, 2010, at 8:25 AM, Igor Stasenko wrote: > > Interesting. The code it emitting using only three registers: eax, ecx and > esp. > And without any heavy optimization and any kind of register allocation > whatsoever, it is 40% of speed > of optimized C code. > > This number is interesting. A lot of energy and thousands of human > hours put to make a high optimization compilers, just to run 2.5 > faster than "naively" generated code? > I can't believe! :) Let me preface this by saying thanks to Ian and the rest of VPRI for coming up with these interesting things to explore! As to the relative performance of Maru compared to a highly-optimized C compiler, it's good to be skeptical of performance claims ;-) In this case, analyzing boot-eval with the Apple "Shark" profiling tool on my iMac (intel i5) shows that when compiling boot.l, emit.l, eval.l, we are spending about 80% of the time in an inlined version of "assq", which is looking up a symbol association value in eval(). The reason we are spending so much time here is that the env list is very long, and some heavily-used symbols are at the end of it. I instrumented assq to print the symbol being searched for and the depth it was found; here's an example: assq match i depth=2 aveDepth= 61.77 assq match i depth=2 aveDepth= 61.77 assq match i depth=2 aveDepth= 61.77 assq match _limit_ depth=1 aveDepth= 61.77 assq match emit depth=410 aveDepth= 61.78 assq match comp depth=9 aveDepth= 61.78 assq match i depth=2 aveDepth= 61.78 assq match self depth=2 aveDepth= 61.77 assq match arguments depth=1 aveDepth= 61.77 assq match arg depth=1 aveDepth= 61.77 assq match method depth=2 aveDepth= 61.77 assq match method depth=2 aveDepth= 61.77 assq match arg depth=1 aveDepth= 61.77 assq match arg depth=1 aveDepth= 61.77 assq match arg depth=1 aveDepth= 61.77 assq match arg depth=1 aveDepth= 61.77 assq match method depth=2 aveDepth= 61.77 assq match method depth=2 aveDepth= 61.77 assq match arg depth=1 aveDepth= 61.77 assq match arg depth=1 aveDepth= 61.77 assq match arg depth=1 aveDepth= 61.77 assq match arg depth=1 aveDepth= 61.77 assq match method depth=2 aveDepth= 61.77 assq match method depth=2 aveDepth= 61.77 assq match method depth=2 aveDepth= 61.77 assq match arguments depth=3 aveDepth= 61.77 assq match println depth=423 aveDepth= 61.77 assq match $1 depth=1 aveDepth= 61.77 assq match print depth=424 aveDepth= 61.77 assq match args depth=1 aveDepth= 61.77 assq match args depth=1 aveDepth= 61.77 assq match do-print depth=426 aveDepth= 61.77 The pointer-chasing code for this loop in the boot-eval version is just a few instructions long, and is spending all of its time stalled on a pair of "jnz" instructions which are waiting for the load data to return. Analyzing eval with Shark shows that it also is spending most of its time in assq, also stalled on instructions which are waiting for the pointer-chasing load data. There are about 4x as many instructions here as in the boot-eval version. So the reason I think the performance is within 30%-40% of highly-optimized C on this code is that we are limited by spending all our time in a small amount of pointer-chasing code (hard to optimize for in hardware), along with associated data cache misses caused by the pointer chasing. -- Tim Olson ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Pepsi missing Integer methods
On Mar 20, 2007, at 5:46 PM, Ted Kaehler wrote: > An interesting exercise would be to write code to examine all > methods and see if they call any methods that are not defined > anywhere. I thought this was an interesting way to delve into the Pepsi compiler internals, a bit, so I wrote it this evening. Here are the unimplemented selectors found in scanning all of the idc and st80 .st files: unimplemented selector: resetToBeginning senders: OrderedCollection>>makeRoomAtLast OrderedCollection.st:139 unimplemented selector: isDictionary senders: Dictionary>>= Dictionary.st:220 unimplemented selector: errorDivisionByZero senders: SmallInteger>>/ SmallInteger.st:91 unimplemented selector: errorZeroDivide senders: SmallInteger>>quo: SmallInteger.st:152 Integer>>digitDiv:neg: LargeInteger.st:187 unimplemented selector: findKeyOrNil: senders: Object>>respondsTo: perform.st:42 unimplemented selector: anyBitOfMagnitudeFrom:to: senders: Integer>>bitShift: LargeInteger.st:362 unimplemented selector: _beTagType senders: imperative>>block Object.st:58 imperative>>block SmallInteger.st:25 unimplemented selector: rem: senders: Integer>>gcd: LargeInteger.st:484 unimplemented selector: _alloc: senders: Object>>_clone Object.st:60 Object>>_clone: Object.st:61 unimplemented selector: highBit senders: Integer>>gcd: LargeInteger.st:461 Integer>>gcd: LargeInteger.st:466 unimplemented selector: _beNilType senders: imperative>>block Object.st:57 unimplemented selector: familyHash senders: Collection>>hash Collection.st:47 Collection>>hash Collection.st:48 unimplemented selector: array senders: Dictionary>>rehash Dictionary.st:194 unimplemented selector: _vtable senders: Object>>_clone Object.st:60 Object>>_clone: Object.st:61 Object>>isKindOf: Object.st:329 Object>>isMemberOf: Object.st:330 Object>>respondsTo: perform.st:42 Collection>>hash Collection.st:47 Object>>family Object.st:326 Some of these are actually implemented in libid (_vtable, _beNilType, _beTagType, _alloc, findKeyOrNil:). The rest are unimplemented, and probably need some cleaning up. -- Tim Olson ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] adapting jolt send to use _libid_bind2
On Aug 28, 2007, at 9:10 AM, SainTiss wrote:
> The most obvious difference between the two _libid_bind versions is
> the return
> type. One returns a struct t__closure*, while the other one returns a
> struct
> __lookup, of which the first member is actually a struct t__closure*
> though.
> What I'm guessing, is that (long@), being a pointer dereferencing
> operation,
> doesn't work on non-pointer types, even though a struct with a pointer
> as its
> first member could be interpreted to be a pointer type, but apparently
> that's
> not good enough.
>
> Am I guessing right?
Yes, the long@ will not work, here. There is a difference in calling
convention when calling a function returning a struct. The typical way
it is done is for the caller to allocate space for the returned struct,
and pass a pointer to that as a "hidden" parameter to the function.
The function then stores the individual components of the struct using
the hidden pointer. So _libid_bind2 is actually expecting another
parameter (the return struct pointer address). Where this hidden
parameter is passed is defined by the calling convention, but typically
it is the first parameter register, with the visible parameters going
in subsequent parameter registers -- so in this case libid_bind2 will
fail pretty spectacularly.
> Also, is this actually a manifestation of a deeper issue, namely that
> jolt can
> only handle pointer variables (or at best primitive types) when it's
> dealing
> with C functions?
Right now, this is the case. There is the beginnings of some type
information and byte widths in Expression.st, but that doesn't appear
to be used, right now. Also, there are some builtin assumptions that
the size of any local variable is 4 bytes (look for "* 4" in
CodeGenerator-{ppc,i386}.st).
-- Tim Olson
___
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
