Linked by Hadrien Grasland on Sat 5th Feb 2011 10:59 UTC
OSNews, Generic OSes So you have taken the test and you think you are ready to get started with OS development? At this point, many OS-deving hobbyists are tempted to go looking for a simple step-by-step tutorial which would guide them into making a binary boot, do some text I/O, and other "simple" stuff. The implicit plan is more or less as follow: any time they'll think about something which in their opinion would be cool to implement, they'll implement it. Gradually, feature after feature, their OS would supposedly build up, slowly getting superior to anything out there. This is, in my opinion, not the best way to get somewhere (if getting somewhere is your goal). In this article, I'll try to explain why, and what you should be doing at this stage instead in my opinion.
Thread beginning with comment 461408
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[6]: Not always rational
by Morin on Tue 8th Feb 2011 17:12 UTC in reply to "RE[5]: Not always rational"
Morin
Member since:
2005-12-31

That's a fair criticism - the shared ram and cache coherency model used by x86 systems is fundamentally unscalable.


I was referring to the shared RAM and coherency model used by Java specifically. That one is a lot better than what x86 does, but it still makes the RAM a bottleneck. For example, a (non-nested) "monitorexit" instruction (end of a non-nested "synchronized" code block) forces all pending writes to be committed to RAM before continuing.

However, considering that shared memory is the only form of IPC possible on multicore x86 processors, we can't really view it as a weakness of the OS.


If you limit yourself to single-chip, multi-core x86 systems, then yes. That's a pretty harsh restriction though: There *are* multi-chip x86 systems (e.g. high-end workstations), there *are* ARM systems (much of the embedded stuff, as well as netbooks), and there *are* systems with more than one RAM (e.g. clusters, but I'd expect single boxes that technically contain clusters to be "not far from now").

Reply Parent Score: 2

RE[7]: Not always rational
by Alfman on Wed 9th Feb 2011 01:12 in reply to "RE[6]: Not always rational"
Alfman Member since:
2011-01-28

Morin,

"There *are* multi-chip x86 systems (e.g. high-end workstations), there *are* ARM systems (much of the embedded stuff, as well as netbooks), and there *are* systems with more than one RAM..."

Sorry, but I'm not really sure what you're post is saying?

Reply Parent Score: 1

RE[8]: Not always rational
by Morin on Wed 9th Feb 2011 07:29 in reply to "RE[7]: Not always rational"
Morin Member since:
2005-12-31

Morin, "There *are* multi-chip x86 systems (e.g. high-end workstations), there *are* ARM systems (much of the embedded stuff, as well as netbooks), and there *are* systems with more than one RAM..." Sorry, but I'm not really sure what you're post is saying?


Then I might have misunderstood your original post:

However, considering that shared memory is the only form of IPC possible on multicore x86 processors, we can't really view it as a weakness of the OS.


I'll try to explain my line of thoughts.

My original point was that shared RAM approaches make the RAM a bottleneck. You responded that shared RAM "is the only form of IPC possible on multicore x86 processors".

My point now is that this is true only for the traditional configuration with a single multi-core CPU and a single RAM, with no additional shared storage and no hardware message-passing mechanism. Very true, but your whole conclusion is limited to such traditional systems, and my response was aiming at the fact that there are many systems that do *not* use the traditional configuration. Hence shared memory is *not* the only possible form of IPC on such systems, and making the RAM a bottleneck through such IPC artificially limits system performance.

As an example to emphasize my point, consider CPU/GPU combinations with separated RAMs (gaming systems) vs. those with shared RAM (cheap notebooks). On the latter, RAM performance is limited and quickly becomes a bottleneck (no, I don't have hard numbers).

I wouldn't be surprised to see high-end systems in the near future, powered by two general-purpose (multicore) CPUs and a GPU, each with its own RAM (that is, a total of 3 RAMs) and without transparent cache coherency between the CPUs, only between cores of the same CPU. Two separate RAMs means a certain amount of wasted RAM, but the performance might be worth it.

Now combine that with the idea of uploading bytecode scripts to server processes, possibly "on the other CPU", vs. shared memory IPC.

Reply Parent Score: 2