Click Here
home features news forums classifieds faqs links search
5765 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
Home
Features
News
Forums
Classifieds
Links
Downloads
Extras
OS4 Zone
IRC Network
AmigaWorld Radio
Newsfeed
Top Members
Amiga Dealers
Information
About Us
FAQs
Advertise
Polls
Terms of Service
Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
52 crawler(s) on-line.
 8 guest(s) on-line.
 0 member(s) on-line.



You are an anonymous user.
Register Now!
 tygre:  6 mins ago
 Kraftwerk2:  35 mins ago
 DWolfman:  1 hr 13 mins ago
 PhantomInterrogative:  1 hr 55 mins ago
 graffias79:  2 hrs 14 mins ago
 MEGA_RJ_MICAL:  2 hrs 32 mins ago
 billt:  2 hrs 34 mins ago
 Rob:  2 hrs 52 mins ago
 Jasper:  3 hrs 7 mins ago
 ggw:  3 hrs 14 mins ago

/  Forum Index
   /  Amiga OS4.x \ Workbench 4.x
      /  Interesting memory allocation benchmark
Register To Post

Goto page ( 1 | 2 | 3 | 4 | 5 | 6 Next Page )
PosterThread
Fab 
Interesting memory allocation benchmark
Posted on 18-Sep-2009 13:49:16
#1 ]
Super Member
Joined: 17-Mar-2004
Posts: 1178
From: Unknown

Quote:

Quote:

@Fab Quote:
I think we already discussed it once. And what's sure is that absolutely nothing indicates SLAB would be more advanced

Possibly we have previously discussed it long ago, but I have since gained a better understanding of OS4.1's Slab implementation: Please go read-up on the "VMem" allocator in relation to Slabs.

You will see that VMem is O(1) & therefore modern Slab implementation's like OS4's is also O(1). VMem is actually very similar to TLSF, but predates it by a few years & so is not quite so clever (or memory efficient).

I do NOT intend to debate the pros & cons of Slab allocators vs TLSF *here*. Please start another thread if you wish to do that.


So, I was bored, and wrote a small simple test. This test isn't meant to be clever at all: it just allocates memory areas and then frees them, in a loop.

Here's the link to binaries and sources:
http://fabportnawak.free.fr/sillybench/

Note that multitasking isn't switched off for the test, and of course be aware that more iterations and idle system will produce more stable results.

MorphOS2.3 (SafeMemList allocator (a bit like OS3.x, with more safety checks)) with membench_morphos:

iterations - result
1000 : ~160000 s (0.16 s)
2000 : ~320000 s (0.32 s)
10000 : ~1600000 s (1.6 s)
50000 : ~8200000 s (8.2 s)
100000 : ~16200000 s (16.2 s)
1000000 : ~17000000 s (161 s)

-> I think with more time, chunks and fragmentation, it would increase quite a lot, given the underlying algorithm. :)

MorphOS2.3 (TLSF allocator) with membench_morphos:

iterations - result
1000 : ~16000 s (0.016 s)
2000 : ~32000 s (0.032 s)
10000 : ~170000 s (0.17 s)
50000 : ~870000 s (0.87 s)
100000 : ~1740000 s (1.7 s)
1000000 : ~17000000 s (17 s)

-> No surprise, TLSF allocator is apparently 10 times faster than old MorphOS memory allocator in this simple scenario.

OS4.1 (advanced SLAB allocator) with membench_amigaos4:

iterations - result
1000 : ~5060000 s (5 s)
2000 : ~10120000 s (10 s)
10000 : ~50600000 s (50 s)
50000 : ~256000000 s (256 s)
100000 : ~514000000 s (514 s)
1000000 : N/A... I hadn't enough time for that. :)

-> Surprising result for the advanced SLAB allocator. It's really much much slower than MorphOS (hundreds times slower!). So it seems there's a high constant allocation time. But I really don't explain it. Even the older MorphOS allocator is way faster.

Anybody have a clue why OS4 shows such slow results? I expected TLSF to be faster, but not with this magnitude. There seems to be something really wrong with the OS4 memory allocation time, so maybe the test exploits something particularly unfavorable to OS4 allocator, i don't know.

