has anyone written a spin program to show prop speed??? For Benchmarking ????

mikediv

Hi guys I checked the Obex I have been over driving my prop chips but the only way I have been able to see performance gains is with my oscilloscope, has anyone written a utility program that would show the prop running any kind of benchmarks? I
would like to actually see if the prop chip is really speeding up visually.

I have been increasing the voltage to the prop chip and we have some left over liquid nitrogen from a project I was working on , so we have cranked up the volts pretty high but its not a lot of fun to just watch an oscilloscope
There was a thread a while back I can not find and I thought some of you guys had a program ??
Thanks

Clock Loop

This could be done with a program that reads a pin as fast as it can.

When you increase the clock speed of the prop, your sample cycle time will decrease,
which will let you get shorter timing between samples, which means more samples per second.


So I could write a spin program that read the state of 20 pins all sequentially (using only 1 cog)

Then output the cycle time to a terminal, record the results.

Not only will the overall time it takes to read 20 pins decrease,
but the timing it takes between the reading of each pin will also decrease.

Benchmarks are nothing more than the relationship between time and completed cycles.



A PROPER benchmark would actually be a BURNIN program that activated as many features as possible on the prop and ran them constantly.

Mike Green

There's no benchmark program, partly because there really isn't anything like a general purpose benchmark. It depends on what you're trying to test, what sort of applications you're working with and what sort of resources they might need. For example, if you need floating point for your application, you need to have a benchmark that includes it as part of the test, particularly because the Propeller doesn't have built-in floating point and a floating point benchmark doesn't accurately reflect the capabilities of the Propeller for non-floating point applications.

RossH

I wrote a trivial fibonacci progtam to compare C and SPIN. But Fibonacci is not a good general purpose benchmark because it consists almost entirely of pure recursive function calls (with one integer addition operation). On the Prop, recursive function calls are REALLY EXPENSIVE due to the architecture, and do not truly reflect the overall general speed of the CPU - this particular benchmark was designed to test the efficiency of various language implementations, not the speed of the Prop itself. See the Catalina 2.1 thread for the programs.

But generally, I agree with Mike.

Ross.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Catalina - a FREE C compiler for the Propeller - see Catalina

waltc

Since Spin interpreted the benchmark of say Dhrystone 2.1 will be lousy as can be, it certainly won't be anywhere near a ARM or Coldfire where their compilers actually generate machine code.

Not worth the effort. The PropII may be different in this regard but who knows.

Mike Huselton

I would like to see a PASM test suite. Hmm - I could start with a standard C test suite and hand-translate the equivalent PASM algorithms.

But - apples and oranges anyway. What we really need is a workable code profiling tool to analyze where the most time is taken by inefficient algorithms.
Easiest way is to dedicate a COG and its two counters to profile the other 7 COGs.

Hanno, are you listening? ViewPort + Code Profiling. Prop I and II applicability. I'll write some base code for the profiler and the subroutine START and END timing capture.
Simple stuff, really, if you have written profiling code before - and I have written plenty for customers over the years. I may start a separate thread on this issue.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH

Post Edited (James Michael Huselton) : 10/29/2009 4:57:34 AM GMT

jazzed

If all you care about is *relative* performance between 5MHz to 6MHz _XINFREQ, then *any* test with observable results will do.
Comparing CPUs is of course more difficult especially when one has a completely different programming approach.

Increasing the voltage on the chip does not by itself improve performance and going to high will destroy your chip ... stay within spec.

Mike Huselton

Jazzed,

Code profiling lets you see the results of badly-implemented algorithms and errors in judgement.
This but one of the tools experienced programmers use, as well you know.

Your implied suggestion of heartbeat code and other diagnostic code is very appropriate. We need all of the diagnostics we can handle.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH

jazzed

Of course. Profiling is relevant in that context since the code would of necessity be different between different CPU architectures. It is not something I care to do though since I consider benchmarking in the given micro-controller class nothing more than hair splitting and turd polishing at this point until a larger internal memory footprint is available. I'm not sure how anything I wrote suggests the need for heartbeat or diagnostics ... shrug shoulders.

BradC

I fail to see how you can do any form of benchmarking without an external measuring device or external time source anyway.

I think profiling on microcontrollers is an interesting concept. I don't see the utility of it, but it's an interesting concept.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?

heater

I'm not sure of the point of this benchmarking idea. Mikediv said "not a lot of fun to just watch an oscilloscope" which may be true in this case but then if we had a benchmark or benchmarks then it would just be "not a lot of fun to look at these benchmark numbers." In fact I'd prefer to have the scope output any day.

