Not using dynamic memory allocation.

[Jezze]

Hi,

I've created my first OS and it works great so far. By design I want it to be single tasking. I began thinking about how I would write my dynamic memory allocator when I suddenly realized that wait; Is this really neccessary?

If I have an operating system with a very small memory footprint I could load my entire operating system into memory right from the start and never worry about allocating more memory for programs. This would have a few benefits as well as a few downsides.

The most important pros would be:

* I would never have to worry about memory running out.
* It would be more reliable.
* It would execute very fast.
* Because it is single tasking I never have to allocate memory for threads.

But what would the biggest downsides be you think? Could this actually work in a real operating system or would it just be a stupid concept?

[Brendan]

Hi,

If I don't have a car, does that mean I can get to the shops faster because I never need to stop and buy petrol/gas? Or does it just mean the 5 minutes I save each week will cost me many hours of time walking each day?

* Because it is single tasking I never have to allocate memory for threads.

An "average" (desktop) computer at the moment has 4 cores/CPUs. You're only planning to use one of them, and force application programmers to write their own threading library to get the most out of the CPU that the OS does use? Of course it will probably take 5 years or more to write the OS - by then "average" computers may have 16 CPUs.

Then there's "above average" computers. The computer I'm using to type this has 16 logical CPUs. In the next few months Intel will release "Nehalem-based Xeon EX" - an eight-core CPU with hyper-threading (16 logical CPUs per chip). There's already 8-socket motherboards for them. That adds up to a total of 128 logical CPUs. By the time your OS is ready to be used, how many CPUs will "above average" computers have?

What if "no multi-tasking and no memory management" makes code running on a single CPU twice as fast? Would you rather 1 CPU running twice, or 16 CPUs running at normal speed?

Ok, lets think about single-CPU systems. At the moment I'm writing a new version of my "build utility". It reads lots of files, processes them and generates lots of files. I use lots of threads to avoid "doing nothing" while I wait for data to be transferred to/from disk; and a reasonable OS would send the pages that I don't use often to swap space so that it can use that RAM for disk caching and speed up the file I/O (which is much more important for performance). With no multi-tasking and no memory managment, it'd be insanely slow, even for single-CPU.

So, in which way would "single-tasking with no memory management" be fast?


Cheers,

Brendan

[Jezze]

I'm not gonna argue against you because you seem to be on top of things.

But for arguments sake lets say that I'm using a single CPU.

For all workloads that does not require I/O operations it would be faster right?

[Brendan]

Hi,

I'm not gonna argue against you because you seem to be on top of things.

But for arguments sake lets say that I'm using a single CPU.

For all workloads that does not require I/O operations it would be faster right?

For code that doesn't do any I/O operations, depending on a lot of things (exact sequence of instructions, CPU, cache, memory speeds, IRQs, etc), not supporting multi-tasking probably won't make any difference at all (when a multi-tasking OS is only running a single task, then no task switches or anything occur - the multi-tasking is effectively disabled/unused), and not using paging might speed things up a little (maybe between 0% and 15% faster).

However, think of all the software you've used in the last 6 months. Can you think of anything that doesn't do any I/O?

If a tree falls in a forest and no one is around to hear it, does it make a sound? If a program does lots of work but doesn't create any output, then how can you tell if it did anything at all?


Cheers,

Brendan

[Srowen]

If i'm not wrong, the first version of Sun Solaris doesn't use dynamic memory for the kernel variable but it support multitasking anyway..

[inx]

@Jezze:

An "average" (desktop) computer at the moment has 4 cores/CPUs. You're only planning to use one of them, and force application programmers to write their own threading library to get the most out of the CPU that the OS does use? Of course it will probably take 5 years or more to write the OS - by then "average" computers may have 16 CPUs.

I believe Brendan is entirely correct on this point. You can keep your single-tasking concept, but unless you plan on developing only for embedded systems, I would recommend at least having kernel support for threads. In fact, many embedded systems are now multi-core or multi-CPU ARM, so even then, you're not entirely safe from severe performance degradation not having some form of multiprocessing support. If it makes you feel any better, having kernel-level threads for only one process would be sinfully simple.

[Owen]

If i'm not wrong, the first version of Sun Solaris doesn't use dynamic memory for the kernel variable but it support multitasking anyway..

Solaris is Unix SVR6 (IIRC?) derived. It's always had dynamic memory allocation in kernel land.

[quok]

If i'm not wrong, the first version of Sun Solaris doesn't use dynamic memory for the kernel variable but it support multitasking anyway..

Solaris is Unix SVR6 (IIRC?) derived. It's always had dynamic memory allocation in kernel land.

According to Wikipedia, SunOS 1.0 to 4.x was all BSD derived. IIRC, SunOS 1.0 was 4.1BSD, 2.0 was 4.2BSD. SunOS 3.0 was 4.2BSD plus SysV IPC, and SunOS 4.x was all 4.3BSD. SunOS 5.x is what is known as Solaris, and is SVR4 based. In fact, SunOS 5.0 (Solaris 2.0) IS SVR4.

[Love4Boobies]

I'm not gonna argue against you because you seem to be on top of things.

But for arguments sake lets say that I'm using a single CPU.

For all workloads that does not require I/O operations it would be faster right?

If a tree falls in a forest and no one is around to hear it, does it make a sound? If a program does lots of work but doesn't create any output, then how can you tell if it did anything at all?

That is indeed true. However, I think the question was not the right one to begin with. I'd ask "is there any workload where the design would perform faster and make any sense in a system with only one logical core (i.e., no SMT either)?"... The answer to that is yes, even with output - as long as it's asynchronous. For x86(-64) and IA-64, that would have to mean memory-mapped I/O, which is good news since this is pretty much how video framebuffers are accessed. In other words, you get to print out your results on screen.

[inx]

However, I think the question was not the right one to begin with. I'd ask "is there any workload where the design would perform faster and make any sense in a system with only one logical core (i.e., no SMT either)?"... The answer to that is yes, even with output - as long as it's asynchronous. For x86(-64) and IA-64, that would have to mean memory-mapped I/O, which is good news since this is pretty much how video framebuffers are accessed. In other words, you get to print out your results on screen.

lol Yes, uses for a Commodore 64 do tend to do well on a Commodore 64.