Moo Bunny Amiga - last 27 messages of thread "Unknown French guy destroying Peg2 video"

Unknown French guy destroying Peg2 video

Page [1]   2
Direct link to this message

Re: Unknown French guy destroying Peg2 video

Crisot. crisot@benchmark.yop.

82.121.243.23
My benchmark speed is not affected by the os it is running on. It is a simple loop written 100% assemly. The only think done by os is "getsystime". Maybe this affect the speed 1% ? The benchmark runs somethink like 20 seconds, so a 0.001 microsecond "getsystime" wont change results that much.

About rams... On Aone I got 330 MB/sec on 32 bits write and 710 MB/sec on 64 bits write. My ram is noname... A benchmark with ECC registered ram give me 360 / 660 instead of 330 / 710.



About "memory verification". I don't do any memory verification. Memory benchmark and memory test is NOT the same think, as verifying memory is slow (so bad way to benchmark).

Anyway I think (?) chances to get errors are near NULL... If a benchmark got errors, it mean any application running should have errors too... This means a computer crashing every 2 minutes. It's not the case of Pegasos or Aone I think . ?



About Os 4 executable size... Yeah, Os 4 SDK generate big executable. Don't know why . ??? Be sure the command used to compile the test was EXACTELY the same for Os 4 or MorphOs (gcc test.c -otest -o3 , somethink like that)

BTW the MorphOs version was not compiled by me but by Fabien Coeurjoli, the guy who compiled MameMos... He is not stupid ;)

Reply to this
Direct link to this message

Re: Unknown French guy destroying Peg2 video

itix. ilkleht@isoveli.org.

130.234.189.82
On Tuesday, Apr 27, 2004, Crisot wrote:
> My benchmark speed is not affected by the os it is running on. It is a
 > simple loop written 100% assemly. The only think done by os is
Although you seem to call Disable() there is still Quark running.

> About Os 4 executable size... Yeah, Os 4 SDK generate big executable. Don't
 > know why . ??? Be sure the command used to compile the test was EXACTELY
 > the same for Os 4 or MorphOs (gcc test.c -otest -o3 , somethink like that)
 >
 > BTW the MorphOs version was not compiled by me but by Fabien Coeurjoli, the
 > guy who compiled MameMos... He is not stupid ;)
He probably stripped binary and you didnt. It is not really important. But you are also using different compilers. OS4 SDK defaults to GCC 3 when MOS SDK provides only GCC 2.

Reply to this
Direct link to this message

Re: Unknown French guy destroying Peg2 video

Crisot. crisot@gcc.gcc.

82.121.243.23
Os 4 SDK generate big executable any way you compile it.

About compiler... We both used GCC 2.95. GCC 3 is, I think, buggy... (any version... linux, os4 ...)

Reply to this
Direct link to this message

Re: Unknown French guy destroying Peg2 video

Nate Downes. not telling.

68.154.100.223
On Tuesday, Apr 27, 2004, Crisot wrote:
> Os 4 SDK generate big executable any way you compile it.
>
> About compiler... We both used GCC 2.95. GCC 3 is, I think, buggy... (any
> version... linux, os4 ...)
>
But which version of GCC 2.95? There are varying "flavors" of optimization you know. What compile options? Which generators? Which assemblers?

Reply to this
Direct link to this message

Re: Unknown French guy destroying Peg2 video

Johan Rönnblom. jrblom@mtek.chalmers.se.

193.11.251.131
Any test getting 700MB+/s out of either the Peg or the A1 is obviously
faulty somehow, IMO.

Anyway, I'm saying what I always say when this subject pops up: Use
lmbench or some other tested and well debugged program.

Reply to this
Direct link to this message

Re: Unknown French guy destroying Peg2 video

Crisot. Assembler@dev.com.

82.121.243.23

Anyway the compiler used make no difference.

My benchmark is only an inline assembler loop in a very minimal C program (I hate C!!!).

The optimisation level of the compiler only affect C part of the code. (witch is only a simple call to timer.device...)

