Click Here
home features news forums classifieds faqs links search
5736 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
61 crawler(s) on-line.
 22 guest(s) on-line.
 3 member(s) on-line.


 Trixie,  Fl@sh,  utri007

You are an anonymous user.
Register Now!
 Fl@sh:  1 min ago
 Trixie:  3 mins ago
 utri007:  4 mins ago
 Templario:  5 mins ago
 Kronos:  15 mins ago
 BigD:  26 mins ago
 OlafS25:  28 mins ago
 towo2099:  37 mins ago
 Frank:  42 mins ago
 outrun1978:  1 hr 11 mins ago

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

Goto page ( Previous Page 1 | 2 | 3 | 4 | 5 | 6 )
PosterThread
cv643d 
Re: Interesting memory allocation benchmark
Posted on 28-Sep-2009 16:27:02
#101 ]
Regular Member
Joined: 29-May-2009
Posts: 262
From: Stockholm - Sweden

How about some news of the amitious journey adventure?

Is AmigaOS4 only going to be a hobby OS for 600 MHz machines or is it going to crush OsX soon?

If the plans are to dominate computer scene again, please hurry up, I am 65 years old 30 years from now and want to enjoy next-gen AmigaOS for at least 2 years before I become to old.

 Status: Offline
Profile     Report this post  
umisef 
Re: Interesting memory allocation benchmark
Posted on 28-Sep-2009 16:55:13
#102 ]
Super Member
Joined: 19-Jun-2005
Posts: 1673
From: Melbourne, Australia

@Tomppeli

Quote:
But I got random values like 4 thousand million


I.e. something damn close to 2 to the power of 32.

Which means that what you got was a negative signed number, which was then treated as a positive, unsigned number.
Did you actually get that number back straight from GetSysTime? Or did you run into problems when calculating something like "double time=0.000001*(end.Microseconds-start.Microseconds)+end.Seconds-start.Seconds"? The latter makes perfect sense, and could be cured by casting the parenthesized expression to a signed int before converting it to double.

Quote:
So falsely working GetSysTime explains Fab's results (which are then false of course).


No, it does not. Fab did not get results of 4 billion microseconds, which would be the case if you wanted to attribute his (very self-consistent) results to some random underflow in some system function.

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

@umisef

Quote:
I.e. something damn close to 2 to the power of 32.
Which means that what you got was a negative signed number, which was then treated as a positive, unsigned number.

Might be. Actually I don't remember I changed my program so many times. And casting in C is sometimes ...

@Fab

Quote:
the results i got perfectly matched the actual spent time

Ok. Maybe I had some casting mistake (or one really old mistake . (I shouldn't do these things too late at night and too tired.) I have to check it and test more some other time.

_________________
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  
mike 
Re: Interesting memory allocation benchmark
Posted on 29-Sep-2009 11:56:28
#104 ]
Regular Member
Joined: 31-Jul-2007
Posts: 406
From: Alpha Centauri

Linux 68k test, and aos ixemu 48.

mike@nellyphant:~/bench$ cat test-lns
# linux 2.6.28 :S
3000000 iterations: Elapsed time: 16955796 us (16.955796 s), 5.651932 us per
3000000 iterations: Elapsed time: 47125710 us (47.125710 s), 15.708570 us per

# linux 2.4.27
3000000 iterations: Elapsed time: 16660098 us (16.660098 s), 5.553366 us per
3000000 iterations: Elapsed time: 40004353 us (40.004353 s), 13.334784 us per

# -m68060
3000000 iterations: Elapsed time: 17691437 us (17.691437 s), 5.897146 us per
3000000 iterations: Elapsed time: 41173514 us (41.173514 s), 13.724505 us per
# -O3 -m68060
3000000 iterations: Elapsed time: 15150191 us (15.150191 s), 5.050064 us per
3000000 iterations: Elapsed time: 38516446 us (38.516446 s), 12.838815 us per

# Amigaos ixemul -O3 -m68060
8.gnunix:bench> amemtest2-ix-aos 40960 1 3000000
3000000 iterations: Elapsed time: 32159685 us (32.159685 s), 10.719895 us per
8.gnunix:bench> amemtest2-ix-aos 40960 100 3000000
3000000 iterations: Elapsed time: 40088275 us (40.088275 s), 13.362758 us per

_________________
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 29-Sep-2009 12:47:22
#105 ]
Cult Member
Joined: 14-Apr-2006
Posts: 829
From: Unknown

@Tomppeli
>As long as there's not full memory protection in the system buggy apps >forces the end user to reboot frequently enough so memory >fragmentation doesn't matter.

when you have run all programs you use, always with memtracker and dont use programs that do enforcer or wipeout Hits (report them always to fix), then AOS not crash and you can use it a long time.At least for 68k i know it.

have memprotection is maybe a safety that no reboot is need, but program data is lost.I use also some windows programs, they run also stable, so memory protect do most time nothing.

the first goal is write programs that dont crash and have good tools to find bugs as soon as possible.

and this can avoid when all programs are use with memtracker as wipeout.then can see soon a Bug in a program.

I know this do some slowdown, so thats a big reason that i dont want such a slow MOS or OS4 system and i use as soon as possible a X86 with fast ram, so the slowdown is not so much.

when i see the speed values of MOS with wipeout, (that seem 20* slower as my winuae)i think MOS or OS4 devs or betatester use very selden memtracker tools when they develop programs.Is that right ?.when i think about that wipeout slow down my winuae system 4* more, then i think its unuable slow, because a action that is increase thru wipeout on winuae system from 1 sec to 8 sec ist then slowdown 8*4= 32 sec.

The OS4 grim reaper or a full memoryprotect does not help anything, because mem is only alloc in 4 kb pages and only if a page bound is overwritten and the page is free, then it give a alert.but most errors happen that few bytes after or before a address are overwrite.

because of the C++ problem, its more usefull to have a faster wipeout.

Last edited by bernd_afa on 29-Sep-2009 at 12:49 PM.

 Status: Offline
Profile     Report this post  
bernd_afa 
Re: Interesting memory allocation benchmark
Posted on 29-Sep-2009 13:25:22
#106 ]
Cult Member
Joined: 14-Apr-2006
Posts: 829
From: Unknown

>Linux 68k test, and aos ixemu 48.

If you like you can try with ixemul V61.then the bench is about 5* faster

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

@thread

I made a simple and stupid mistake last time so there's no problems with GetSysTime().

Some results with my own test program (A1SE 750CXe-600MHz, AmigaOS 4.1, gcc 4.2.4):
"Bigger" rounds + "smaller" rounds + mem alloc in bytes = total alloc secs + total dealloc secs
100 * 1000, 1024 bytes = 0.317 s + 0.166 s
100 * 400, 4096 bytes = 0.136 s + 0.107 s
1 * 20000, 8192 bytes = 0.068 s + 0.762 s
1 * 10000, 16384 bytes = 0.369 s + 0.685 s

"Benchmark" tests usually "abuses" the system so they are not necessarily related to any real world apps.

_________________
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  
mike 
Re: Interesting memory allocation benchmark
Posted on 19-Nov-2009 16:26:10
#108 ]
Regular Member
Joined: 31-Jul-2007
Posts: 406
From: Alpha Centauri

@umisef

./membenchosxppc 40960 1 3000000
3000000 iterations: Elapsed time: 14016424 us (14.016424 s), 4.672141 us per
./membenchosxppc-gcc4.0 40960 1 3000000
3000000 iterations: Elapsed time: 13987690 us (13.987690 s), 4.662563 us per
./membenchosxppc 40960 1 3000000
3000000 iterations: Elapsed time: 14243231 us (14.243231 s), 4.747744 us per
./membenchosxppc 40960 1 3000000
3000000 iterations: Elapsed time: 14181801 us (14.181801 s), 4.727267 us per
./membenchosxppc 40960 1 3000000
3000000 iterations: Elapsed time: 14243231 us (14.243231 s), 4.747744 us per
./membenchosxppc-gcc4.0 40960 1 3000000
3000000 iterations: Elapsed time: 13998746 us (13.998746 s), 4.666249 us per
./membenchosxppc-gcc4.0 40960 1 3000000
3000000 iterations: Elapsed time: 14036767 us (14.036767 s), 4.678922 us per

_________________
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  
thinkchip 
Re: Interesting memory allocation benchmark
Posted on 17-Dec-2009 3:40:50
#109 ]
Super Member
Joined: 26-Mar-2004
Posts: 1134
From: Salt Lake City, Utah, USA

@Fab

This seems like a serious problem, but it just sort of petered out. It looks like the consensus was that the benchmarks used didn't reflect real-world applications. So the question is, does the new memory allocation system slow the Amiga down a lot and if so how much. Does this make AmigaOS-based machines significantly slower than the competition (MorphOS)?

_________________
X5000 / AmigaOne 500(OS4.1 FE) / microA1(OS4.1 FE) / Cubic IDE / Imagine / Blender
Lightwave 2019 / Microsoft Visual C++

 Status: Offline
Profile     Report this post  
ChrisH 
Re: Interesting memory allocation benchmark
Posted on 17-Dec-2009 9:29:43
#110 ]
Elite Member
Joined: 30-Jan-2005
Posts: 6673
From: Unknown

@thinkchip Quote:
Does this make AmigaOS-based machines significantly slower than the competition (MorphOS)?

In general I suspect the answer is NO, although you could no doubt find exceptions.

Quote:
This seems like a serious problem,

Naaah, it's all a storm in the tea cup, because I expect it will be fixed sooner or later (as must be some sort of bug).

Quote:
does the new memory allocation system slow the Amiga down

The new Slab allocator should be *faster* than MorphOS's TLSF allocator in general (even if only by a constant amount in the worst case). And both allocators should be far faster than OS3's allocator.

_________________
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  
itix 
Re: Interesting memory allocation benchmark
Posted on 17-Dec-2009 10:55:39
#111 ]
Elite Member
Joined: 22-Dec-2004
Posts: 3398
From: Freedom world

My Amiga 500 running 68000 at 7MHz never felt slow. I guess we can say new memory systems seen on OS4 and MorphOS are only waste of time

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

 Status: Offline
Profile     Report this post  
Fab 
Re: Interesting memory allocation benchmark
Posted on 17-Dec-2009 13:15:51
#112 ]
Super Member
Joined: 17-Mar-2004
Posts: 1178
From: Unknown

@ChrisH

Except this SLAB allocator still relies on some lower level allocator, which probably is the abnormally slow part here.

SLAB itself is only beneficial if it's used (i.e for system objects via AllocSys/DOSObject() or so). But what about normal applications that just need regular allocations through AllocMem (or say malloc for ports. How is malloc implemented?).

 Status: Offline
Profile     Report this post  
ChrisH 
Re: Interesting memory allocation benchmark
Posted on 17-Dec-2009 17:21:30
#113 ]
Elite Member
Joined: 30-Jan-2005
Posts: 6673
From: Unknown

@Fab Quote:
Except this SLAB allocator still relies on some lower level allocator, which probably is the abnormally slow part here.

Technically speaking that "lower level allocator" is still part of the Slab allocator (or at least modern implementations of it - see VMem). But I agree with what you were trying to say.

Quote:
SLAB itself is only beneficial if it's used (i.e for system objects via AllocSys/DOSObject() or so).

No, the Slab allocator benefits all (non-large) allocations. You seem to think that it's Object Cache is all there is to the Slab allocator, which is wrong!

Last edited by ChrisH on 17-Dec-2009 at 05:21 PM.

_________________
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  
kamelito 
Re: Interesting memory allocation benchmark
Posted on 21-Jun-2012 18:50:50
#114 ]
Cult Member
Joined: 26-Jul-2004
Posts: 725
From: Unknown

is there any updated memory benchmark out there?

Thanks
Kamel

 Status: Offline
Profile     Report this post  
NutsAboutAmiga 
Re: Interesting memory allocation benchmark
Posted on 21-Jun-2012 21:03:34
#115 ]
Elite Member
Joined: 9-Jun-2004
Posts: 11328
From: Norway

@kamelit0

Not until the next OS update.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

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

[ 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