<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,<br>
<br>
Sebastian Sastre wrote:
<blockquote
cite="mid:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAx5oTyKKcHEiH5jLobrYqEMKAAAAQAAAAhozPTNvTZUy+TpA5+5MBtAEAAAAA@seaswork.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta content="MSHTML 6.00.2900.3199" name="GENERATOR">
</blockquote>
<div dir="ltr" align="left"> </div>
<blockquote
cite="mid:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAx5oTyKKcHEiH5jLobrYqEMKAAAAQAAAAhozPTNvTZUy+TpA5+5MBtAEAAAAA@seaswork.com"
type="cite">
<div>hi,<br>
<br>
What? That just won't work. Think of the memory overhead. <br>
<span class="859282918-25102007"><font color="#0000ff"
face="Trebuchet MS" size="2"> </font></span></div>
<div><span class="859282918-25102007"><font color="#0000ff"
face="Trebuchet MS" size="2">I don't give credit to unfounded
apriorisms. I think it deserves to be proved that does not work. Anyway
let's just assume that may be too much for state of the art hardware in
common computers in year 2007. What about in 2009? what about in 2012?
Remember the attitude you had saying this now the first day of 2012.</font></span></div>
</blockquote>
<br>
It's not an unfounded apriorism as you put it. <br>
<br>
Current hardware and technology expected in the next ten years isn't
optimized for N hundred thousand or N million threads of execution.
Maybe in the future that will be the case. <br>
<br>
The Tile-64 processor is expected to grow to about 4096 processors by
pushing the limits of technology beyond what they are today. To reach
the levels you are talking about for a current Smalltalk image with
millions of objects each having their own thread (or process) isn't
going to happen anytime soon. <br>
<br>
I work with real hardware.<br>
<br>
I am open and willing to be pleasantly surprised however. <br>
<br>
<br>
<blockquote
cite="mid:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAx5oTyKKcHEiH5jLobrYqEMKAAAAQAAAAhozPTNvTZUy+TpA5+5MBtAEAAAAA@seaswork.com"
type="cite">
<div>Tying an object instance to a particular process makes no sense.
If you did that you'd likely end up with just as many dead locks and
other concurrency problems since you'd now have message sends to the
object being queued up on the processes input queue. Since processes
could only process on message at a time deadlocks can occur - plus all
kinds of nasty problems resulting from the order of messages in the
queue. (There is a similar nasty problem with the GUI event processing
in VisualAge Smalltalk that leads to very difficult to diagnose and
comprehend concurrency problems). It's a rats maze that's best to avoid.<br>
<span class="859282918-25102007"> </span><br>
Besides, in some cases an object with multiple threads could respond to
many messages - literally - at the same time given multiple cores. Why
slow down the system by putting all the messages into a single queue
when you don't have to!?<br>
<span class="859282918-25102007"></span></div>
<div><span class="859282918-25102007"><font color="#0000ff"
face="Trebuchet MS" size="2">You didn't understand the model I'm
talking about. </font></span></div>
</blockquote>
<br>
That is likely the case. <br>
<br>
<br>
<blockquote
cite="mid:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAx5oTyKKcHEiH5jLobrYqEMKAAAAQAAAAhozPTNvTZUy+TpA5+5MBtAEAAAAA@seaswork.com"
type="cite">
<div><span class="859282918-25102007"><font color="#0000ff"
face="Trebuchet MS" size="2">There isn't such a thing as an object
with multiple trheads. That does not exists in this model. </font></span></div>
</blockquote>
<br>
Ok. I got that. <br>
<br>
<br>
<blockquote
cite="mid:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAx5oTyKKcHEiH5jLobrYqEMKAAAAQAAAAhozPTNvTZUy+TpA5+5MBtAEAAAAA@seaswork.com"
type="cite">
<div><span class="859282918-25102007"><font color="#0000ff"
face="Trebuchet MS" size="2">It does exists one process per instance
no more no less. </font></span></div>
</blockquote>
<br>
I did get that. Even if you only do that logically you've got serious
problems.<br>
<br>
<br>
<blockquote
cite="mid:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAx5oTyKKcHEiH5jLobrYqEMKAAAAQAAAAhozPTNvTZUy+TpA5+5MBtAEAAAAA@seaswork.com"
type="cite">
<div><span class="859282918-25102007"><font color="#0000ff"
face="Trebuchet MS" size="2">I think you're thinking about processes
and threads the same way you know them today. </font></span></div>
</blockquote>
<br>
I can easily see such a scenario working and also breaking all over the
place.<br>
<br>
<br>
<blockquote
cite="mid:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAx5oTyKKcHEiH5jLobrYqEMKAAAAQAAAAhozPTNvTZUy+TpA5+5MBtAEAAAAA@seaswork.com"
type="cite">
<div><span class="859282918-25102007"><font color="#0000ff"
face="Trebuchet MS" size="2">Lets see if this helps you to get the
idea: Desambiguation: for this model I'm talking about process not as
an OS process but as a VM light process which we also use to call them
threads.</font></span></div>
</blockquote>
<br>
Ok.<br>
<br>
<br>
<blockquote
cite="mid:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAx5oTyKKcHEiH5jLobrYqEMKAAAAQAAAAhozPTNvTZUy+TpA5+5MBtAEAAAAA@seaswork.com"
type="cite">
<div><span class="859282918-25102007"><font color="#0000ff"
face="Trebuchet MS" size="2">So I'm saying that in this model you have
only one process per instance but that process is not a process that
can have threads belonging to it. </font></span></div>
</blockquote>
<br>
ok.<br>
<br>
<blockquote
cite="mid:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAx5oTyKKcHEiH5jLobrYqEMKAAAAQAAAAhozPTNvTZUy+TpA5+5MBtAEAAAAA@seaswork.com"
type="cite">
<div><span class="859282918-25102007"><font color="#0000ff"
face="Trebuchet MS" size="2">That generates a hell of complexity. <br>
</font></span></div>
</blockquote>
<br>
You lost me there. What complexity?<br>
<br>
<br>
<blockquote
cite="mid:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAx5oTyKKcHEiH5jLobrYqEMKAAAAQAAAAhozPTNvTZUy+TpA5+5MBtAEAAAAA@seaswork.com"
type="cite">
<div><span class="859282918-25102007"><font color="#0000ff"
face="Trebuchet MS" size="2">The process I'm saying it's tied to an
instance it's more close to the process word you know from dictionary
plus what you know what an instance is and with the process implemented
by a VM that can balance it across cores.</font></span></div>
</blockquote>
<br>
I didn't understand. Please restate. <br>
<br>
<br>
<blockquote
cite="mid:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAx5oTyKKcHEiH5jLobrYqEMKAAAAQAAAAhozPTNvTZUy+TpA5+5MBtAEAAAAA@seaswork.com"
type="cite">
<div><span class="859282918-25102007"></span> </div>
<div><span class="859282918-25102007"><font color="#0000ff"
face="Trebuchet MS" size="2">I'm not falling in the pitfall of start
trying to parallelize code automagically. This far from it. In fact I
think this is better than that illusion. Every message is guaranteed by
VM to reach it's destination in guaranteed order. Otherwise will be
chaos. And we want an ordered chaos like the one we have now in a
Squeak reified image.</font></span></div>
</blockquote>
<br>
Yes, squeak is ordered chaos. ;--). <br>
<br>
<br>
<br>
<blockquote
cite="mid:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAx5oTyKKcHEiH5jLobrYqEMKAAAAQAAAAhozPTNvTZUy+TpA5+5MBtAEAAAAA@seaswork.com"
type="cite">
<div><span class="859282918-25102007"></span> </div>
<div><span class="859282918-25102007"><font color="#0000ff"
face="Trebuchet MS" size="2">Clarified that I ask why do you think
could be deadlocks? and what other kind of concurrency problems do you
think that will this model suffer?</font></span></div>
</blockquote>
<br>
<br>
If a number of messages are waiting in the input queue of a process
that can only process one message at a time since it's not
multi-threaded then those messages are BLOCKED while in the thread. Now
imagine another process with messages in it's queue that are also
BLOCKED since they are waiting in the queue and only one message can be
processed at a time. Now imagine that process A and process B each have
messages that the other needs before it can proceed but those messages
are BLOCKED waiting for processing in the queues. <br>
<br>
This is a real example of what can happen with message queues. The
order isn't guaranteed. Simple concurrency solutions often have
deadlock scenarios. This can occur when objects must synchronize events
or information. As soon as you have multiple threads of execution
you've got problems that need solving regardless of the concurrency
model in place. <br>
<br>
<br>
<blockquote
cite="mid:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAx5oTyKKcHEiH5jLobrYqEMKAAAAQAAAAhozPTNvTZUy+TpA5+5MBtAEAAAAA@seaswork.com"
type="cite">
<div><span class="859282918-25102007"> </span><br>
Tying an object's life time to the lifetime of a process doesn't make
sense since there could be references to the object all over the
place. If the process quits the object should still be alive IF there
are still references to it.<br>
</div>
<span class="859282918-25102007"></span>
<div>You'd need to pass around more than references to processes. For
if a process has more than one object you'd not get the resolution
you'd need. No, passing object references around is way better.<br>
<span class="859282918-25102007"><font color="#0000ff"
face="Trebuchet MS" size="2"> </font></span></div>
<div><span class="859282918-25102007"><span class="859282918-25102007"><font
color="#0000ff" face="Trebuchet MS" size="2">Yes</font> <font
color="#0000ff" face="Trebuchet MS" size="2">of course there will be.
In this system a process termination is one of two things: A) that
instance is being reclaimed in a garbage collection or B) that instance
has been written to disk in a kind of hibernation that can be reified
again on demand</font></span><font face="Trebuchet MS"><font
color="#0000ff"><font size="2">.<span class="859282918-25102007"> </span><span
class="859282918-25102007">Please refer to my previous post with
subject "One Process Per Instance.." where I talk more about exacly
this. <br>
</span></font></font></font></span></div>
</blockquote>
<br>
If all there is is a one object per process and one process per object
- a 1 to 1 mapping then yes gc would work that way but the 1 to 1
mapping isn't likely to ever happen given current and future hardware
prospects. <br>
<br>
<br>
<blockquote
cite="mid:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAx5oTyKKcHEiH5jLobrYqEMKAAAAQAAAAhozPTNvTZUy+TpA5+5MBtAEAAAAA@seaswork.com"
type="cite">
<div><span class="859282918-25102007"><font face="Trebuchet MS"><font
color="#0000ff"><font size="2"><span class="859282918-25102007"></span></font></font></font> </span><br>
Even if you considered an object as having it's own "logical" process
you'd get into the queuing problems hinted at above.<br>
<span class="859282918-25102007"><font color="#0000ff"
face="Trebuchet MS" size="2"> </font></span></div>
<div><span class="859282918-25102007"><font color="#0000ff"
face="Trebuchet MS" size="2">Which I dont see and I ask your help to
understand if you still find them after the clarifications made about
the model.</font></span></div>
</blockquote>
<br>
See the example above. <br>
<br>
<br>
<blockquote
cite="mid:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAx5oTyKKcHEiH5jLobrYqEMKAAAAQAAAAhozPTNvTZUy+TpA5+5MBtAEAAAAA@seaswork.com"
type="cite">
<div><span class="859282918-25102007"> </span><br>
Besides objects in Smalltalk are really fine grained. The notion that
each object would have it's own thread would require so much thread
switching that no current processor could handle that. It would also be
a huge waste of resources.<br>
</div>
<span class="859282918-25102007"></span>
<div><span class="859282918-25102007"><font color="#0000ff"
face="Trebuchet MS" size="2">And what do you think was going out of
the mouths of criticizers of the initiatives like the park place team
had in 1970's making a Smalltalk with the price of the CPU's and RAM at
that time? that VM's are a smart efficient use of resources?</font></span></div>
</blockquote>
<br>
That's not really relevant. If you want to build that please go ahead -
please don't let me stop you, that's the last thing I'd want. I wish
you luck. I get to play with current hardware and hardware that's
coming down the pipe such as the Tile-64 or the newest GPUs when they
are available to the wider market.<br>
<br>
<br>
<blockquote
cite="mid:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAx5oTyKKcHEiH5jLobrYqEMKAAAAQAAAAhozPTNvTZUy+TpA5+5MBtAEAAAAA@seaswork.com"
type="cite">
<div><span class="859282918-25102007"></span> </div>
<div><span class="859282918-25102007"><font color="#0000ff"
face="Trebuchet MS" size="2">So I copy paste myself: "<span
class="859282918-25102007"><font color="#0000ff" face="Trebuchet MS"
size="2">I don't give credit to unfounded apriorisms. It deserves to
be proven that does not work. Anyway let's just assume that may be too
much for state of the art hardware in common computers in year 2007.
What about in 2009? what about in 2012?"</font></span></font></span></div>
</blockquote>
<br>
Well just get out your calculator. There is an overhead to a thread or
process in bytes. Say 512 bytes per thread plus it's stack. There is
the number of objects. Say 1 million for a medium to small image. Now
multiply those and you get 1/2 gigabyte. Oh, we forgot the stack space
and the memory for the objects themselves. Add a multiplier for that,
say 8 and you get 4 gigabytes. Oh, wait we forgot that the stack is
kind weird since as each message send that isn't to self must be an
interprocess or interthread message send you've got some weirdness
going on let along all the thread context switching for each message
send that occurs. Then you've got to add more for who knows what... the
list could go on for quite a bit. It's just mind boggling. <br>
<br>
Simply put current cpu architectures are simply not designed for that
approach. Heck they are even highly incompatible with dynamic message
passing since they favor static code in terms of optimizations. <br>
<br>
<blockquote
cite="mid:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAx5oTyKKcHEiH5jLobrYqEMKAAAAQAAAAhozPTNvTZUy+TpA5+5MBtAEAAAAA@seaswork.com"
type="cite">
<div><span class="859282918-25102007"> </span><br>
Again, one solution does not fit all problems - if it did programming
would be easier.<br>
<span class="859282918-25102007"><font color="#0000ff"
face="Trebuchet MS" size="2"> </font></span></div>
<div><span class="859282918-25102007"><font color="#0000ff"
face="Trebuchet MS" size="2">But programming should have to be easier.
</font></span></div>
</blockquote>
Yes, I concur, whenever it's possible to do so. But it also shouldn't
ignore the hard problems either. <br>
<br>
<br>
<blockquote
cite="mid:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAx5oTyKKcHEiH5jLobrYqEMKAAAAQAAAAhozPTNvTZUy+TpA5+5MBtAEAAAAA@seaswork.com"
type="cite">
<div><span class="859282918-25102007"><font color="#0000ff"
face="Trebuchet MS" size="2">Smalltalk made it easier in a lot of
aspects. </font></span></div>
</blockquote>
<br>
Sure I concur. That's why I am working here in this group spending time
(is money) on these emails. <br>
<br>
<blockquote
cite="mid:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAx5oTyKKcHEiH5jLobrYqEMKAAAAQAAAAhozPTNvTZUy+TpA5+5MBtAEAAAAA@seaswork.com"
type="cite">
<div><span class="859282918-25102007"><font color="#0000ff"
face="Trebuchet MS" size="2">Listen.. I'm not a naif silver bullet
purchaser nor a faithful person. I'm a critic Smalltalker that thinks
he gets the point about OOP and tries to find solutions to surpass the
multicore crisis by getting an empowered system not consoling itself
with a weaker one. </font></span><span class="859282918-25102007"><font
color="#0000ff" face="Trebuchet MS" size="2"><br>
</font></span></div>
</blockquote>
<br>
I do get that about you. <br>
<br>
<br>
<blockquote
cite="mid:!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAAx5oTyKKcHEiH5jLobrYqEMKAAAAQAAAAhozPTNvTZUy+TpA5+5MBtAEAAAAA@seaswork.com"
type="cite">
<div><span class="859282918-25102007"><font color="#0000ff"
face="Trebuchet MS" size="2">Peter please try to forget about how
systems are made and think in how you want to make them.</font></span></div>
</blockquote>
<font color="#0000ff"><font size="2"><font face="Trebuchet MS"><br>
</font></font></font>I do think about how I want to make them. However
to make them I have no choice but to consider how to actually build
them using existing technologies and the coming future technologies. <br>
<br>
Currently we have 2-core and 4-core processors as the mainstream with
3-core and 8-core coming to a computer store near you. We have the
current crop of GPUs from NVidia that have 128 processing units that
can be programmed in a variant of C for some general purpose program
tasks using a SIMD (single instruction multiple data) format - very
useful for those number crunching applications like graphics,
cryptology and numeric analysis to name just a few. We also have the
general purpose networked Tile-64 coming - lots of general purpose
compute power with an equal amount of scalable networked IO power -
very impressive. Intel even has a prototype with 80-cores that is
similar. Intel also has it's awesomely impressive Itanium processor
with instruction level parallelism as well as multiple cores - just
wait till that's a 128 core beastie. Please there is hardware that we
likely don't know about or that hasn't been invented yet. Please bring
it on!!!<br>
<br>
The bigger problem is that in order to build real systems I need to
think about how they are constructed. <br>
<br>
So yes, I want easy parallel computing but it's just a harsh reality
that concurrency, synchronization, distributed processing, and other
advanced topics are not always easy or possible to simplify as much as
we try to want them to be. That is the nature of computers. <br>
<br>
Sorry for being a visionary-realist. Sorry if I've sounded like the
critic. I don't mean to be the critic that kills your dreams - if I've
done that I apologize. I've simply meant to be the realist who informs
the visionary that certain adjustments are needed.<br>
<br>
All the best,<br>
<br>
Peter<br>
<br>
<br>
</body>
</html>