@ChrisH

Morphos has TLSF memory management (o(1) allocation time), which is faster than slab allocators, actually, but is still compatible with all "undocumented" but well-known tricks anyway (such as golded 6 one, for instance).

And about virtual memory (or rather swap memory, because virtual memory is really a different thing that both os4 & morphos have), morphos 0.x had that concept implemented about 8 years ago. It was not maintained to current versions, because it didn't make that much sense with machines like Pegasos where you can physically have the whole addressable amount (~2GB) of memory anyway, which is obviously way more efficient. What's the point of having virtual memory if you can have real memory instead? Of course the situation is different with efika, but you certainly wouldn't like to swap on PIO IDE either, so... :)

Besides, as we can see in OS4.1, there are quite many reported compatibility issues with virtual memory usage. Whether it's a design issue or just a small bug i don't know, but i know i wouldn't like to have such a feature only semi-working.

And more generally, we see really contradictory critics against MorphOS:
- some say it's not amigaos-like anymore because it became too modern and different (ambient, united prefs, efficient 3d, descent usb support, you name it...)
- and on the other hand, some say MorphOS is just a ppc os 3.x without any kernel improvement, unlike OS4.x that is designed for the future

So, what to believe then? :)

Last edited by Fab on 08-Aug-2009 at 02:18 PM.
Last edited by Fab on 08-Aug-2009 at 12:22 PM.
Last edited by Fab on 08-Aug-2009 at 12:11 PM.

@Fab

Quote:

Morphos has TLSF memory management (o(1) allocation time), which is faster than slab allocators

Benchmarks?

Quote:

So, what to believe then?

I would like to have OS that supoorts partitions larger than 128 GB...

Quote:

I would like to have OS that supoorts partitions larger than 128 GB...

Just curious: are you saying that because OS4 supports it, and MorphOS does not, or because you actually need it ? (in which case I'd be curious to know why :))

_________________
http://www.warpdesign.fr/

@Leo

Now I use WinUAE box that supports it. I have only one partition (far bigger than 128 GB) for data (video, pics etc) and I like it. HDD on this PC is 1 TB and I don´t need more than 4 partitions - with 128 GB limit I should have 8 (!) partitions.

Quote:

care to elaborate?

NO

that's more a job for number6 if he wishes

_________________
"The system no longer works " -- Young Anakin Skywalker

@pavlor

Quote:

Benchmarks?

If you have any benchmark that comes to your mind, feel free.
Anyway, the point is TLSF has a constant allocation time, while Slab allocator doesn't. Slab is also more about caching system objects (to be seen if it has an actual purpose in amigaos).

That said, it must be seen precisely how well they perform in different conditions. There's a book that studies that, unfortunately the link isn't free.

Quote:

I would like to have OS that supoorts partitions larger than 128 GB..

FFS, ext2/ext3 and ntfs have >128GB support. You can also use the latest SFS 68k version with >128GB if you really want it badly. :)

Last edited by Fab on 08-Aug-2009 at 03:53 PM.

@Fab
Seems like a struck a nerve, which was not my intention. In any event, I don't intend to continue what looks like become another stupid Red vs Blue war. However, I will briefly comment on what you said...

Quote:

Morphos has TLSF memory management (o(1) allocation time), which is faster than slab allocators,

The last I heard, MorphOS suffered for severe memory fragementation & poor memory allocation speed (same as OS3.x), so I am apparently out-of-date.

If it is anything like that TLSF mem hack that was released for OS3.x, then it's probably useless. At least TLSF made no difference to the speed of my program under OS3.x, where-as my own super-fast memory allocator made a huge difference.

Also, that TLFS mem hack was incompatible with certain OS3.x programs, most likely the same ones that OS4.1 is incompatible with.

Quote:

Besides, as we can see in OS4.1, there are quite many reported compatibility issues with virtual memory usage

It doesn't seem bug-free in OS4.1 beta for Sam440 (USB stops working in certain situations), but it does work. I fully expect the issue(s) to be fixed for the final release of OS4.1 on Sam440, and suggest you reserve judgment until then.

Quote:

And more generally, we see really contradictory critics against MorphOS:

I did not critise MorphOS, so I don't know why you brought this up. Perhaps it might be more appropriate to ask why some MorphOS users just *had* to be first to compare (*) it to OS4, and try to stir up resentment & flames? Do you like falling into that trap?

(* = when I say "compare", I really mean "list what is allegedly does better". A true unbiased comparison would list pros AND cons.)

Last edited by ChrisH on 08-Aug-2009 at 03:37 PM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

There's a fine documentation on the new memory managment in 2.x at this adress :
http://www.morphos-team.net/tlsf.html

