Would it be possible to generate a class that contains all tables (and their initialisers) and pass a reference to the instance::init() method?
Then it is up to the container to manage the lifecycle and allocation of shared data. Martin On 08/06/17 12:14, Stéphane Letz wrote: > The reason is that we want to share a unique table between all instances of > the class. But… it appears that: > > - even if the table is shared, the classInit code is actually called each > time in the instance::init(SR) method, which is rather stupid…((-; and > possibly problematic. > > - and the memory allocation strategy of this table is also not the same > across all backend (in faust2 branch). C/C++/LLVM backend use a shared table, > asm.js, WebAssembly, Interpreter backend allocate and fill the table in each > instance (the was simply done to ease the development of the backend…) > > - so we’ll have to rework this table memory allocation scheme in all backend > to be perfectly clean. Added on the « TODO » list. > > Stéphane > > >> Le 8 juin 2017 à 12:31, Martin Klang <m...@pingdynasty.com> a écrit : >> >> I've got another question regarding tables, hopefully not as silly as >> the last one -> >> >> When creating a table in Faust it produces C++ code with a static global >> variable to hold the data. >> >> `static float ftbl0mydspSIG0[65537];` >> >> (from example `generator/osci.dsp`, using Faust 2.0.a73, owl.cpp >> architecture) >> >> Is there any way to instruct Faust to create this on the heap instead? >> >> >> If I edit the generated code to make the table a non-static member >> variable of the generated class, and change `classInit()` to not be >> static, then I can create the class instance on the heap and it all >> works beautifully. >> >> I imagine there's a reason why classInit() and the generated tables are >> static. >> >> >> Martin >> >> >> On 06/06/17 15:58, Stéphane Letz wrote: >>>> Le 6 juin 2017 à 16:50, Martin Klang <m...@pingdynasty.com> a écrit : >>>> >>>> Hello list, this is my first post - Martin in London here! >>>> >>>> I develop the OWL Pedal / Modular, an embedded platform which runs FAUST. >>>> We're trying to get up to speed with the latest version, but have hit a >>>> couple of snags. >>>> >>>> Somewhere between v0.9.85 and 0.9.90 it seems that optimised versions of >>>> math functions have been introduced that are based on lookup tables. >>>> E.g. sin/sinf(). >>> We are not generating any optimized version of math functions based on >>> lookup tables.... >>> >>>> With the OWL, our trig is already optimised, so the generated tables are >>>> actually populated from our implementation. And the FAUST tables are way >>>> too big for us: 65k of floats is 4x our total memory footprint for patches! >>>> >>>> This applies to both the master and faust2 branches. They generate >>>> different code, but with the same size tables. >>>> >>>> Is there a way to turn this off and use the system math functions instead? >>>> >>>> thanks! >>>> >>>> >>>> Martin >>>> >>> Please send me example of .dsp files (and possibly the generated C++ code >>> also) that are showing the issue. >>> >>> Thanks >>> >>> Stéphane >>> ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Faudiostream-devel mailing list Faudiostream-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/faudiostream-devel