Last edited by Fab on 18-Sep-2009 at 02:18 PM.
Last edited by Fab on 18-Sep-2009 at 02:17 PM.
Last edited by Fab on 18-Sep-2009 at 02:17 PM.
Last edited by Fab on 18-Sep-2009 at 02:04 PM.
Last edited by Fab on 18-Sep-2009 at 02:03 PM.

 Status: Offline
Profile     Report this post  
BaldGuy 
Re: Interesting memory allocation benchmark
Posted on 18-Sep-2009 14:29:35
#2 ]
Member
Joined: 11-Aug-2009
Posts: 28
From: Belgium

@Fab

I know not that OS4 is slow like this.

That is horrible.

Hope Amiga and Hyperion will fix soon.

_________________
AMIGA 500/EXT.FLOPPY
AMIGA 1200/030/50MHz/FPU/SCSI
AMIGA 4000/060/50MHz/SCSI/CYBERVISION
AMIGA CD32
AMIGA CDTV
AMIGA T-Shirt
AMIGA Mousepad
Commodore Underwear

 Status: Offline
Profile     Report this post  
zerohero 
Re: Interesting memory allocation benchmark
Posted on 18-Sep-2009 15:12:24
#3 ]
Team Member
Joined: 4-May-2004
Posts: 2524
From: Uddevalla, Sweden

@Fab

It's even slower on my A1 XE with a G4 @ 800MHz, though I have set my FSB down to 100MHz... Interesting results though.

_________________
Common sense - So rare it's almost like a super power

 Status: Offline
Profile     Report this post  
kas1e 
Re: Interesting memory allocation benchmark
Posted on 18-Sep-2009 15:17:12
#4 ]
Amiga Developer Team
Joined: 11-Jan-2004
Posts: 3411
From: Russia

Interesting benchmarks. Will be cool to hear somethink from the Os4 devels about :)

_________________
Join us to improve dopus5!
zerohero's mirror of os4/os3 crosscompiler suites

 Status: Offline
Profile     Report this post  
jPV 
Re: Interesting memory allocation benchmark
Posted on 18-Sep-2009 15:53:00
#5 ]
Cult Member
Joined: 11-Apr-2005
Posts: 683
From: .fi

With Pegasos1 and MorphOS2.3 (TLSF):

1000: 24248 s (~0.024s)
2000: 62200 s (~0.062s)
10000: 256290 s (~0.26s)
50000: 1229004 s (~1.2s)
100000: 2454614 s (~2.5s)
1000000: 24336641 s (~24s)

I didn't bother to boot to fresh system. So it's with couple of hours uptime, several irc clients, browser, ssh etc in the background :)

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

 Status: Offline
Profile     Report this post  
mike 
Re: Interesting memory allocation benchmark
Posted on 18-Sep-2009 15:53:29
#6 ]
Regular Member
Joined: 31-Jul-2007
Posts: 406
From: Alpha Centauri

68060 tlsfmem
1000 Elapsed time: 239673 s (0.23s)
2000 Elapsed time: 458838 s (0.45s)
10000 Elapsed time: 2277872 s (2.27s)
50000 Elapsed time: 11382361 s (11.3s)
100000 Elapsed time: 23131983 s (23.1s)
1000000 Elapsed time: 231297482 s (221.2s)

68060 exec's finest.
1000 Elapsed time: 406642 s (0.40)
2000 Elapsed time: 813348 s (0.81)
10000 Elapsed time: 4038716 s (4.0)
50000 Elapsed time: 20193021 s (20.1)
100000 Elapsed time: 40599833 s (40.5)
1000000 Elapsed time: 403810916 s (403.8)

oi, recompiled with gcc -O3 -m68060 -noixemul membench.c -o membench, gcc340 came to 280013-273133 ns for 1000 allocs, gcc295 came to 237650-226703 at best

