OpenGenera on Linux is the same as Alpha, except with the VLM hacked to run on x86-64 linux instead of Alpha OSF. My smallest Alpha is a DS20e (that still weighs 100+ lbs.), half the PCI cards in it aren't supported in DU4, and I was never able to get OG2 to run on Tru64 v5. Frankly, OG2 in a Linux VM makes anything else really difficult to recommend.

I've read that ( in at least xemacs ), lisp code is compiled to byte-code, and because emacs-lisp is a smaller language than common lisp, they can get away with hacks such as getting rid of the first few ascii bits, and using smaller space per opcode. ( which the documentation claims makes this a much faster way to execute code ( according to jwz ).

It's kind-of how risc can be faster than intel opcodes because the archetecture is designed to do one thing quickly.

geo: your benchmark is a bit limited because it only tests the speed of incrementing, testing, and branching. in real programs memory architecture and function calling are probably more important. back in the medieval period, Dick Gabriel did some work on benchmarking systems and wrote a book about it.http://www.dreamsongs.com/Files/Timrep.pdf

these days it would be better to have more up-to-date benchmarks, like I suppose, RSA crypto or *ML parsing.

thanks ham!! will check this out later on our break what's up there? CNY is fast approaching so kinda busy here.. will head home soon yahoo!! no more cold places this CNY

robespierre wrote:geo: your benchmark is a bit limited because it only tests the speed of incrementing

hahaha i know robes but i just use this as a quick comparison for different platforms i just got this test from one article i read.. and yes i did read the Timrep.pdf, one of my fave reference on different Lisp implementations..

yeah.. i even thought maybe Lisp could be used on bitcoin mining? not sure if i understood it right.. oh! i already got Kogge's book from Amazon, i cant stop reading hehe but now im kinda busy with BLE stuff.. get back with SGI and LISPM soon, cheers!!

No new benchmark results (though I thought about installing Macintosh Common Lisp on the IIfx and comparing that to the MacIvory II. maybe in the spring.) but I have been jerking around with bringing up color on the NuVista+. There is some stub support for it in Genera 8.3, but it's not complete enough to actually work. So I hacked a patch together, borrowing the sync programs from the NuVista source. I think the timings are maybe not quite correct for the NuVista+ because I've got no color in any of the video modes, and the "hires" (31kHz) mode needs some pretty serious sync processing before any display will play ball. It'd be nice to find a copy of the Mac driver disks so I could extract the timing values from the "official" NuVista+ sync programs, and see if it makes any difference in the displays output from Genera.

But it does work. I haven't looked into any of the S-Graphics packages yet, though the color demos are (however) mildly amusing.