And about Assembly compilation, the assembler used makes no difference. An assembler only convert "ascii code" into binary CPU instructions. There is no optimisations like in a C pre-compiler. So it is AS, but result is certainly the same with pasm, powerasm, etc...


And AmigaOne G4 reach 711, it's not a fault. Pegasos 2 reach 660 too under linux, witch is quite great.

What prove my soft is ok is when benchmarking cache (L1) (same loop used) I reach the maximum expected by Motorola documentation.



Anyway this become off-topic, my benchmark is now "old" and I am bored having to prove it is ok every week. If pegasos vs aone benchmark hurts you, I'm sorry, it's reality. After years and years of assembly code, after years and years of 3D engine cycle per cycle optimisation, I don't have to prove anything about a so easy software.

Reply to this
Direct link to this message

Re: Unknown French guy destroying Peg2 video

crisot. crisot@truc.com.

82.121.243.23
Sorry, for me every bench coming from linux, compilable on any computer, 100 written in C, is not serious.

Those benchmarks only makes read/write in 32 bits mode, as any good X86 is running fine this way. Not optimal for PowerPc... G4 is able to goes up to 128 bits read/write...

Reply to this
Direct link to this message

Re: Unknown French guy destroying Peg2 video

Nate Downes. not telling.

68.154.100.223
On Wednesday, Apr 28, 2004, Crisot wrote:
>
> Anyway the compiler used make no difference.

You're kidding right?
>
> My benchmark is only an inline assembler loop in a very minimal C program
> (I hate C!!!).

A minimal C program can still speed up/slow down any program.
>
> The optimisation level of the compiler only affect C part of the code.
> (witch is only a simple call to timer.device...)

A simple-call, Um... a call to the timer is the most critical segment of your design here. Any delay here *will* cause your highly-optimized loop to fail.
>
> And about Assembly compilation, the assembler used makes no difference. An
> assembler only convert "ascii code" into binary CPU instructions. There is
> no optimisations like in a C pre-compiler. So it is AS, but result is
> certainly the same with pasm, powerasm, etc...

Actually yes it does. Flags used can modify the output binary code. Only slightly, but it is still modified.
>
>
> And AmigaOne G4 reach 711, it's not a fault. Pegasos 2 reach 660 too under
> linux, witch is quite great.

And what is the data-corruption rate at these speeds?
>
> What prove my soft is ok is when benchmarking cache (L1) (same loop used) I
> reach the maximum expected by Motorola documentation.
>

Then your loop is very wrong, as *noone* should be able to reach the maximum in those documents. That maximum is theoretical maximum only. There is no physical manner to reach the system maximum.
>
>
> Anyway this become off-topic, my benchmark is now "old" and I am bored
> having to prove it is ok every week. If pegasos vs aone benchmark hurts
> you, I'm sorry, it's reality. After years and years of assembly code, after
> years and years of 3D engine cycle per cycle optimisation, I don't have to
> prove anything about a so easy software.
>
No, it's not reality, it is your own fantasty world. We've posted the reality, that your benchmark is worth toilet paper, not even worth the bits you've coded with it. And we've even said way.

As for proving anything, YOU POSTED THE MARKS, YOU PROVE IT OR YOU REMOVE IT. Don't want to prove it, don't want the hassle, then pull the damned marks and can the trash talk. If you can't walk the walk, don't talk the talk. I've discussed the benchmarks I have run for comparison here multiple times, but had noone with an AmigaONE willing to go head-to-head with me on them. They always back out, as if they have something to hide. Based on your chicken-shit attitude here, it seems that they do. A memory iteration loop as a benchmark? give me a break. It showed nothing, absolutely nothing. So either put up or shut up, post something concrete, some code, some firm benchmark possible. As is, you are pathetic.

I don't care which machine is faster, even your measurement gave the A1 a speed benefit of 7% (yes, 7%) in 1 task and 1 task only. Well, how much is a machine doing this 1 task? What about the other few hundred thousand tasks that a platform can do? You want to post a benchmark, you'd better provide a complete one. Don't want to, then don't start the shit.

So, you willing to put up with a real benchmark test? You'd better be sure, the suite I have here is not for the faint of heart. I call it the Torture Chamber.

