@AlexC Quote:

To be able to use sobj with the old update4 wb (51.x) you'd have to replace so many other components that in the end you'd end up with a 52.x setup.

I had been told that OS4.0 users could just use the latest SObj files (intended for OS4.1) without problems. Seems I was misinformed?

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

@ChrisH

In order to keep the results of the Bernd test in one place, please see my amended post #47, which now has the OS4 results included with those of OS3.

If you want me to run your other tests (see earlier post where I ran only Fab's tests), please let me know.

Oh...is it my imagination or am I clobbering Peg2 G4 and XE G4 results? Heh.

#6

Last edited by number6 on 20-Sep-2009 at 06:28 PM.

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

on WinUAE Amikit (amd64 5200x2)

membench_68k:

1000 = 280001 us
2000 = 599999 us
10000 = 2840000 us

Last edited by Seiya on 21-Sep-2009 at 12:18 AM.

_________________

@Fab

Interesting indeed !!!

_________________
- KimmoK
// For freedom, for honor, for AMIGA
//
// Thing that I should find more time for: CC64 - 64bit Community Computer?

@Thread

I just thought about something, can't test myself right now, but is there anyone to test replacing the

AllocVec/FreeVec

AllocSysOject(ASOT_ITEMPOOL,ASOITEM_ItemSize,sizes[j],ASOITEM_MFlags,MEMF_PUBLIC,TAG_END);
FreeSysObject(ASOT_ITEMPOOL,ptr[j])

_________________
AOS 4.1 : I dream it, Hyperion did it !
Now dreaming AOS 4.2...
Thank you to all devs involved for this great job !

@abalaban

Where is the connection between a sufficiently large allocation and the creation of an item pool for fixed sized items? This is like comparing AllocVec() to CreatePool(). They simply have nothing in common.

_________________
Why stop it now, just when I am hating it?

Thore Böckelmann

@tboeckel

you are right, I don't know why I had the impression ASOT_ITEMPOOL was allocating an item from a system dynamically created pool. rereading the autodoc it's clearly written that in fact it's allocating a specialized memory pool for a given object size. I was a bit tired, sorry for disturbing the discussion
I'm so surprised by such a bad performance (using OS4.1 daily here I never noticed such slowness) that I'm desperately trying to find an explication/solution where it would give better figures...

_________________
AOS 4.1 : I dream it, Hyperion did it !
Now dreaming AOS 4.2...
Thank you to all devs involved for this great job !

i just tried chrish compile of bernds 68k benchmark on an regular a4k cs060ppc
(without tlsf) but the results are confusing me a little:

18.RAM_0:> membench-bernd_afa_OS3 1000
Elapsed time: 995383 µs = 995 ms
Average time: 47 µs (per allocation + deallocation)

and then again:

18.RAM_0:> membench-bernd_afa_OS3 1000
Elapsed time: 2474416 µs = 2474 ms
Average time: 117 µs (per allocation + deallocation)


18.RAM_0:> membench-bernd_afa_OS3 2000
Elapsed time: 5233329 µs = 5233 ms
Average time: 124 µs (per allocation + deallocation)

18.RAM_0:> membench-bernd_afa_OS3 10000
Elapsed time: 25325698 µs = 25325 ms
Average time: 120 µs (per allocation + deallocation)

Last edited by wawa on 21-Sep-2009 at 02:48 PM.
Last edited by wawa on 21-Sep-2009 at 02:48 PM.

@Fab

I hope at the end of this somebody summarizes it. How slow is OS4 memory allocation?

_________________
X5000 / microA1(OS4.1 FE U2) / CodeBench / Imagine / Blender
Lightwave 2019 / Microsoft Visual C++

@thinkchip

Well, in favorable conditions (i.e small allocations), OS4 allocator seems to be a bit faster than MorphOS old allocator, but several times slower than MorphOS TLSF allocator (which is the default allocator).

With bigger allocations (one should determine how much exactly), OS4 allocator seems really *extremely* slower than all other allocators (even compared to a 68k machine).

That's all that could be said from my original benchmark (and the derivated version with smaller sizes). Umisef's benchmark should also be run on OS4, since it's much more interesting to show the actual allocator performance in a fragmentation condition.

@Fab

Quote:

That's all that could be said from my original benchmark (and the derivated version with smaller sizes). Umisef's benchmark should also be run on OS4, since it's much more interesting to show the actual allocator performance in a fragmentation condition.

If others feel this would be a worthy test and supply an executable, I'd be happy to incorporate my results with the other tests I've run here on 4.0, for whatever it's worth.

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@KimmoK

Quote:

Interesting indeed !!!

you call ?



btw: anyone port this test to a Mac PPC and run it? I for one would like to see what we get.

Last edited by Interesting on 21-Sep-2009 at 03:51 PM.

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

@Interesting

Quote:

btw: anyone port this test to a Mac PPC and run it?

Small allocations:

1000 iterations: Elapsed time: 9916 us (0.009916 s)
2000 iterations: Elapsed time: 20402 us (0.020402 s)
10000 iterations: Elapsed time: 99572 us (0.099572 s)
50000 iterations: Elapsed time: 496547 us (0.496547 s)
100000 iterations: Elapsed time: 1019312 us (1.019312 s)
1000000 iterations: Elapsed time: 9928873 us (9.928873 s)

Power-of-two
1000 iterations: Elapsed time: 44308 us (0.044308 s)
2000 iterations: Elapsed time: 89221 us (0.089221 s)
10000 iterations: Elapsed time: 443498 us (0.443498 s)
50000 iterations: Elapsed time: 2213461 us (2.213461 s)
100000 iterations: Elapsed time: 4421420 us (4.421420 s)
1000000 iterations: Elapsed time: 44288658 us (44.288658 s)

1.25GHz G4, 512k L2, 167MHz FSB, MacOS X Leopard

15.dill:bench> membench-bernd_afa_OS3 1000
Elapsed time: 212202 �s = 212 ms
Average time: 10 �s (per allocation + deallocation)
15.dill:bench> membench-bernd_afa_OS3 2000
Elapsed time: 424403 �s = 424 ms
Average time: 10 �s (per allocation + deallocation)
15.dill:bench> membench-bernd_afa_OS3 5000
Elapsed time: 1065175 �s = 1065 ms
Average time: 10 �s (per allocation + deallocation)
15.dill:bench> membench-bernd_afa_OS3 50000
Elapsed time: 10640157 �s = 10640 ms
Average time: 10 �s (per allocation + deallocation)
15.dill:bench> membench-bernd_afa_OS3 100000
Elapsed time: 21277950 �s = 21277 ms
Average time: 10 �s (per allocation + deallocation)

I have a feeling some consistent benchmarks would be nice. I dont really understand why wawa's cyberstorm is slower then this blizzard 1260. And tlsf seems to be a two fold improvement over filelist

Last edited by mike on 21-Sep-2009 at 04:46 PM.
Last edited by mike on 21-Sep-2009 at 04:46 PM.
Last edited by mike on 21-Sep-2009 at 04:43 PM.

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

@mike:

seems its really tlsf dependant, now i can confirm your results:

15.RAM_0:> tlsfmem
15.RAM_0:> membench-bernd_afa_os3 1000
Elapsed time: 218796 µs = 218 ms
Average time: 10 µs (per allocation + deallocation)
15.RAM_0:> membench-bernd_afa_os3 2000
Elapsed time: 444772 µs = 444 ms
Average time: 10 µs (per allocation + deallocation)
15.RAM_0:> membench-bernd_afa_os3 5000
Elapsed time: 1097295 µs = 1097 ms
Average time: 10 µs (per allocation + deallocation)
15.RAM_0:> membench-bernd_afa_os3 10000
Elapsed time: 2193542 µs = 2193 ms
Average time: 10 µs (per allocation + deallocation)
15.RAM_0:> membench-bernd_afa_os3 50000
Elapsed time: 10910625 µs = 10910 ms
Average time: 10 µs (per allocation + deallocation)
15.RAM_0:> membench-bernd_afa_os3 100000
Elapsed time: 20822604 µs = 20822 ms
Average time: 9 µs (per allocation + deallocation)
15.RAM_0:> membench-bernd_afa_os3 1000000
Elapsed time: 210849014 µs = 210849 ms
Average time: 10 µs (per allocation + deallocation)

ive previously forgot to switch off the muforce background and the rest.
without it:
15.RAM_0:> membench-bernd_afa_os3 1000
Elapsed time: 1200470 µs = 1200 ms
Average time: 57 µs (per allocation + deallocation)
15.RAM_0:> membench-bernd_afa_os3 2000
Elapsed time: 2379933 µs = 2379 ms
Average time: 56 µs (per allocation + deallocation)
15.RAM_0:> membench-bernd_afa_os3 5000
Elapsed time: 6028652 µs = 6028 ms
Average time: 57 µs (per allocation + deallocation)
15.RAM_0:> membench-bernd_afa_os3 10000
Elapsed time: 12075588 µs = 12075 ms
Average time: 57 µs (per allocation + deallocation)

it is still much slower than tlsf. damn, i want the tlsf aware release of mutools!! (and i need to throw all remaining warpos crap down the toilet:P)

Last edited by wawa on 21-Sep-2009 at 05:54 PM.

@wawa

Thanks yep, with tlsf its consistent.

8.dill:bench> membench-bernd_afa_OS3 1000
Elapsed time: 245460 µs = 245 ms
Average time: 11 µs (per allocation + deallocation)
8.dill:bench> membench-bernd_afa_OS3 2000
Elapsed time: 486063 µs = 486 ms
Average time: 11 µs (per allocation + deallocation)
8.dill:bench> membench-bernd_afa_OS3 5000
Elapsed time: 1228521 µs = 1228 ms
Average time: 11 µs (per allocation + deallocation)
8.dill:bench> membench-bernd_afa_OS3 10000
Elapsed time: 2461173 µs = 2461 ms
Average time: 11 µs (per allocation + deallocation)
8.dill:bench> membench-bernd_afa_OS3 50000
Elapsed time: 12155125 µs = 12155 ms
Average time: 11 µs (per allocation + deallocation)
8.dill:bench> membench-bernd_afa_OS3 100000
Elapsed time: 24119190 µs = 24119 ms
Average time: 11 µs (per allocation + deallocation)
8.dill:bench> membench-bernd_afa_OS3 1000000
Elapsed time: 241136363 µs = 241136 ms
Average time: 11 µs (per allocation + deallocation)
8.dill:bench> w39:patch/tlsfmem/tlsfmem
8.dill:bench> membench-bernd_afa_OS3 1000
Elapsed time: 221012 µs = 221 ms
Average time: 10 µs (per allocation + deallocation)
8.dill:bench> membench-bernd_afa_OS3 2000
Elapsed time: 443853 µs = 443 ms
Average time: 10 µs (per allocation + deallocation)
8.dill:bench> membench-bernd_afa_OS3 5000
Elapsed time: 1109797 µs = 1109 ms
Average time: 10 µs (per allocation + deallocation)
8.dill:bench> membench-bernd_afa_OS3 10000
Elapsed time: 2211227 µs = 2211 ms
Average time: 10 µs (per allocation + deallocation)
8.dill:bench> membench-bernd_afa_OS3 50000
Elapsed time: 11035257 µs = 11035 ms
Average time: 10 µs (per allocation + deallocation)
8.dill:bench> membench-bernd_afa_OS3 100000
Elapsed time: 22080445 µs = 22080 ms
Average time: 10 µs (per allocation + deallocation)
8.dill:bench> membench-bernd_afa_OS3 1000000
Elapsed time: 221550640 µs = 221550 ms
Average time: 10 µs (per allocation + deallocation)
8.dill:bench>

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

double

Last edited by mike on 21-Sep-2009 at 06:11 PM.

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

@umisef

What changes did you make to the mac compile?
Would be interesting to run this on linux 68k as well.

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

@bernd_afa

Quote:

@Hypex >Now that we have more reasonable sounding results,

Huh? When did I say this?

Or you just trying to bring me into the conversation?

Okay then, so where is test you want me to modify?

@itix
>Each time when you allocate or deallocate memory Wipeout fills memory block with >0xDEADBEEF (or similar) pattern and checks tracked memory.

wipeout check not every memallac/free memory.there need wipeout check called or a period add so it check all.

I do this amiblitz test.

It alloc mem and overwrite the bound and then alloc another mem and free the other mem.then on trap # 0 come the guru requester and stop the program until press continue.the metrash is not show.only when i click on continue and the freemem a,16 is execute, then the wipeout Hit come.

a.l = AllocMem_(16,0)
Poke.l a+16,4
b.l = AllocMem_(24,0)
FreeMem_ b,24
TRAP #0
FreeMem_ a,16 ; only here the Hit is detect.

so

On my system a wipeout check i use sometimes and for 256 MB mem it take 0,1 sec to check.

i think thats lots too slow to do every alloc/free.

but the fill with illegal values and bound checks should not slowdown all so much.

Have you test on your Peg what the memtest values are when you use wipeout ?

@Hypex
>Huh? When did I say this?

sorry i look again, i mean ChrisH.
I change the last post

Last edited by bernd_afa on 22-Sep-2009 at 05:06 PM.
Last edited by bernd_afa on 22-Sep-2009 at 05:06 PM.