Last edited by mike on 18-Sep-2009 at 04:50 PM.
Last edited by mike on 18-Sep-2009 at 04:39 PM.
Last edited by mike on 18-Sep-2009 at 04:11 PM.
Last edited by mike on 18-Sep-2009 at 03:57 PM.

_________________
C= Amiga addict
,,,
(Oo)
⎛☮ໄ
ﮑὠՀ
Couldn't care less what other people think, seeing that there's concrete evidence they don't.

 Status: Offline
Profile     Report this post  
bernd_afa 
Re: Interesting memory allocation benchmark
Posted on 18-Sep-2009 17:27:48
#7 ]
Cult Member
Joined: 14-Apr-2006
Posts: 829
From: Unknown

@Fab
>Anybody have a clue why OS4 shows such slow results? I expected TLSF to be >faster, but not with this magnitude.

try such numbers for the bench.If OS4 get faster.

int sizes[] = {2, 5, 11, 13, 28, 20, 44, 19, 3, 77, 33, 127, 251,
304, 111, 700, 43, 7011, 112, 1, 4000 }; /* Silly stuff, whatever :) */

thats more praxis relatet.most frequent mem alloc are always in range from 0 to 256 bytes.i do a small profiling tool that count memalloc < 256 and memalloc >256.

and use of programs show that memallocs < 256 are about 1000* more often as larger mem allocs.

larger memallocs happen not so often in reality, but when do the bench that it do so large allocs, the mmu tables must change often and rearrange.

 Status: Offline
Profile     Report this post  
Tomppeli 
Re: Interesting memory allocation benchmark
Posted on 18-Sep-2009 17:34:00
#8 ]
Super Member
Joined: 18-Jun-2004
Posts: 1635
From: Home land of Santa, sauna, sisu and salmiakki

I've noticed a long time ago that allocation is fast but deallocation is slow. So add reporting of elapsed time in between allocation and deallocation loops. And rerun the test. (Also for AmigaOS4 use AllocVecTags (it uses MEMF_PRIVATE flag by default also).)

Edit: I found a bug from it:
Quote:
APTR ptr[sizeof(sizes)/sizes[0]];
for(j = 0; j < sizeof(sizes)/sizeof(sizes[0]); j++)

Last edited by Tomppeli on 18-Sep-2009 at 06:14 PM.
Last edited by Tomppeli on 18-Sep-2009 at 05:46 PM.

_________________
Rock lobster bit me, so excuse me. Amiga. Never forget.
X1000 + AmigaOS4.1 FE
"Anyone can build a fast CPU. The trick is to build a fast system." -Seymour Cray

 Status: Offline
Profile     Report this post  
Fab 
Re: Interesting memory allocation benchmark
Posted on 18-Sep-2009 18:00:07
#9 ]
Super Member
Joined: 17-Mar-2004
Posts: 1178
From: Unknown

@Tomppeli

There was indeed a copy/paste bug, but it didn't have any ill effect anyway, given the value of size[0].

But i changed it a bit. Not that it will change anything to these results, though. :)

 Status: Offline
Profile     Report this post  
itix 
Re: Interesting memory allocation benchmark
Posted on 18-Sep-2009 18:17:11
#10 ]
Elite Member
Joined: 22-Dec-2004
Posts: 3398
From: Freedom world

I expected old memlist based memory allocater would have been slower than SLAB allocator in OS4. Even 68k Amiga is faster...

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

 Status: Offline
Profile     Report this post  
Cheese 
Re: Interesting memory allocation benchmark
Posted on 18-Sep-2009 21:58:54
#11 ]
Regular Member
Joined: 23-Oct-2006
Posts: 258
From: Unknown

Seems SLAB rhymes with ....

Last edited by Cheese on 18-Sep-2009 at 10:18 PM.

_________________
x86/MorphOS 4.0

"Delving into the past can be a dangerous exercise." -hyperionmp

"I've been a supporter of "REACTION" GUI because is an Amiga OS thing." -Snuffy

"I personally prefer a vision of do'ers and makers rather than

 Status: Offline
