ARM NEON in ObJAsm

I totally forgot about this thread lol, what the heck has happened here? XD

@ Matthew
Performance obviously vary based on the size of memcpy/memmove/memset your code does in one time. For instance, if it copies a single byte or like 3 bytes per time, you have no performance improvements (and btw in these cases I fall back to standard RISC OS implementation as it’s lighter). But if your code needs to copy/set/move a lot of bytes at once then performance improvement can be substantial (depending on amount of bytes in a single call, the board, memory bandwidth, the ARM chip etc.).

As soon as I have a good benchmark running on RISC OS I’ll share the numbers I get on all my boards.

@ Rick

yes the original topic is about improving memory (copy, set and move) performance in C on RISC OS.

@ Stuart

Gavin link to Zhal here: http://www.wra1th.plus.com/soft.html

Scroll down. And great work Gavin! :)

For the new topic about math operations using NEON:

NEON can benefits such type of operations only when a piece of software does a lot of similar computations that could be parallelised. In other words if you just need to do a single sqrt for a single value, then there will be little to no benefit in using a NEON based implementation of it.

A reason why I am working on another project using NEON for math functions, is to improve Genann performance where each neuron performs an FP calculation and (on backfeed neural networks) this can happen multiple times too (and for the same neuron) and given that a single neural network layer may have many neurons, and a neural network is composed by multiple layers of neurons you can imagine.

There are many applications for NEON in AI: https://www.youtube.com/watch?v=lUmjnCdGtGE

The video above is a presentation of a Tech Talk that should happen on the 21st of September 2021, and it’s specifically for ARM. Some of the techniques that will be explained in that Tech Talk I am implementing on RISC OS and hopefully I’ll have enough time to get to demo-able state at some point.

All of this has very little to help BBC BASIC type of uses and/or retro-coding type of approaches on RISC OS. So, maybe not of interest here, in which case sorry for the noise.

The big integer type in !Zahl is realized by the IMath library (copyright @ 2002-2009 Michael J. Fromberger), an ISO C arbitrary precision integer and rational library that will tell you want you want to know about its representation of numbers.

Nick Craig-Wood originally wrote his BigNum (relocatable) module in ARM assembler, offering SWI calls so that any kind of RISC OS application could use it. When he left RISC OS-land I offered to maintain it for him. I came across some bugs. For example the Newton-Raphson algorithm for square root does not work in integer arithmetic when you start with a number one less than a power of two. After a while I found the ARM assembler code too difficult to maintain, and, finding C easier to work with, I produced !Zahl as a partial replacement.

If I may mount my hobby horse at this point, there are indefinitely many ways of representing numbers in a computer, but it seems that most people are fixated on the standard floating point representations and are unaware of alternatives. Floating point numbers suit engineering very well (I am not being rude here), but they do have their own drawbacks. Their principal virtue is to break the bond between the value of a number and the number of bytes required to store its representation. Their principal vice is that the ordinary laws of arithmetic, e.g that x + (y + z) be equal to (x + y) + z, do not hold. There are systems for which they do, but not ones for which numbers take up a fixed number of bytes to store.

Three years ago there was a very extended topic in the Raspberry Pi forums about the suitability of various un-enhanced ¹ languages to numeric tasks. This centred around finding the first fibonacci number with 1 million decimal digits. DavidS was there on the sidelines with his usual promotion of Assembler and BASIC, but the other contributors were fully engaged and there were some really interesting aspects discussed, so that I learned a great deal.

To be part of it, I set about finding a solution in ARM BASIC, using array operations with some modifications of my own invention. I was able to get my solution to finish on my mini.m in about a day and a half! Towards the end, the experts, using various compiled languages, were shaving fractions off substantially less than a second on some quite fast machines.

I then found the Numbers module that Gavin was maintaining. Using that, still in BASIC, I was able to get a result in only a few minutes. While working out how to use Numbers I wrote a StrongHelp manual for it, so if anyone is interested I could post a link.

There are a couple of other things I learnt. First is that the algorithms used in Numbers have dated and there are significantly faster ones around now. The second is that there are C libraries that incorporate all the speed tricks for the fibonacci task and can produce a result in a single line. ;-)

What is needed is a job like the RexEx module, which takes a C library and incorporates it into a RISC OS module. That is probably Zahl, of course, but I have not looked at it yet.

¹ Un-enhanced was taken to mean no libraries or extensions.

Edit: it was fibonacci number not factorial – oops.

I wrote an article The Triumph of Lazy Tables in PiAddict Vol 1. No 6.August 2013, comparing the performance of different algorithms for calculating the fibonacci series. Alas, that magazine is defunct, I believe.

The contradiction between time and space (i.e. storage) is an interesting theme in computer science. Lua makes this explicit. Functions (f(x)) use fixed space but unknown time, tables (f[x]) use fixed time but unknown space. Memoization lets use of tables speed up functions. The dual, using Lua’s metatables, lets use of functions enlarge tables.

That set me thinking back to school days.
(Slightly divergent: Pascal’s triangle)
A triangle of values where the two values above add to produce the value and with the n+1^th line giving the coefficients of the expansion of (x+y)ⁿ

Our schoolboy minds quickly realised we could use a tetrahedron of values in the same way for (x+y+z)ⁿ
So for me the next step was (w+x+y+z)ⁿ with a conundrum about how to represent the coefficient values. The tetrahedron already ran foul of the limitations of a flat sheet of paper.

I had a long email correspondence with Richard Hallas, when he was editor of Foundation Risc User, about how people differ in their imaginations, particularly how they see numbers.

Our schoolboy minds quickly realised we could use a tetrahedron of values in the same way for (x+y+z)n

Good for your schoolboy minds. I think you were unusually quick.

the performance of different algorithms for calculating the fibonacci series

Both the discussion and my reading around it introduced me to several of those. My own attempts used only slightly enhanced Karatsuba method.

Memoization lets use of tables speed up functions.

Now there’s a concept that was new to me and cropped up a lot in the fibonacci topic. Nothing like that for BASIC, although I have learned that the use of precalculated data structures can save a lot of code and time.

That is probably Zahl, of course, but I have not looked at it yet.

I now realise that I did look at Zahl back then, but it is not the module I hoped for and not possible to integrate with BASIC, is it?

Good for your schoolboy minds.

That reminds me of, first Mathematician’s Delight, but especially of the later Prelude to Mathematics, that introduced me to the idea of looking for such patterns.

Both excellent books. Alas, the IMath library, which Zahl uses, is in C and would be hard to integrate with BASIC. I felt a bit guilty that this aspect of Craig-Wood’s BigNumber module I was unable to keep alive. I think he went on to look at some other arithmetics that are possibly interesting for RISC OS. One was to choose the biggest prime, call it p (surprise?), smaller than 2^64. Its residues can be represented within 8 bytes. Modular arithmetic modulo p could be useful, and there are some clever ARM assembler tricks to make it fast. Another useful thing to consider is the Chinese Remainder Theorem. That tells you that modular arithmetic modulo a product of distinct primes can be done by working modulo each prime separately. Ideally you delegate a separate core for each prime. Something for the future, maybe?