Linux?

Think there will ever be a Linux Dolphin, in particular, a 64-bit Linux
Dolphin?

douglas polson wrote:
> Think there will ever be a Linux Dolphin, in particular, a 64-bit Linux
> Dolphin?

 From what I've seen, with Dolphin being heavily tied to the Win32 API
that'll be an unlikely thing.

An idea I did have earlier thou was implmenting the Dolphin VM as a CLR
wrapper, or using the CLR directly.  Which would open up the
possibilities of using Dolphin.NET under Mono ( once the Windows.Forms
stuff is complete - if the ViewComposer was wrapped up with Windows.Forms ).

> Think there will ever be a Linux Dolphin, in particular, a 64-bit Linux
> Dolphin?

IMHO, there should not be a "Linux version of Dolphin" - Dolphin is
heavily tied to the Windows API, and a direct port would probably not be
very satisfying.  However, I will gladly eat those words.

Some have reported success with running Dolphin under Wine.  Of course,
one of the big problems facing Wine's developers is emulating all of the
myriad bugs in the various versions of Windows.  As much as I like the
option to bug out from Microsoft, it strikes me as starting from a very
weak position.

My standing request/advice is to create an Object Arts Smalltalk for
Linux.  Given Dolphin, both its image and VM, OA should be able to make
a translater to give them a huge start on a new system.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

I guess the question really is, 64 bits?  I asked in reference to Linux
as I really like Dolphin Smalltalk and think it would be good to see it
spread...

But hey, 64 bit XP isn't that far off and, though it may very well be
possible to run the current VM as a 32 bit application, there are
definite performance advantages to be had from running natively in 64
bit mode...

douglas polson wrote:
> I guess the question really is, 64 bits?  I asked in reference to Linux
> as I really like Dolphin Smalltalk and think it would be good to see it
> spread...
>
> But hey, 64 bit XP isn't that far off and, though it may very well be
> possible to run the current VM as a 32 bit application, there are
> definite performance advantages to be had from running natively in 64
> bit mode...

... for *some* applications, but not for most.  Many people don't
realize that memory-bound 64-bit applications can run twice as slowly as
32-bit ones.  Imagine you have a purely symbolic computation that
doesn't fit in the processor's cache.  The 32-bit version of this
application will move half the number of bytes of data than the 64-bit
version and if (as is typical on current processors) the interface to
main memory is the bottle neck then the 64-bit application will run at
half the speed.

64-bits can be a win if
- your application won't fit in a 32-bit address space but will fit in
e.g. something around 40 bits (*)
- your application does lots of arithmetic on 64-bit data types
- the implementation is able to exploit 64-bits for nefarious purposes.

but if it fits in 32-bits and doesn't benefit from 64-bit data types
then you're probably better off staying with 32-bits.

Of course the last bullet point is a biggie.  In 64-bit VW 64-bits make
it much easier to share memory between multiple activations of an image
and so certain server configurations will benefit significantly.  But
the notion that 64-bits implies greater performance is naive at best.

(*) current 64-bit machines don't provide a full 64-bit address space.
Typical iron (AMD Opteron) allows 1 terabyte of ram (40 bits).
--
_______________,,,^..^,,,____________________________
Eliot Miranda              Smalltalk - Scene not herd

It is possible that 64 bit native mode could offer performance
improvements in the general case.  In that Dolphin Smalltalk uses a
"byte code" interpreting virtual machine and that the native instruction
set is still x86 based, caching of byte codes in data cache, or caching
of instructions in the data shouldn't change all that much. However, the
VM could possibly use the wider data paths and, or, registers to improve
byte code prefetch, even possibly "look ahead", or byte code folding.
Of course, this may not work in all cases, but it is a possibility.
Another advantage might come from, object references including any tag
or descriptor bits, could be fetched, manipulated, etc. using less
accesses to memory, twice the number of bits can be held in a register
than when using a strictly 32 bit architecture.  Would any of these
tricks be considered nefarious?

Another possible performance enhancement might come through using the
larger address space to implement multiple object spaces, differences
based on object type, or object usage patterns, which could potentially
facilitate using more efficient (read: incremental) garbage collection
algorithms (a "soft" real-time Dolphin?).

Anyway, I was just curious, as the AMD x86-64 architecture is proving
itself to be rockin' in both 32 bit and 64 bit modes.

dp

douglas polson wrote:

Not at all.  The problem is that whatever tricks one uses to take
advantage of 64-bit machines have to overcome the basic problem that one
is moving twice as much data whenever one accesses a slot, and the basic
computational activity in Smalltalk (excepting accessing strings, et al)
is accessing slots.

The interpreter (and language implementation in general) is all
overhead; that it can potentially be made faster is potential that
overhead can be reduced.  But the actual computation will still cost you
more.  In an efficient language implementation overhead does not
dominate computation, so as the implementation gets more efficient so
the penalty of moving to 64-bits grows.


> Another possible performance enhancement might come through using the
> larger address space to implement multiple object spaces, differences
> based on object type, or object usage patterns, which could potentially
> facilitate using more efficient (read: incremental) garbage collection
> algorithms (a "soft" real-time Dolphin?).

Right, but these kinds of advantages only apply to applications that can
exploit them.  In general 64-bits incurs a higher cost.  Its
self-fulfilling since current 32-bit applications are precisely that,
applications that fit in 32-bits.  There are rare applications (things
like large databases) that don't fit and have to implement elaborate
paging and segmentation schemes to evade the 32-bit limit, and these
applications can and do benefit enormously from 64-bit machines.  But
they are by definition atypical.  Most 32-bit apps are well-tuned to
running effectively in 32-bits.


>
> Anyway, I was just curious, as the AMD x86-64 architecture is proving
> itself to be rockin' in both 32 bit and 64 bit modes.

Indeed it is.  My experience of 32-bits vs 64-bits with the VisualWorks
VM is that theoretically the 64-bit system should run about 33% slower
(because if dynamic access patterns reflect static data distributions
then 1/3 of  accesses in normal computation are of byte data, which is
unaffected by word size).  But by exploiting 64-bits (e.g. by moving the
instance size of a pointer object into the object header, and encoding a
class reference indirectly through an index resulting in only a 33%
growth in object header size, 12 bytes => 16 bytes, instead of 12 bytes
=> 24 bytes) the actual slowdown is ~10% for our standard benchmarks.

But my experience of the Opteron and Athlon 64 vs Intel x86 is extremely
positive.  The AMD iron has higher mips per buck (and goes to 64-bits :) ).

--
_______________,,,^..^,,,____________________________
Eliot Miranda              Smalltalk - Scene not herd