Speed test

J

jmumby

Senior Member
Hello,

I'm wonder what the boffins would do to compare speeds between a 28x1@16Mhz and an Arduino Diecimila. I have written a GPS logger program for each that gets GPS data and writes it to a uSD card but this relies more on the speed of the GPS and card writer and Im not really getting much of a speed difference.

Something a bit real world I guess.

Cheers.
 
D

Dippy

Moderator
You've probably answered your own question.

I have none of the chips you have, but it's fairly obvious that if you have serial 'bottlenecks' occupying most of your code then their 'slowness' will dominate the test.
e.g. if you had a short code which said serin...serout...goto start then the slow serial stuff would limit your speed. (In this example you can replace 'serin/serout' with any comms command. The principle is the same.)
 
J

jmumby

Senior Member
I know why the test I did was not a particulary good one.

This is why I was asking if someone had a better theory to test the speed difference other than my poorly executed example.
 
D

Dippy

Moderator
Well why not just have repetitive calcs in various size loops? Add in some subroutine call and returns too?
Personally I would try some code that reflects your uses and chuck it in big loops and time it. Leave out any comms stuff and leave out any stuff that can't be done on a like-for-like basis.

You could compare FOR/NEXTs against Repeat/Untils.

I've never used Arduino so there may be some functions that replace PICAXE Basic multi-line functions. Put that in loops and try it.
Sure someone can knock you up some code, but surely you can do this yourself?
Maybe some LCD writing too if applicable...
 
hippy

hippy

Ex-Staff (retired)
A 4GHz quad-core PC isn't really quicker than a PICAXE when it comes to typing on a keyboard and sending that out a serial port. The only advantage comes in being able to do a lot more between key presses while keeping up with the rate of typing. If a PICAXE can do the job required it's as good as anything else.

There's a tendency to think that just because a micro isn't running interpreted it will automatically be a lot faster and that's usually never true, even when not slowed down by real-world interfacing. For example; to do a multiply, the PICAXE has to pull that instruction out of program memory, get the data to multiply and call a routine to do the multiplication. The Arduino is exactly the same, and the code it executes will almost certainly be comparable to what the PICAXE executes. So prima-facie, no gain at all.

Where the PICAXE loses is in extracting the multiply instruction, the info which say where the data to use is and in dispatching execution to the multiply routine. Because the PICAXE code is tokenised and not optimally aligned this takes consderable time, it's the only real bottleneck in the PICAXE. An Arduino has much lower overhead.

This bottleneck has more impact for setting I/O high and low etc; the PICAXE still has the overhead it does for multiply above but the Arduino is able to do this with almost no overhead at all.

So how does one come up with a comparison of a PICAXE and Arduino or any other micro ? Not easily. When I tested whether man was faster than a car, I found man was much quicker, but that comes down to the test - I can get to the corner of my street quicker than it takes to jump in a car, start it and drive to the same point.

The Arduino will always be somewhat faster than a PICAXE ( it has minimal instruction execution overhead ) and when instruction execution overhead takes longer than 'just doing it', the Arduino will be a lot faster. But most real-world programs don't use commands which favour the Arduino so that advantage can be quickly lost. The problem is in defining anything which is real-world.

It's the same in the PC world; a 286 was nearly as good at word-processing as the latest dual-cores are which are something like 1,000 times faster but I know which I'd use for 3D image rendering. Many people use very low-end PC's as internet routers and the like because packets only turn up rarely so their latency in handling that data isn't usually a problem, for anyone with high bandwidth needs though it would be a ridiculous choice.

Hence benchmarking is usually done across a whole range of different applications to easure raw maximum performance and more real world applications, especially using benchmarks which reflect what the product is aimed towards. The only reason to put a super-computer into a set of traffic lights rather than a PICAXE is if it's cheaper or easier to use or you want to do more than just switch the lights and handle button pushes. Any speed gains are otherwise irrelevant.
 
R

RexLan

Senior Member
A little of subject but could I please know what GPS module you are using, the refresh rate of the module (1 Hz) and an exact sample of the snetenances you actually receive from the module ... not modified.

We are working on a similiar project and have some concern about the sentenance character length in the NMEA sentemnances. Some manufactures say teh fields are "varilable" length and others do not. While all of them are seperated with teh coma, it is the actual field length I am concerned with the properly receive it with the Picaxe.

I am using a Trimble module and find that in the RMC sentenance teh filed lengths are constant and padded with zero. For example the speed may be reported as 0103 knots or 1033 knots, but always with 4 digits.
 
J

jmumby

Senior Member
My GPS is a EM-406a and the strings are variable length - no padding.

