On 24/02/2007, at 1:13 PM, syan tan wrote:
the fact that Kuang threw a spotlight on erlang was enlightening,
and I don't know enough about the circumstances of smalltalk and other
OO languages to completely discount that there isn't a multiprocessor
relevance.
The smalltalk that I use does not support SMP/concurrency involving
multicore architectures.
There is a definite move to make Smalltalk more Erlang like to take
advantage of the multicore processors.
A model proposed is the Actalk framework and a transparent
distribution framework
such as Opentalk-STST. With such a model one has to make sure that
things get passed by value, yes - even in local calls, instead of by
reference.
HTH
Kuang
Isn't it true that many unix reentrant-safe functions
depend on passing a pointer to a client memory structure from the
calling code context, and who knows what kind of black magic goes
behind in the OS in kernel mode in servicing some of those functions .
(even when trying to read the intel systems programming book 3, manual
chapter 7, whilst trying to work out if it is possible to understand
the linux source regarding spin locks ).
On Sat, 2007-02-24 at 11:04 +1100, Andrew Patterson wrote:
rather than by the value itself. This is said to be more efficient
programming and memory wise - are you saying that due to the extra
lookup step from pointer to variable that it slows the processor?
It is more efficient - its also the only practical way of doing
things on any data artifacts that are too big to fit in a register
(i.e. anything that is not an integer or a double). Some languages
might optimize string manipulation for extremely small strings
that can fit in a register, but as its not at all the normal usage
of strings (i.e. even short error message strings would be too
big for a register), I doubt most languages would bother..
I don't know why OO, Erlang or call by reference really
have anything to do with the limits of multiprocessor
systems. Syan is right that the most in most EMR
systems it is the disk or network latency that will be
killing you, and hence adding extra cpu's won't likely
make the performance for one user much better. Extra
cpu's does allow the simultaneous user load to be
scaled up (i.e. going from 3 doctors
simultaneously with 1 cpu to 5 or 6 concurrent
users with 2 cpu's).
I can't help out with the initial query which was whether
for _licensing_ purposes, a dual core is classified as
multiprocessor.
If I was marking Kuang for a computer architecture exam
he'd be hovering at the 3/10 mark at the moment so take
what he says with a grain of salt..
Andrew
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
_______________________________________________
Gpcg_talk mailing list
[email protected]
http://ozdocit.org/cgi-bin/mailman/listinfo/gpcg_talk
