Page 2 of 4

Re: about LISP performance

Posted: Mon Oct 28, 2013 7:55 pm
by robespierre
What machine is the microexplorer running in? I tried using one in a Quadra 840 and it didn't work.

Re: about LISP performance

Posted: Mon Oct 28, 2013 8:04 pm
by kjaer
Macintosh II. It's a "real microExplorer", in that it has all the TI stickers on it. microExplorer logo on the front; configuration and serial number sticker on the back.

The whole microExplorer system is designed around MultiFinder. I'm not sure whether it would work at all under System 7. I didn't try.

Re: about LISP performance

Posted: Mon Oct 28, 2013 8:06 pm
by mia
haha cute.

would be nice to run this on a symbolics.

Re: about LISP performance

Posted: Mon Oct 28, 2013 8:08 pm
by kjaer
I guess I could... my Symbolics projects are farther behind though.

Re: about LISP performance

Posted: Mon Oct 28, 2013 8:15 pm
by ClassicHasClass
That's pretty sweet, kjaer. I knew about the MacIvory, but never used one of the MicroExplorers.

Re: about LISP performance

Posted: Mon Oct 28, 2013 8:38 pm
by robespierre
Another dubious "project" is to upgrade this MicroExplorer from 8MB to 12MB (2 MW to 3 MW). But there is a specific TI gate array that I don't think I'll be able to find.

Re: about LISP performance

Posted: Wed Oct 30, 2013 8:47 pm
by kjaer
Pulled out the MacIvory machine. MacIvory 2 gives slightly better but roughly equal performance to the microExplorer, despite having to access its memory over the Nubus. 34 seconds for 50000 iterations.

Re: about LISP performance

Posted: Wed Oct 30, 2013 8:52 pm
by kjaer
Swapped in the MacIvory 1 board. Not surprisingly, it has slightly better than half of the performance of the MacIvory 2, since the MacIvory 1 is in every way identical to the 2 except for having slightly better than twice the cycle time. 62 seconds for 50000 iterations.

Re: about LISP performance

Posted: Thu Oct 31, 2013 8:56 pm
by geo
hi kjaer! thanks for sharing these results :)

looking forward to see the compiled result ;)

hmm wow, this is already considered almost the high end Lispm from Symbolics right? i wonder if the standalone Symbolics can do better? or the TI Explorer or LMI Lambda?

i even tried this test on some of our Linux servers and using CMUCL, CCL, CLISP and SBCL let me pull out the results later..

Re: about LISP performance

Posted: Thu Oct 31, 2013 11:38 pm
by robespierre
The Microexplorer uses the same chip as the TI Explorer II, the first VLSI lisp processor released commercially. The Symbolics Ivory came out a year or so later. The MacIvory I and II access main memory over the NuBus, which was a performance bottleneck the standalone machines did not have. The TI Explorers were also based on NuBus, but had a faster local bus for main memory access.

Running this "dhumbstone" in interpreted code is amusing, and it reminds me of a story I read here.

Re: about LISP performance

Posted: Fri Nov 01, 2013 3:35 am
by hamei
robespierre wrote:... a story I read here.

"n general terms, the job description was to take a customer question; translate it into inoffensive language and present it to the developers. We then took the answer and tranlated that into inoffensive language and presented it to the customer. "

That was funny :D

Re: about LISP performance

Posted: Fri Nov 01, 2013 9:21 am
by geo
robespierre wrote: a story I read here.


you mean this:
...and another jrd story:
I did the macivory serial stuff, so when a guy at Lincoln Labs started having problems using a macivory to do data acquisition over a serial line to some random piece of hardware, I got dragged into the loop in short order. I talked to the guy, and debugged over the phone a little, and came to the conclusion that (a) he didn't have much of a clue, and (b) there was a stupid bug in some low-level queue-handling code. I knocked together a patch and sent it off. The next day he calls back, and he's not losing data any more, but "every once in a while" the whole machine hangs up, wedged solidly in Run state, not responsive to keyboard or anything else. It would do that for some number of seconds, and then start running again. I did a lot of head-scratching over that, but couldn't come up with an explanation. Finally I went and found Greenwald, who'd written the (then) new scheduler, to ask him if I was doing something wrong. He looked at the code, and said it looked ok. Eventually the management said if we couldn't fix it over the phone, we should just go out there, so we drove over. Met the guy (more military security checks) and got into the lab. Sure enough, the machine wedges up whenever it turns around. Mike digs around in the scheduler datastructures for a while, but can't find any explanation. After some FEP debugging, Mike says "I dunno, but it looks to me like it's just spending a lot of time in the interpreter". We look at each other. I ask the costomer "You loaded the patch I sent you, right?" "Yes." "Did you compile it first?" He looks blankly at me. Mike and I look at each other again. I tell the guy "You have to compile it before you load it." "Really?? I never do that with my code." After discarding several other responses, I said "Just compile it and reload it and let's try it again". He goes off to compile it and save it into a world, we go get coffee and boggle and the level of lossage. Now he's got his new world set up, so we go try again. No joy, it still wedges up. Thinking maybe we hadn't really fixed it, Mike digs around some more. After a while, "It still looks to me like it's spending a lot of time in the interpreter." I ask the customer "You compiled that, right?" "Yes" "and loaded it into this world, right?" "Yes". Grumble. Well maybe it didn't get saved where we thought it did. He saves a new world. Try again. Still wedges. By now we're both stumped. Let's try it one last time. "You're sure you compiled it" "Sure I'm sure!" "And loaded the binary file into this world, right?" Blank look. "Binary file?" The thing that really amazed me about the whole incident was what it said about genera robustness. We were running a fair-sized slab of code interpreted, at interrupt level, and it didn't croak anything.
--- jrd
indeed funny hehe

hamei wrote:"n general terms, the job description was to take a customer question; translate it into inoffensive language and present it to the developers. We then took the answer and tranlated that into inoffensive language and presented it to the customer. "

That was funny
hahaha this sounds like our project managers job here :)

Re: about LISP performance

Posted: Sun Nov 03, 2013 1:29 am
by kjaer
I have compiled results to share, and there's no word for them but "hilarious". I ended up having to use n=50000000 (as in the original examples) for the compiled results, because n=50000 was too fast for the resolution of the timer.

MacIvory 2: 28
MacIvory 1: 54
MicroExplorer: 339

Re: about LISP performance

Posted: Sun Nov 03, 2013 5:18 pm
by kjaer
Those results made me curious. So I tried the same on OpenGenera 2 in a Linux VM, on my Mac Pro.

Interpreted: 1171
Compiled: 2

Nice.

Re: about LISP performance

Posted: Sun Nov 03, 2013 6:40 pm
by geo
morning kjaer!

thanks for all this results! wow! the TI uExplorer is really behind hehe
but wow! the OpenGenera 2 on your Linux VM under Mac Pro :shock: :shock:

hmmm how about the Genera under Alpha? i think that was the latest setup from Symbolics right? do you have such setup? :) i still cannot make mine work on Ubuntu 64bit via virtualbox.. i already tried almost all the available instructions on the net but still wont work.. i think its about my network setup..