Reply to this
Direct link to this message

Re: Unknown French guy destroying Peg2 video

Polyhead. polyhead@polyhead.net.

c-24-21-170-178.client.comcast.net
On Tuesday, Apr 27, 2004, crisot wrote:
>
> My benchmark is simple:
>
> Reading/writing a 16 MB memory buffer from "left" to "right", doublewords
> after doublewords (64 bits per 64 bits).
>
> I wrote it on AmigaOne, having no idea neither for AOne nor for Pegasos
> performances.
>
> It is as simple as possible. I can't make it running faster, like I can't
> make it running slower. The only limitation is hardware (memory type, CPU
> bus, etc...)

um and that alone makes it not a proper memory bandwidth test.

Jesus you really are retarded. Were you born, or hatched?

Reply to this
Direct link to this message

Re: Unknown French guy destroying Peg2 video

Polyhead. polyhead@polyhead.net.

c-24-21-170-178.client.comcast.net
On Tuesday, Apr 27, 2004, Crisot wrote:
> Os 4 SDK generate big executable any way you compile it.
>
> About compiler... We both used GCC 2.95. GCC 3 is, I think, buggy... (any
> version... linux, os4 ...)

strange... works here..

i686-pc-linux-gnu-3.3.3

works ok that way, or this way

alpha-ev56-gnu-3.3.3

so it does infact work on linux. haven't had a chance to try it with ppc.

Reply to this
Direct link to this message

Re: Unknown French guy destroying Peg2 video

Polyhead. polyhead@polyhead.net.

c-24-21-170-178.client.comcast.net
> Anyway this become off-topic, my benchmark is now "old" and I am bored
> having to prove it is ok every week. If pegasos vs aone benchmark hurts
> you, I'm sorry, it's reality. After years and years of assembly code, after
> years and years of 3D engine cycle per cycle optimisation, I don't have to
> prove anything about a so easy software.

Well unfortunatly you do have to prove yourself everytime you do something, and when you refuse to provide proof people are going to question your motives. Thats life, and people would be fucking stupid if they didn't call you on it.

Reply to this
Direct link to this message

Re: Unknown French guy destroying Peg2 video

Polyhead. polyhead@polyhead.net.

c-24-21-170-178.client.comcast.net
now now nate, don't taunght him, he may fling poo at you.

Reply to this
Direct link to this message

Re: Unknown French guy destroying Peg2 video

Sigbjørn Skjæret. cisc@c2i.net.

80.203.16.13
On Wednesday, Apr 28, 2004, Crisot wrote:
> And AmigaOne G4 reach 711, it's not a fault. Pegasos 2 reach 660 too under
> linux, witch is quite great.

Hmmm, wait, are you saying you tried it on Linux after all? Why didn't you say so in the first place? ..and is that A1 number from Linux too (with the exact same setup as Peg2)?

What kind of RAM was in the Peg2? That number sounds awfully much like the number you got with ECC Reg RAM on A1...


- CISC

Reply to this
Direct link to this message

Re: Unknown French guy destroying Peg2 video

dammy. damocles@thenostromo.com.

adsli184.cofs.net
On Tuesday, Apr 27, 2004, Crisot wrote:
> BTW.
>
> About Bigfoot, I just forgot him in the readme. Just an error. I said him
> many thanks at the party and he is one of the rarefull morphos teamer I got
> respect for.
>
> Another think. I wrote a program benchmarking Aone and Pegasos, yes... I
> don't want to spread the sources??? Spreading sources was planed to be
> done, but somebody tell me: "please give me sources for me to correct your
> errors"... Now you want sources? fuck off! There are no errors.
>
> The only "error" of my program was to prove how crap Pegasos and Pegasos 2
> hardware are.

How about giving a third party the source? I would love to see how my Edge LE running AROS compares. ;)

Dammy

Reply to this
Direct link to this message

Re: Unknown French guy destroying Peg2 video

tarbos. no@spam.org.

217.187.194.229
On Tuesday, Apr 27, 2004, Crisot wrote:

> I'm author of this video.

> It is a Pegasos 1 G3 / 600 April 2 equiped.

> Be sure it's just fun. The mobo works well. Some water is not stressfull at
 > all for a mobo... I also washed my CyberstormPPC with water and soap some
 > month ago. It's not a problem. I'm still using it.

Hi Crisot,

the cat is sweet and I thought the video to be funny. :-)
It's good to hear no Pegasos has been harmed in the production of the video.
In fact I hear it's quite common to put keyboards into the dish washer to make
them clean again.
Once a bottle of mineral water tumbled and the water went into the venting-slots
of my A1200...it ran for about another 20-30min before it showed adverse effects.
Who knows what Neko's cats do to the Pegasos II boards before they ship from
http://www.pegasos.co.uk/
*g*

Reply to this
Direct link to this message

Re: Unknown French guy destroying Peg2 video

tarbos. no@spam.org.

217.187.194.229
>About Os 4 executable size... Yeah, Os 4 SDK generate big executable. Don't know why . ???
Simple - ELF is a MONSTER!!!
SCNR ;)

Reply to this
Direct link to this message

Re: Unknown French guy destroying Peg2 video

tarbos. no@spam.org.

217.187.194.229
On Wednesday, Apr 28, 2004, Nate Downes wrote:

> And what is the data-corruption rate at these speeds?

The Pegasos has data corruption? :-o

> Then your loop is very wrong, as *noone* should be able to reach the
 > maximum in those documents. That maximum is theoretical maximum only.
> There is no physical manner to reach the system maximum.

Huh, why is that?

> No, it's not reality, it is your own fantasty world. We've posted the
 > reality, that your benchmark is worth toilet paper, not even worth the bits
 > you've coded with it. And we've even said way.

I would like to see a benchmark done "right" by you that shows the Pegasos
to perform faster. As of now I only saw results that make it look slow as a
dog and I'm not willing to accept that. :)

Reply to this
Direct link to this message

Re: Unknown French guy destroying Peg2 video

.... ...@....

194.2.91.222
On Wednesday, Apr 28, 2004, tarbos wrote:
> I would like to see a benchmark done "right" by you that shows the Pegasos
> to perform faster. As of now I only saw results that make it look slow as a
> dog and I'm not willing to accept that. :)

No it's true, both AmigaOnes and Pegasos are slow computers compared to what you can have today on PCs or Macs. That's the reality.

But they are still fast enough for most of people and most of people doesn't even notice the slow memory performances of these computers, AmigaOS and MorphOS helps also to hide this as they feel faster on a Pegasos or AmigaOne G3 600MHz (and I don't speak about AOne/Peg G4 that are even faster) than a Windows or a Linux on a Pentium 4 3GHz ;)

So you have the following choice:

On one side: Slow computer (AOne or Peg) with very fast OS (AmigaOS or MorphOS) but very few software.

On the other side: Very fast computer (PC or Mac) with more "modern" and acceptably fast OS: Windows, Linux or MacOS 9/X (because of the fast HW, it helps for that) with lot of software.

Reply to this
Direct link to this message

Re: Unknown French guy destroying Peg2 video

CRISOT. CRISOT@LAST.COM.

82.121.112.158
@Polyhead.

NO NO NO!!!!!!!!

Assembler used DON'T CHANGE PEPRFORMANCE!!! Have you ever typed a bit of ASM in your life!!!

And about my call to timer.device... The test runs 20 seconds on my AOne!!! I'm sorry, but even a very crap unoptimised call to timer.device wont exced a couple of cycles!



This becomes ridiculous. Was my last post anyway, I can't learn you everything you need to understand something.





Tests where done from Os 4 and MorphOs 1.4.2.. The "Linux" tests for Pegasos 2 were done only once to get same memory configuration as Os 4.

Reply to this
Direct link to this message

Re: Unknown French guy destroying Peg2 video

crisot. crisot@verylast.precision.

82.121.112.158
And motorola documentation value are OK!!! Not theorical!

You can reachit with an assembly optimised loop, because CPU speed/performance is something EXACT, not approximate.

