Unknown French guy destroying Peg2 video

Re: Unknown French guy destroying Peg2 video

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 "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 . ?

Re: Unknown French guy destroying Peg2 video

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.

Re: Unknown French guy destroying Peg2 video

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?

Re: Unknown French guy destroying Peg2 video

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...

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.

Re: Unknown French guy destroying Peg2 video

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.

Re: Unknown French guy destroying Peg2 video

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...)

Re: Unknown French guy destroying Peg2 video

> 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.

Re: Unknown French guy destroying Peg2 video

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. ;)

Re: Unknown French guy destroying Peg2 video

> 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 fromhttp://www.pegasos.co.uk/
*g*

Re: Unknown French guy destroying Peg2 video

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.

Re: Unknown French guy destroying Peg2 video

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.

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.

Re: Unknown French guy destroying Peg2 video

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.

Re: Unknown French guy destroying Peg2 video

Re: Unknown French guy destroying Peg2 video

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)?