The Arduino is probably quicker but that would because it is programmed at a lower level than The Picaxe. Out of interest I would like to compare the difference between the two and speed would seem to be a resonable comparison.

Being the fastest doesn't neccesary mean one is better than the other and as mentioned development time can be a factor. I can get a GPS logger knocked out in couple of hours on the picaxe where as the arduino it has taken me a week of tinkering to get a similar result.

At the end of the day we have two 28 pin micros running at 16Mhz. The question is which is best not which is fastest.
 
D

demonicpicaxeguy

Senior Member
jmumby said:
At the end of the day we have two 28 pin micros running at 16Mhz. The question is which is best not which is fastest.
Click to expand...
the answer is not nessarily which is the best micro ,it should be which micro is better suited for the job at hand, with the required capabilities and functions
at the end of the debate it matters not what the answer is if the person writing the program that the micro has to run hasn't got a clue what they are doing or they write somthing that isn't as effeciient as it otherwise could be
 
hippy

hippy

Ex-Staff (retired)
jmumby said:
At the end of the day we have two 28 pin micros running at 16Mhz. The question is which is best not which is fastest.
Click to expand...
That goes back to what the specific task is and how anyone measures "best".

One big advantage I see to the PICAXE which moves it up the 'best' ladder is that it can be connected to a PC serial port using nothing but a resistor. One breadboard, one PICAXE, one resistor and a couple of batteries and you can be using a PICAXE. One cannot get much cheaper than that. For the Arduino and most other micro's, one either has to buy a board ready built or assemble a whole load of components to make it do anything.
 
J

jmumby

Senior Member
One big advantage I see to the PICAXE which moves it up the 'best' ladder is that it can be connected to a PC serial port using nothing but a resistor. One breadboard, one PICAXE, one resistor and a couple of batteries and you can be using a PICAXE. One cannot get much cheaper than that. For the Arduino and most other micro's, one either has to buy a board ready built or assemble a whole load of components to make it do anything.
Click to expand...
Beg to differ on that one.

http://itp.nyu.edu/physcomp/images/tutorials/Arduino-USB-BB-10.jpg
http://www.arduino.cc/en/Main/Standalone

Can also be programmed via ICSP cable which wouldn't be much harder to make than a picaxe one.

Anyhue this isn't a picaxe beat up! All I wanted to know was what would be a good method to compare the speeds of the two. From what I gather this is mathmatical calculations.

When it comes down to it there are heaps of picaxe chips as opposed to Arduino's 1 which is overkill and overly exspensive for most projects. 90% of my playtime has been on the 18x which is an amazeing little chip.

I get the feeling that everyone thinks Im saying one is better than the other when all I was asking is what would be a good method to test each. Much the same as they test and compare Nvidia and ATI, Intel and AMD, chevy and ford, mitsubishi and subaru.......
 
B

BCJKiwi

Senior Member
The answer is the same as it is for all those other tests referred to. They test what they test. For gamers they test a selection of games. For CAD they test CAD programs etc etc. One graphics card may be better on one game, the other on a different game. A 4WD is different from a Ferrari but both will take a similar amount of time from home to the office in rush hour.

So the application has to be decided on. The test has to be designed for the application, then there is a result for those specific conditions.

So if there is an app for processing GPS input, then the test is to run the code in each chip against the GPS. If the answer is they are the same (because of the interfacing issues then that is the answer).