Quote:

The last I heard, MorphOS suffered for severe memory fragementation & poor memory allocation speed (same as OS3.x), so I am apparently out-of-date.

That was the 1.4 times. So quite outdated, yes. About TLSF performance, it certainly makes a big difference, both in fragmentation and allocation times. Now, i haven't tested the OS3.x patch, so i can't comment on this implementation, but on MorphOS, it certainly makes a difference.

For instance, under MorphOS 1.4 or 2.x with TLSF disabled, my Wesnoth port with libstdc++ used to take really long to start (let's say 5 minutes or so), while it was about 30 times faster with a build using STLPort (which i used for release). With TLSF, the build with libstdc++ is now just as fast as the build using STLPort.

Quote:

It doesn't seem bug-free in OS4.1 beta for Sam440 (USB stops working in certain situations), but it does work. I fully expect the issue(s) to be fixed for the final release of OS4.1 on Sam440, and suggest you reserve judgment until then.

I've also seen several other reports here or at aw.net about weird behaviour or even crashes when swap was used. Maybe some apps aren't designed to behave well with that, but that's not the point. My only point is that such a critical feature as memory allocation should be bullet-proof. Anyway, that's off-topic here.

Quote:

I did not critise MorphOS, so I don't know why you brought this up. Perhaps it might be more appropriate to ask why some MorphOS users just *had* to be first to compare (*) it to OS4, and try to stir up resentment & flames? Do you like falling into that trap?

I used critic in its neutral meaning. A critic can be good or bad.

@ChrisH:
Quote:

If it is anything like that TLSF mem hack that was released for OS3.x, then it's probably useless.

It's useless, if you try to "optimize" your apps performance with it. It's not however, if you want to sustain useable system responsivity after days of heavy usage, with little to no mem fragmentation. It was it's purpose, and it does it's job on both my classics quite well..

Quote:

If it is anything like that TLSF mem hack that was released for OS3.x, then it's probably useless.

I haven't encountered so many apps incompatible with TLSF, but in case of MorphOS, if you experience compatibility problems with an application you really need so badly, you can switch back to the old memory system, with a simple boot argument...

_________________
MorphOS, classic Amiga, demoscene, and stuff
"When a bridge is not enough, build a Viaduct!"
"Strip the Amiga community of speculation and we can fit every forum on a 720k floppy" (by resle)

Quote:

If it is anything like that TLSF mem hack that was released for OS3.x, then it's probably useless. At least TLSF made no difference to the speed of my program under OS3.x, where-as my own super-fast memory allocator made a huge difference.

If you are using memory pools then TLSF does not help much under OS3. In OS3 memory pools are always "slow" depending on memory and puddle fragmentation. In MorphOS memory pool allocs/deallocs are always very fast but only if you are using TLSF.

But even with (relatively) slow memory pools TLSF gives clear advantage on OS3 with faster memory management and lesser fragmentation. My OS3 applications are always optimized for TLSF.

Quote:

Also, that TLFS mem hack was incompatible with certain OS3.x programs, most likely the same ones that OS4.1 is incompatible with.

It can cause problems with certain debugging tools like Mungwall or Wipeout. But it does not matter because in MorphOS they can not work due to new Exec calls and native port of those tools is needed.

In OS3 an update for those tools is (probably) needed. Not sure if compatibility could be enhanced in the TLSF utility itself.

Quote:

It doesn't seem bug-free in OS4.1 beta for Sam440 (USB stops working in certain situations), but it does work.

As far as VM is concerned I do not think that implementation is broken (there is VMM and Gigamem for OS3 and they do work) but more like some applications fail to work properly when paging kicks in. In OS3 it usually works but crashes randomly at random places when running out of physical ram.

Last edited by itix on 08-Aug-2009 at 07:20 PM.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@itix Quote:

If you are using memory pools then TLSF does not help much under OS3.

No I was not using pools. Perhaps there was some other memory patch that conflicted with it, but I think (this was some time ago) I tried disabling all my patches without success.

Certainly the TLSF algorithm should be very fast, although I suspect it won't elimate external fragmentation as well as something like a Slab allocator (as used by Linux, OS4, etc). Of course it is still lightyears ahead of OS3.x.

@Chain-Q Quote:

It's useless, if you try to "optimize" your apps performance with it.

Sorry, you've lost me. What do you mean?

Quote:

I haven't encountered so many apps incompatible with TLSF

They won't be incompatible unless they either (a) deallocate part (rather than all) of a memory allocation, or (b) directly manipulate the Exec memory list. "b" will be limited to system hacks, which should not be a problem. "a" could be any program, but I suspect very few programs did it in reality (as you seem to have found but Fab perhaps disagrees).

@Develin
Thanks for the link, I will read sometime soon.

@fab Quote:

TLSF memory management (o(1) allocation time), which is faster than slab allocators

Got any links that prove that? The literature I read seems to claim that Slab allocators have O(1) performance... although I had a hard time seeing that as true if they were built on-top of an O(N) allocator like OS3.x has. If a Slab allocator was built on-top of TLSF, then you would definitely get O(1) performance while simulatenously minimising external fragmentation (which I don't think TLSF does so well).

Last edited by ChrisH on 09-Aug-2009 at 08:22 AM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

Quote:

becouse its nothing better or is because they are stuck in the past?

Both. Or how do you define being stuck in the past. I guess the main reason for moving to "next generation platforms" has been the possibility to run familiar Amiga software on more modern and much faster hardware, no matter if there'd come any exclusive native programs. I don't believe that either OS4 or MorphOS would have become even this popular if they'd been completely detached from classic Amiga. No chance. Some people still find some older programs good and usable and filling their needs and likes (even better than later available replacements in some cases), call it being stuck if you want.

Now there's native software available in certain degree, but as there isn't any commercial potential still, it's impossible to cover all special areas with limited amount of hobbyist coders. At least the progress is very slow and takes still years to fill the gaps. Amiga had big commercial (as well as hobbyist) apps scene and it still is essential source for making new platforms usable for different kinds of needs. That's why good emulation/compatibility in operating systems is very critical still. And will be for long.

_________________
- The wiki based MorphOS Library - Your starting point for MorphOS
- Software made by jPV^RNO

Quote:

Certainly the TLSF algorithm should be very fast, although I suspect it won't elimate external fragmentation as well as something like a Slab allocator (as used by Linux, OS4, etc). Of course it is still lightyears ahead of OS3.x. ... Got any links that prove that? The literature I read seems to claim that Slab allocators have O(1) performance... although I had a hard time seeing that as true if they were built on-top of an O(N) allocator like OS3.x has. If a Slab allocator was built on-top of TLSF, then you would definitely get O(1) performance while simulatenously minimising external fragmentation (which I don't think TLSF does so well).

Here are a few links about TLSF vs SLAB.

About efficiency, see http://code.google.com/p/compcache/wiki/AllocatorsComparison
As you see, TLSF wins hands down on this topic (SLUB is a more recent version of SLAB): SLUB eats 43% more memory.

Then another interesting link to some book: http://portal.acm.org/citation.cfm?id=1412656

Also note that TLSF has been designed in 2004, while SLAB has been introduced with SunOS in 1994. Of course, you can't draw any conclusion from that, but in the research, you generally try to find more efficient algorithms than previous ones (be it on speed or fragmentation), else it doesn't make much sense to publish them.

Also, about the SLAB allocator (at least the os4 implementation), i've often read from os4 developers in related threads that you can't really trust the free memory amount anymore in titlebar (because some objects may be cached, or whatever). That's an issue you don't experience with MorphOS TLSF implementation.

Quote:

read-only support for HFS+ formatted volumes

Nice

_________________
ikir

Quote:

About efficiency, see http://code.google.com/p/compcache/wiki/AllocatorsComparison As you see, TLSF wins hands down on this topic (SLUB is a more recent version of SLAB): SLUB eats 43% more memory.

Your link says nothing about speed.

Quote:

Also, about the SLAB allocator (at least the os4 implementation), i've often read from os4 developers in related threads that you can't really trust the free memory amount anymore in titlebar (because some objects may be cached, or whatever). That's an issue you don't experience with MorphOS TLSF implementation.

And this is good or bad for MorphOS?

There is TLSFMem.readme written by Chris Hodges but TLSF page seems gone.

_________________
Amiga Developer
Amiga 500, Efika, Mac Mini and PowerBook

@pavlor

Quote:

Your link says nothing about speed.

I didn't claim it did. It says about memory usage, tho.

Quote:

And this is good or bad for MorphOS?

Unless you think it's bad to have an accurate figure of the free amount of memory, i think it's safe to say it's good. :)

@Fab

Quote:

Unless you think it's bad to have an accurate figure of the free amount of memory, i think it's safe to say it's good. :)

If the solution in OS4 is faster, then it is better to sacrifice accurate figure of the free amount of memory, I think.

In my point of view, there aren´t many differences between OS4 and MOS. Both have their pros and cons: I like modern desktop in MorphOS (Ambient is really nice) and some features of OS4 (concept - not hack... - of virtual memory with retaining OS3 compatibility).

Many thanks to all involved!

_________________
Glames / Boing Attitude :)