Im interested to know if the CRIO supports SIMD (Single Instruction Multiple Data)
(https://en.wikipedia.org/wiki/SIMD)
Or if anyone has the technical specifications that would be great as well.
The reason I ask is because I am currently working on a math library for a game engine and it uses the 128bit register on the CPU to hold multiple data that can be operated on with a single instruction thus increasing performance (e.g. scaling a vector (x,y,z)*2)
So i was thinking same technique could be used to increase code performance for FRC 2014.
I’m just wondering, what exactly are you planning to do on the cRIO that requires optimization of the math library? Also, you’ll only see benefits on things that deal with complex math and vectors, not something that teams really use too much on FRC robots.
If your robot’s code doesn’t work correctly (100% CPU usage), and it needs to be optimized, you can post it here and people can help.
NOTE: This is wrong, it doesn’t have SIMD.
Also, the first page in the datasheet for the cpu says
e300 Power Architecture processor core
Wikipedia says that all e300’s meet Power ISA 2.03
Wikipedia says that Power ISA 2.03 requires AltiVec
Wikipedia says AltiVec is a floating point and integer SIMD instruction set
Most modern processors have SIMD, so it’s not always explicitly stated in the datasheet.
I’d be more worried about making the robot move and function properly than trying to speed up a math library that’s rarely used in this application in the first place…
I’m just wondering, what exactly are you planning to do on the cRIO that requires optimization of the math library? Also, you’ll only see benefits on things that deal with complex math and vectors, not something that teams really use too much on FRC robots.
If your robot’s code doesn’t work correctly (100% CPU usage), and it needs to be optimized, you can post it here and people can help.
The robot is functional.
I just have a lot time on my hands so I’ve been investing my time into learning new software design, coding concepts, techniques and libraries even if its trivial or non applicable to the function of the robot. (What im doing is more for my own benefit, but if i can incorporate it to assist my team its even better)
That is good to know. Its just a question now of whether or not they will enable NEON as it is listed as optional on the specs of the Cortex A9. I hope the RRIO gets deployed before I enroll for U of BC so I can at least mentor for a bit.
I applaud your curiosity to better understand computer architectures. To reiterate, the cRIO processor used in FRC does not support any vector operations in HW, no SIMD. Rather than wait for a new controller or look for opportunities to do this with robotics, I’d encourage you to do this on your desktop or laptop computer. SSE, MMX, and other vector technologies from Intel are readily available and great examples to learn from.
My own exposure to this was via Altivec a number of years ago when a bug caused me to break into disassembled code for the system’s memcpy, copyMem, or whatever it was called then. I was puzzled to find an complex arrangement of vector and prefetch instructions being used. The complexity was there to optimize a various alignment situations, and the calling code was copying a large buffer from an even to an odd address. The architecture isn’t generally efficient at dealing with odd accesses, so they used Altivec to unroll and vectorize the operation.
This led me to find other libraries hand-tuned with Altivec including those for image processing and sound processing.
My suggestion would be to find a project that interests you, perhaps sound processing or image processing and compare different implementation techniques for the same operation. You can write very simple C code to walk through the data, use vector iterators, and compare to optimized SSE libraries from Intel. Even better is to use the debugger or the disassembly option of the compiler to inspect what the compiler produced and what the CPU is executing. Use the reference manuals and white papers for SSE to better understand why the libraries were written that way. This sort of investigation is still something I do from time to time to understand newer architecture features and language features.