Just have a look at a DNETC client. The SAME PowerPC give EXACTELY same performances from a X computer under Os Y and a Z computer under Os ZZ. Why? Because ASM/machine/os USED DOES NOT CHANGE RESULTS!



But of course poor C program can't reach it, because they are depending of very very crap Compiler optimisation... Anyway C compiler are not able to use every PPC advanced functions.


That's boring, boring boring... People are having doubt on technical part of a soft and most are maybe unable to compile a hello world, and sure have never compiled any ASM.

Reply to this
Direct link to this message

Re: Unknown French guy destroying Peg2 video

John Block. jb@jb.

80.14.232.59
On Wednesday, Apr 28, 2004, CRISOT wrote:
>
> Tests where done from Os 4 and MorphOs 1.4.2.. The "Linux" tests for
> Pegasos 2 were done only once to get same memory configuration as Os 4.
>

So this means OS4 uses Linux code to configure the memory. Yet another creative usage of the GPL by Hyperion.

Reply to this
Direct link to this message

Re: Unknown French guy destroying Peg2 video

pixie. ncosta@esec.pt.

proxy.esec.pt
On Wednesday, Apr 28, 2004, John Block wrote:

>
> So this means OS4 uses Linux code to configure the memory. Yet another
> creative usage of the GPL by Hyperion.
>

Another conspiracy theory against hyperion?

pixie- writing from a paradise called Portugal

Reply to this
Direct link to this message

Re: Unknown French guy destroying Peg2 video

Nate Downes. not telling.

68.154.100.223
On Wednesday, Apr 28, 2004, tarbos wrote:
> On Wednesday, Apr 28, 2004, Nate Downes wrote:
>
> > And what is the data-corruption rate at these speeds?
>
> The Pegasos has data corruption? :-o

Every machine will corrupt data. You'll loose a TCP packet. You'll suffer a cache miss. You'll hit line noise. All of these things can and do corrupt data. They also are checked for by the OS as it is operating, in order to eliminate the chance of the "oops" from affecting your stability.
>
> > Then your loop is very wrong, as *noone* should be able to reach the
> > maximum in those documents. That maximum is theoretical maximum only.
> > There is no physical manner to reach the system maximum.
>
> Huh, why is that?

Because there are factors that will step into play. The OS's task-swapper will periodically "peek" in, which will stall a pipe. Other tasks will poll the resource pool, which will stall it as well. Interrupts, DMA, caches, these things exist and are operating in a real-world system. Each will cause some delay in any single-task.

Imagine a highway. In theory, a single car can drive 200mph down that highway. Now, let's throw some other cars onto the highway. Maybe some construction. A police speedtrap. You won't go 200mph anymore.
>
> > No, it's not reality, it is your own fantasty world. We've posted the
> > reality, that your benchmark is worth toilet paper, not even worth the bits
> > you've coded with it. And we've even said way.
>
> I would like to see a benchmark done "right" by you that shows the Pegasos
> to perform faster. As of now I only saw results that make it look slow as a
> dog and I'm not willing to accept that. :)
>
I have the benchmark suite compiled into a deb around here somewhere. I'll get it onto my website later this week for you all to try.

Reply to this
Direct link to this message

Re: Unknown French guy destroying Peg2 video

Nate Downes. not telling.

68.154.100.223
On Wednesday, Apr 28, 2004, CRISOT wrote:
> @Polyhead.
>
> NO NO NO!!!!!!!!
>
> Assembler used DON'T CHANGE PEPRFORMANCE!!! Have you ever typed a bit of
> ASM in your life!!!
>
> And about my call to timer.device... The test runs 20 seconds on my AOne!!!
> I'm sorry, but even a very crap unoptimised call to timer.device wont exced
> a couple of cycles!
>

A couple of cycles on a benchmark is a couple too much. When you're talking a difference of *7%*, an unoptimized element *anywhere* can account for that difference. You claim to know programming, yet you are ignoring this simple fact that unoptimized calls will consume 10-20% of any application. Shoot, I have seen programs that will spend 90% of their time in an unoptimized C loop that does only 1% of the programs work.
>
>
> This becomes ridiculous. Was my last post anyway, I can't learn you
> everything you need to understand something.
>
>
>
>
>
> Tests where done from Os 4 and MorphOs 1.4.2.. The "Linux" tests for
> Pegasos 2 were done only once to get same memory configuration as Os 4.
>
You seem to lack understanding. You're claiming validity for some fantasy figures you are spouting out. We're calling your bluff. Put up or shut up.

Reply to this
Direct link to this message

Re: Unknown French guy destroying Peg2 video

crisot. bla.

82.121.112.158

*** QUOTE ***
A couple of cycles on a benchmark is a couple too much.
***

...

Damn, you suxx, you suxx, you suxx!!!!!!!

How can ONE call make a 20 seconds benchmark false??? The difference is somethink like 0.0000001%, not "7%" !!!!!

IF A CALL TO YOUR TIMER.DEVICE IS THAT LONG, CHANGE YOUR DEVICE, OR LEARN TO CODE!!!



Ho please all, shut up, shut up shut up!!! Your all poor lame fuckers, FUCKERS, FUCKERS!!!!!!!! FFFFUUUUUUUUUCCCCCCCKKKKKKKKKEEEEERRRRRRRRRRSSSSSS!!!!!!




Please, please, shut up, don't try to attack somethink that can't be defeated. This will hurt your poor fucked ass.

Reply to this
Direct link to this message

Re: Unknown French guy destroying Peg2 video

Nate Downes. not telling.

68.154.100.223
Egads, grow a backbone.

Reply to this
Direct link to this message

Re: Unknown French guy destroying Peg2 video

Sigbjørn Skjæret. cisc@c2i.net.

80.203.16.13
On Wednesday, Apr 28, 2004, crisot wrote:
> You can reachit with an assembly optimised loop, because CPU
> speed/performance is something EXACT, not approximate.

If it was something exact (constant), wouldn't the results be constant too?

> Just have a look at a DNETC client. The SAME PowerPC give EXACTELY same
> performances from a X computer under Os Y and a Z computer under Os ZZ.
> Why? Because ASM/machine/os USED DOES NOT CHANGE RESULTS!

So how does that correspond with your previous statement:

"Tests where done from Os 4 and MorphOs 1.4.2.. The "Linux" tests for Pegasos 2 were done only once to get same memory configuration as Os 4."

Obviously machine/os *can* change results .. moreover you are completely ignoring the fact that they *are not* running the same PPC chip (something which *will* affect performance of the *exact same* asm), and they don't even have the same cachesize/levels .. even when you least expect it (esp. if you haven't read the whitepapers on the particular chips in question to see how their caches behave in various modes) things may/may not get cached...

..it's interesting though, through the course of this thread you have gone from saying that Pegasos is complete and utter crap and that A1 rules the world to saying that maybe Pegasos isn't that bad after all, yet you blow a fuse when people try to tell you that maybe your benchmark isn't benchmarking quite what you think it is benchmarking (even though this was already proven and admitted by you earlier by saying the results differ on Linux) .. maybe it's time you take a breather and try to figure out the reasons for this, or drop it alltogether (maybe the world isn't ready for Yet Another Benchmark)?


- CISC

Reply to this
Page [1]   2

Short list view

Previous thread - Next thread

Back to Moo Bunny

It is now: 21:53:47 GMT.
Message boards:
[General Stuff (21:49:20)] [Amiga Section (21:48:55)] [Sarah McLachlan Stuff (n/a)] [Cabinet of Curiosities section (Jan 13)] [WalkingFish (Apr 15)] [radiographite: art by js (Mar 1)]
More message boards:
[Macintosh Section (Tuesday)] [Space Section (Tuesday)] [Portland Section (Monday)] [Anime Section (Tuesday)]
Other pages
[Squid's Amiga Page & Rumor Mill (n/a)] [radiographite (Feb 25)] [Guestbook (n/a)]

[John's Homepage] [Sarah McLachlan Stuff] [Cabinet of Curiosities] [Squidprojects]
[About John] [John's Art] [Email John] [Guestbook] [Message Board]