Profile     Report this post  
ssolie 
Re: Interesting memory allocation benchmark
Posted on 18-Sep-2009 22:46:39
#12 ]
Elite Member
Joined: 10-Mar-2003
Posts: 2745
From: Alberta, Canada

@Fab
Quote:
Anybody have a clue why OS4 shows such slow results?

I would suggest you email Thomas Frieden directly and discuss it. Perhaps you can help find a root cause and a solution to fix it if there is indeed a problem.

_________________
ExecSG Team Lead

 Status: Offline
Profile     Report this post  
pixie 
Re: Interesting memory allocation benchmark
Posted on 18-Sep-2009 22:56:54
#13 ]
Elite Member
Joined: 10-Mar-2003
Posts: 2662
From: Figueira da Foz - Portugal

@ssolie

Quote:
Perhaps you can help find a root cause and a solution to fix it if there is indeed a problem.


And what exactly lead you into thinking there is a problem?

_________________
Indigo 3D Lounge, my second home.
The Illusion of Choice | Am*ga

 Status: Offline
Profile     Report this post  
Samwel 
Re: Interesting memory allocation benchmark
Posted on 19-Sep-2009 7:44:51
#14 ]
Elite Member
Joined: 7-Apr-2004
Posts: 3396
From: Sweden

@pixie

Eh.. Maybe because the speed result is waaay slower than it should be?

_________________
/Harry

[SOLD] A1-C - 750GX 800MHz - 512MB - Antec Aria case

Avatar by HNL_DK!

 Status: Offline
Profile     Report this post  
corto 
Re: Interesting memory allocation benchmark
Posted on 19-Sep-2009 8:10:06
#15 ]
Regular Member
Joined: 24-Apr-2004
Posts: 328
From: Grenoble (France)

@Fab

Are we sure that memory functions do the same thing ? I mean, at work we had a similar case between two Linux and at the end one was using 'lazy allocation' : the alloc function was returned with success but mapping part of the allocation was done at the first memory access in the page.

It would be interesting to split the benchmark to know the elapsed time associated with each function.

With your raw results, that's true that something is wrong ...

As I work on tests and benchmarks everyday, I use to have (at least) 2 conclusions :
- be careful with benchmarks results and early conclusions
- they are both useful to improve software

Thanks Fab, you certainly pointed a problem.

 Status: Offline
Profile     Report this post  
itix 
Re: Interesting memory allocation benchmark
Posted on 19-Sep-2009 8:26:14
#16 ]
Elite Member
Joined: 22-Dec-2004
Posts: 3398
From: Freedom world

@Samwel

Quote:

Eh.. Maybe because the speed result is waaay slower than it should be?


It should be easy to find out by running the test on OS 4.0.

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

 Status: Offline
Profile     Report this post  
ChrisH 
Re: Interesting memory allocation benchmark
Posted on 19-Sep-2009 9:03:40
#17 ]
Elite Member
Joined: 30-Jan-2005
Posts: 6673
From: Unknown

@Fab
Interesting albiet worrying results. I'll hopefully have time to look at closer later, but it might explain why E programs still perform better on OS4 with a custom super-fast allocator (as provided by AmigaE & PortablE) than when directly using the OS.

It's a pity that your benchmark does not report time per allocation ( = total time / number of allocations), that would make comparisons easier, and microseconds a more sensible unit. I changed it to milliseconds for sanity, but currently left it at total elapsed time for easy comparison with your results.

BEWARE that the Debug Kernel added 50% on to my reported times.

Last edited by ChrisH on 19-Sep-2009 at 09:05 AM.

_________________
Author of the PortablE programming language.
I can usually be found on www.Amigans.net (my favourite Amiga forum).
It is pitch black. You are likely to be eaten by a grue...

 Status: Offline
Profile     Report this post  
Cyborg 
Re: Interesting memory allocation benchmark
Posted on 19-Sep-2009 9:26:34
#18 ]
Regular Member
Joined: 26-Nov-2003
Posts: 422
From: Germany

@Fab

bernd_afa is right. Your power-of-2 sizes are a) not praxisrelevant and b).. well.. no algorithm performs equally good or bad in every situation. I'm sure someone could also find a situation where the results would be reversed.. Anyway, if your do what bernd_afa suggested, OS4 is numerous times faster. Still not faster than MOS, but there are enough pitfalls a "benchmark" can fall into to generate questionable results.

For the heck of it here the results with bernd_afa changes on OS4:

1000: 113044 s (0.113044 s)
2000: 225120 s (0.225120 s)
10000: 1155693 s (1.155693 s)
50000: 5807400 s (5.807400 s)
100000: 11615699 s (11.615699 s)
1000000: 116656246 s (116.656250 s)


Quite a difference, huh? And that only because more realistic allocation sizes were used than the original silly ;) ones.

I only tested an 68k build on MOS, because I don't have the SDK (where could I get that from?). As said, it still was faster (the JIT doesn't really have any great workload with that little code) but a lot slower than with the original silly sizes.




Anyway.. this just to show you that there is absolutely no big fat problem in the memory allocation algorithms in OS4 and that the original "benchmark" of this thread doesn't mean anything. (And even if MOS is faster... well.. so be it ;) )

_________________
Regards, Cyborg.
AmigaOS4 development team member

"In the beginning was CAOS.."
-- Andy Finkel, 1988 (ViewPort article, Oct. 1993)

 Status: Offline
Profile     Report this post  
ChrisH 
Re: Interesting memory allocation benchmark
Posted on 19-Sep-2009 10:54:28
#19 ]
Elite Member
Joined: 30-Jan-2005
Posts: 6673
From: Unknown

@Fab
I hate coding in C, so I rewrote yours in E (actually PortablE), and compiled it for various OSes:
http://cshandley.co.uk/temp/membench/

As an aside: The E source code is about half the size of the C source, has no OS-specific work-arounds, reports more meaningful information, and looks a hell of a lot nice to boot :) . I also compiled an AROS version for the hell of it (since it is about zero extra effort).

EDIT: I have also uploaded a Bernd_AFA version of the test. Is a LOT faster as reported elsewhere!

Last edited by ChrisH on 19-Sep-2009 at 11:19 AM.
Last edited by ChrisH on 19-Sep-2009 at 11:06 AM.
Last edited by ChrisH on 19-Sep-2009 at 10:56 AM.

_________________
Author of the PortablE programming language.
I can usually be found on www.Amigans.net (my favourite Amiga forum).
It is pitch black. You are likely to be eaten by a grue...

 Status: Offline
Profile     Report this post  
ChrisH 
Re: Interesting memory allocation benchmark
Posted on 19-Sep-2009 11:16:52
#20 ]
Elite Member
Joined: 30-Jan-2005
Posts: 6673
From: Unknown

I have now uploaded a TEST script, which makes it incredibly easy. Here are my results using the NON-debug kernel on my 667MHz Sam440ep:
Quote:
execute membench-TEST membench-bernd_afa_OS4

1000 iterations:
Elapsed time: 114872 s = 114 ms
Average time: 5 s (per allocation + deallocation)

2000 iterations:
Elapsed time: 228924 s = 228 ms
Average time: 5 s (per allocation + deallocation)

10000 iterations:
Elapsed time: 1133979 s = 1133 ms
Average time: 5 s (per allocation + deallocation)

50000 iterations:
Elapsed time: 5610080 s = 5610 ms
Average time: 5 s (per allocation + deallocation)

100000 iterations:
Elapsed time: 11195496 s = 11195 ms
Average time: 5 s (per allocation + deallocation)

1000000 iterations:
Elapsed time: 111841734 s = 111841 ms
Average time: 5 s (per allocation + deallocation)


FWIW, I got 9 us when using the Debug kernel.

Last edited by ChrisH on 19-Sep-2009 at 11:17 AM.

_________________
Author of the PortablE programming language.
I can usually be found on www.Amigans.net (my favourite Amiga forum).
It is pitch black. You are likely to be eaten by a grue...

 Status: Offline
Profile     Report this post  
Goto page ( 1 | 2 | 3 | 4 | 5 | 6 Next Page )

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle