Hi Manuel,
On 11/05/2020, 10:45, "Manuel Pegourie-Gonnard" Manuel.Pegourie-Gonnard@arm.com wrote:
> These are very similar points to those Manuel was making to remove the feature > in the first place - however - short of investing the time in rewriting the > asymmetric functions, what we could do as a quick fix is to replace the > existing memory code with a block allocation scheme - which should be much > faster, speed up the asymmetric functions (in theory), avoid fragmentation, be > more deterministic, and a better fit for embedded applications. That could > then become the basis of the library for other projects too. > I think compared to our existing allocator, that would indeed be an improvement, and as you say possibly a "quick fix" for some of the performance issues of our asymmetric crypto (esp. ECC)... for people who use our allocator. I'm still under the impression they're a minority of users, even in the embedded world.
I would anticipate use of the allocator to actually speed up most platforms, as it will be faster than malloc. Block allocators can be inefficient in their use of RAM but are often used where performance matters. They are not just the domain of embedded software. I'm seen them appear in SQL server software, drivers, and game software. It's a common technique.
So the intention here is that enabling the feature should see a performance improvement but possibly at the cost of RAM efficiency. (It depends how well tuned it is).
I think it comes back to a point we touched on earlier in the thread: what other allocators are available, and how do they compare to the design you have in mind? If existing allocators in popular embedded libc implementations already handle small allocations efficiently, then people are probably better off using them.
I think this goes back to Dan's point.
There are other options out there - and people can configure the library to use them already.
The choice here was to keep the existing memory manager, or replace it with something faster, more deterministic and safer - predicated on the decision to keep support for a memory manager or not.
If you want or need to keep it - let's turn it to our advantage, and improve it, and make it the library faster through its use.
Would your offer still stand in a couple of months, when the future of the module is perhaps a bit clearer, and when we've hopefully cleared a few of the long-standing large PR awaiting review?
I have no plans on starting it for a while. I need to clear down my own PR backlog before I start something new.
Regards
Simon