Given the huge variety of applications and possible implementations, Spin, PASM, C, one COG many COGS and all the trade offs people have to make, speed vs size vs complexity vs ease of use etc etc any benchmark numbers are pretty meaningless. Its very hard to find a benchmark X that will tell you if it is possible to implement function Y in the time limits required. You find out that Y is the benchmark you need[noparse]:)[/noparse]

Profiling can be very useful when you have written a huge pile of code for some application, perhaps in the simplest quickest way yo can, and then want to find out where optimizations may be beneficial. I can't see that it is so helpful on the scale of code we can fit in the Prop. Generally it's small enough to know your way round it all and see where the bottle necks are.


BradC: Why not? If you know your XTAL frequency then you can always measure time in seconds (or whatever) pretty accurately and then compare your Spin, C, PASM whatever execution time against it. No external measuring device required.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

BradC

heater said...

BradC: Why not? If you know your XTAL frequency then you can always measure time in seconds (or whatever) pretty accurately and then compare your Spin, C, PASM whatever execution time against it. No external measuring device required.

The context of the original post was benchmarking for the purpose of overclocking. So you are benchmarking code against varying clock speeds (which is pointless anyway as the execution cycle count won't vary in any case and you can just calculate it out).

Yes, you can use cnt values to compare relative code execution time, but you can't do that when you are varying the clock speed.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
lt's not particularly silly, is it?

heater

Well, I hope the is a linear relation between clock speed and instruction execution rate with the Prop[noparse]:)[/noparse]

Having said that, I bet there are systems our there that add extra wait states for external RAM (say) when the clock speed is increased. Possibly leading to a decrease in performance for some small increases of clock.

As you say benchmarking for the purpose of over clocking is pointless, if it runs at all we already know how fast it will be from a "normal" speed test. The question is does it run at all and is it reliable ? At this point it would be good to have a program that exercises all features of the Prop in all manner of configurations so that we can be sure that all it's transistors are doing their thing correctly and that any extra heat stress does not kill it. Not exactly a "benchmark" perhaps a "benchtest"

I believe Sapieha has been working on this issue with his 120MHz tests.

Presumably Parallax has a suite of test codes that they have used to verify the Propeller logic. Perhaps they'd like to share that with the overclockers?

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
For me, the past is not over yet.

Sapieha

Hi All.

It is more true He talk on same program type as I some time ago - Test program for reliable functioning of Propeller with overckloking.
To one of my test I use 2 Propellers one that RUN in standard frequency and one that are overckloked - and in that configuration I have posiblity to test if overckloked Propeller Run correctly. And have posiblity to calculus some benchmarks for it (If overklocked Prop have stable frequency).

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Nothing is impossible, there are only different degrees of difficulty.
For every stupid question there is at least one intelligent answer.
Don't guess - ask instead.
If you don't ask you won't know.
If your gonna construct something, make it·as simple as·possible yet as versatile as posible.


Sapieha

mikediv

Thanks guys I did write a few little routines to test I/O and I would watch the output on a scope as I increased the clock and the voltage you can see the chip speed up but what I had in mind, Actually I was thinking out load if there was any type of utility
that would show a graphic on a display TV/VGA maybe a little bar graph like measuring bandwidth on a PC . To be honest I Really did not think it through just asked/typed out load. Like I said I had some Liquid Nitrogen leftover and I was just playing.
We ended up driving an old Pentium chip the big giant old ones with the gold pins back then it was just a Pentium 90 into the stratosphere its was amazing the speed you can get. I guess what led me to think about my prop chips is I have over clocked some of them but
I am just doing control applications, driving motors, looking at switches so there is really no reason to bother it was just a spur of the moment thing , BradC you are correct all of you are it was just a thought.
I don't know if any of you remember when the PC and Clones first came out at boot up it would display a little / character in the upper left hand corner that would toggle back and forth if you speed up the computer that little / slash would toggle faster and faster me and my friends became obsessed with over driving are PC's we had no decent software to speak of since we were all CPM nerds so there was really no point but before it all came to an end there would be 9 guys at a computer club meeting all standing around just booting are machines to show how fast that darn Slash would toggle back and forth It was like we were at a drag race LOL looking back its was shocking we ever got any chicks LOL

jazzed

Nothing wrong with thinking out loud ... start worrying when you start answering yourself .... [noparse]:)[/noparse]

We used to keep track of the 16 or so Linux workstations for parallel build farms back in the early 90's. There was an X window widget that we started for each box and it would show the loads. Using "top", it was easy to see who was hogging all the CPU power. We would replace half the servers every time Intel came out with a new speed upgrade about every 6 months. We could use all the power available back then especially with 66MHz 486 boxes for doing builds.

Mike Huselton

Jazzed,

I had no idea you worked with parallel CPU farms back in the 90's.
Great experience, wasn't it? I worked with clusters of RS6000's in the early 90's and switched to Beowulf clusters of PC's. My hat is off to you!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
JMH