Have found programming plays a huge part in most performance issues.
Have a 28X1 at 16MHz doing multiple inputs, i2c in/outs and data logging. (1600 lines / 3500 bytes including IR driven configuration routines). Ran numerous tests on different logic methods, use of eeprom/scratchpad, honed the logic and coding and reduced cycle time by a factor of 5 over the original code (that wouldn't fit in the 4096 anyway without the configuration routines). Also found that changing the i2c bus speed from 100 to 400 made almost no difference to the overall cycle time.
 
D

Dippy

Moderator
jumumby, why don't you just try something?
Set yourself some benchmark tests which you can do on both.

All those 'benchmark' tests you see on processors test the chip functions repeatedly allowing the user to see which chip is 'best' in certain aspects, whether it be maths or whatever.
Why the reluctance to try something even its a loop 0 to 65000 adding up a few numbers? (You said ealrier you wanted to ignore i/o).

Here's one comparison for you;
Task: FFT spectrum calculation using 256 sample data points.
1. PIC18F2520 @10MHz +PLL using EEPROM for variable array. Took 37 seconds.
2. Same as above using FRAM. Took 12 seconds.
3. dsPIC flat out with enough on-board memory for array. Took 0.75 seconds.

Completely irrelevant to you but shows the differences.

I really don't know what you are expecting other to tell you?
Why don't you propose a bit of code and see what others think?

BCJ: I found the same. In the above tests I tried 100 and 400 for bus speed and the difference was piffling for EEPROM and FRAM. And it was doing thousands of i/o. The memory was to store hundreds of numbers in a pseudo array.
I wouldn't even worry about it. The 'bottleneck' was the overhad code as much as the data rate. I guess it'll have a more significant effect if moving larger blocks of data. I was only shifting 8 bytes at a time.
And I totally agree that twiddling, sorry, optimising your code can have a huge effect.
 
J

jmumby

Senior Member
Well, it seems the serial speed may not have been as much of a factor as I suspected.

Using both the same baud and hardware the Picaxe was about 50% faster. The Arduino captured 27 samples in 60 secobds where as the Picaxe managed 49.

I had to use the hersin for the 28x1 as the string was too large for the usual memory and I would have to take two chucks which would be inaccurate. Quite unbalanced using the usual memory as well as the Arduino puts all the data into an array so I figured an apples with apples would be more like the hserin at the same baud.

Because the uSD will only write bytewise or in 512byte chucks I have to write the data bytewise which (I) require an ACK (0x06) back to verify the byte is written. This is what slows the process down somewhat.

The string I get is as follows....

GPGLL,x319.35x8,S,x7235.78x9,E,090059.000,A*2D

My code...

Code: 
SETFREQ EM16
SYMBOL GPS_TX = 7
SYMBOL GPS_RX = 0
SYMBOL GPS_BAUD = T4800_16

SYMBOL UDRIVE_RESET = 2
SYMBOL uDrive_TX = 1
SYMBOL uDrive_RX = 4
SYMBOL uDRIVE_BAUD = T4800_16

HSERSETUP B4800_16, %00 'setup hardware serial

GOSUB turn_off_nmea
GOSUB initUdrive
GOSUB setAddress

MAIN:
 for b6 = 0 to 50							'wipe scratchpad
 put b6," "
 next b6
 SEROUT GPS_TX,GPS_BAUD,("$PSRF103,01,01,00,01*24",CR,LF)
 HSERIN [1000,readout],0,126,("$")
 GOTO MAIN

ReadOut:
 FOR b20 = 0 to 50								
 GET b20, b1								'get byte from scratchpad
 SERTXD (B1)								'send byte to screen
 SEROUT uDrive_TX,uDRIVE_BAUD,(0x40,0x77,B1)			'send byte to uSD								'send byte to screen	
 SERIN uDrive_RX,uDRIVE_BAUD,B1					'wait for ACK
 sertxd(#b1)
 IF B1 != 0x06 THEN ReadOut						'if no ACK start again
 NEXT b20
GOTO MAIN

turn_off_nmea:
 SERTXD("Turning off NMEA strings",CR,LF)
 SEROUT GPS_TX,GPS_BAUD,("$PSRF103,00,00,00,01*24",CR,LF) 'GGA
 SEROUT GPS_TX,GPS_BAUD,("$PSRF103,01,00,00,01*25",CR,LF) 'GLL
 SEROUT GPS_TX,GPS_BAUD,("$PSRF103,02,00,00,01*26",CR,LF) 'GSA
 SEROUT GPS_TX,GPS_BAUD,("$PSRF103,03,00,00,01*27",CR,LF) 'GSV
 SEROUT GPS_TX,GPS_BAUD,("$PSRF103,04,00,00,01*20",CR,LF) 'RMC
 SEROUT GPS_TX,GPS_BAUD,("$PSRF103,05,00,00,01*21",CR,LF) 'VTG
RETURN

initUdrive:					
 LOW UDRIVE_RESET
 WAIT 4
 HIGH UDRIVE_RESET
 WAIT 4									'wait as spec
 SEROUT uDrive_TX,uDRIVE_BAUD,("U")					'send init byte		
 SERIN uDrive_RX,uDRIVE_BAUD,B1					'wait for ACK
 IF B1 != 0x06 THEN initUdrive					'if no ACK start again
 SERTXD ("Drive Initialized",CR,LF)					
RETURN

setAddress:
 SEROUT uDrive_TX,uDRIVE_BAUD,(0x40,0x41,0x00,0x00,0x00,0x00) 'set address to 0
 SERIN uDrive_RX,uDRIVE_BAUD,(B1)					  'wait for ACK	
 IF B1 != 0x06 THEN setAddress					  'if no ACK start again
 SERTXD ("Address set",CR,LF)
RETURN
The code is very brass tacks stuff no error checking or fancy stuff. Still haven't worked out a method to find the current pointer address of the scratchpad.

Also echoing to the screen so this could possibly perform even quicker.

So in this test atleast the Arduino gets a thumping.
 
You must log in or register to reply here.
Top