Your concerns are certainly warranted.

But if the function is

a) never called recursively,

b) is never inlined(!)* and

c) the buffer size is guaranteed not to exceed some reasonable size for stack allocation (say a few hundred bytes),

then alloca() is IMO the best tool for the job. It is not only simpler but also faster than pre-allocation, because the stack memory is much more likely to be in cache.

Again, I wouldn't recommend using alloca() for general purpose programming, but when used cautiously it can be a great tool for real-time code.

---

BTW, here's an example for how alloca() might be used in a production-grade library: https://github.com/gcp/opus/blob/master/celt/stack_alloc.h

It uses alloca() resp. VLAs, but can fallback to a pseudo stack for platforms without alloca()/VLA support or small stack sizes (e.g. embedded devices).

Christof

*) IIRC, GCC refuses to inline functions if they contain alloca() statements. What can go wrong with inlined functions containing alloca(): https://stackoverflow.com/a/3410689/6063908

> On Friday, December 4, 2020, 9:43:20 AM EST, Christof Ressi <info@christofressi.com> wrote:

> alloca() "allocates" memory on the stack. This is done by simply incrementing the stack pointer. So it's extremely fast and - more importantly - equally fast for all sizes.

It also requires you, the programmer, to add up the total number of possible allocations in a recursive call to the object, for supported platforms with small default stack sizes, and doing the math in your head to ensure your algorithm will never go over that stack limit, for all possible cases. Since that stack limit is many orders of magnitude smaller than the RAM on the most popular Pd platform, you're way more likely to accidentally cause crashes for your users by relying on alloca.

Again, the ATOMS_ALLOCA macro in x_list.c is the careful, thoughtful reference for use of alloca. And even in that case there are almost certainly multiple ways to cause a crasher from it. In other words, it's nearly impossible to use alloca safely.

Don't use alloca *unless* you have made worst case measurements on every other algorithm you can think of, and none of them are satisfactory. Even then, *measure* alloca to be worst-case safe and write regression tests for the recursive edge cases that could blow the stack. Chances are when you consider doing that extra work, you'll quickly think up a different algorithm that doesn't rely on alloca.

> malloc(), on the other hand, actually uses the system memory allocator which can take arbitrarily long and might even block!

> Generally, you should avoid using any malloc() in real-time code paths. Instead, pre-allocate temporary buffers (e.g. in the "dsp" method) or allocate on the stack (but note the caveats mentioned in the other mails).

Pre-allocate.

If you can't, ask on the list how to use alloca without blowing the stack. Once you crowdsource a truly safe algorithm, write tests so you catch the crashers that the crowd missed the first time around.

To be clear-- I basically grepped for "alloca" in the current codebase, opened up x_list.c, and *assumed* because alloca is tricky that there is somehow a crasher bug. It took about 5 minutes to come up with a case that should crash on Windows.

I also see it in m_binbuf.c, and I'd make the same bet it can blow the Windows stack if someone spends five minutes looking at the code. For a common building block of realtime safe algos, I shouldn't be able to make claims like these for any use of alloca I happen to find.

I keep harping on this because the default description of alloca makes it sound like the quintessential building block of realtime algos. Please weigh that alluring set of seeming realtime safe benefits against the history of realtime unsafe crashers of which will likely include your use alloca.

Best,

Jonathan

> Christof

On 04.12.2020 03:28, Alexandre Torres Porres wrote:

I'm using getbytes and freebytes for now, any disadvantages over alloca?

thanks!

Em qui., 3 de dez. de 2020 às 20:59, David Rush <kumoyuki@gmail.com> escreveu:

On Thu, 3 Dec 2020 at 23:15, Alexandre Torres Porres <porres@gmail.com> wrote:

Hi, when compiling ELSE for camomille in windows, me and Esteban are getting some errors. Offending pieces of code are when trying to do things like

t_atom at[ac];

If you want to maintain straight C compiler compatibility

        t_atom* at = (t_atom*)malloc(ac * sizeof(t_atom));

but you have to remember to free(at), &cet. You can avoid the free() if you HAVE_ALLOCA with

        t_atom* at = (t_atom*)alloca(ac * sizeof(t_atom));

if you want to do it the C++ way without a std::vector<t_atom>

        t_atom* at = new t_atom[ac];

but again you will have to

        delete at;

For my own externals, I write them all in C++ and use STL. Making the change from the C-world allocation of PD to the C++ world is not so hard, but it does involve a tiny bit of trickery which I only justify through expediency.

- d

_______________________________________________
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev

_______________________________________________
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev