OSDev.org

All pointers are twice as big in 64-bit apps, meaning that they consume more memory than their 32-bit counterparts. This can reduce overall system performance if it forces some apps to start thrashing (in which case, just add more RAM).

@Brendan, You talk about, having two kernels 32bit and 64bit, but as you pointed out, theres a fine line (in my case), between kernel and program.
If a kernel is say 64k and self contained, that can be load as any other program, then yes as in my case its possable to run 64bit program from a 32bit OS.
You spend alot of time talking about the down sides of my type of OS, but there are many up sides too.
The day will come when there is no multitasking, but each program will run on its own core with a stripped down OS, with just the things it needs, see the light before its too late

The day will come when there is no multitasking, but each program will run on its own core with a stripped down OS

I hate to break it to you Dex, but if you have a program on each core, you're actually multitasking.

Unless of course you only want one core to be working at a time until its program finishes running?

pcmattman wrote:

The day will come when there is no multitasking, but each program will run on its own core with a stripped down OS

I hate to break it to you Dex, but if you have a program on each core, you're actually multitasking.

Unless of course you only want one core to be working at a time until its program finishes running?

Multitasking in computer sence is cpu time sharing, what it will be replaced with is "Parallel processing".
It will be like running 100 of single-tasking OS install PC, all at the same time.

What would the cores do when one process had to wait for I/O ? And wouldn't you still need IPC (and therefore a unified kernel to manage it properly)?

Try looking at all the processes on your system. When I ran 'ps ax | wc -l' I got 136 processes on a Linux computer running just a web browser and a text editor. Imagine the ammount of processes that computers in the future (when 136 core machines are feasible for desktops) will have.

Multitasking in computer sence is cpu time sharing

No, multitasking is the act of performing multiple tasks at once. CPU time sharing is one way of achieving that (with the current hardware). If you're running 100 tasks, each with its own core, you are still multitasking.

pcmattman wrote:No, multitasking is the act of performing multiple tasks at once. CPU time sharing is one way of achieving that (with the current hardware). If you're running 100 tasks, each with its own core, you are still multitasking.

Well, if you really want to be technical about it, CPU time sharing isn't true multitasking (because tasks are switching about, not executing at the same time). You guys have it the wrong way round: multi-core processing is the only real multitasking we have today.

It's the illusion we can create that matters. There are no actual movies, just still images that flick over really quickly. We never walk, just put one foot in front of the other lots.

Hi,

Dex wrote:It will be like running 100 of single-tasking OS install PC, all at the same time.

No.

As each process needs more CPU power (for better graphics, processing larger amounts of data, etc) each process will have more threads and use more cores, so you'd end up with (for e.g.) a computer with 64 logical CPUs running 3 processes with 64 threads per process; or 192 threads being scheduled on 64 CPUs (where any thread runs on any CPU to get the most "bang per buck" out of the system).

For your approach, you'd end up with (for e.g.) a computer with 64 logical CPUs running 3 processes with 1 thread per process, and none of the processes will have enough CPU time even though there's at least 61 logical CPUs doing nothing. To get around this limitation programmers will write applications that use many processes (instead of writing applications that use many threads), which is similar to what you're trying to avoid except there's more overhead, more hassle for the programmer and it'd be less efficient because CPUs will be idle when there's work to be done (because if one process blocks the OS won't be able to schedule other processes on that CPU).

The only advantage that I can see is that this approach reduces the complexity of the kernel, but that's only a pretend advantage - once you start writing things like GUIs, daemons, etc you'll need to use multiple processes just to use multiple CPUs, and the complexity you avoided in the scheduler will come back and bite you hard everywhere else.


Cheers,

Brendan