Right. Internally the faust compiler uses doubles anyway and these doubles
are parsed using a very standard atof function. It would be useful if you
could send me a sample code because it's really weird.....
Yann
-------------------------
Yann Orlarey
Directeur scientifique
www.grame.fr
2018-03-20 17:29 GMT-07:00 Julius Smith <j...@ccrma.stanford.edu>:
> I would not expect that big of a difference in the amount of time to
> process 64-bit versus 32-bit input data. Something else may be afoot
> here. - Julius
>
> On Tue, Mar 20, 2018 at 3:42 PM, CrocoDuck o'Ducks
> <crocoduck.odu...@gmail.com> wrote:
> > Hi guys,
> >
> > I think I probably found what was wrong.
> >
> > So, I used the -t 0 option and it worked, but it took a really huge time
> to
> > compile (almost a hour I think).
> >
> > I did some tests and I don't see any problem with fi.fir(), it supports
> very
> > large lists.
> >
> >
> > The fact that your times are as so much smaller than mine made me think.
> I
> > upgraded to 2.5.23 (that's the latest on Arch repos), but same issue. I
> was
> > about to try to build the last version but then I realised that my Julia
> > code was dumping Float64 literals into the Faust source code. However, I
> got
> > the impression that Faust wants C++ float literals, which should be kinda
> > equivalent to Julia's Float32, while C++ double should be sort of like
> > Julia's Float64. What suggested that to me is that I could see the
> numbers
> > notated with f in few (not related) compiler errors.
> >
> > So, I modified my Julia code to convert the FIR taps to Float32 before
> > writing them down in the .dsp files. Now it compiles quite fast, a bunch
> of
> > seconds.
> >
> > So, I guess that I was dropping numbers with too high precision into the
> > Faust source code, and then the compiler was spending a ton of time to
> > convert them. Is it plausible?
> >
> >
> > On Tue, 20 Mar, 2018 at 7:28 PM, Julius Smith <j...@ccrma.stanford.edu>
> > wrote:
> >
> > I think [complexity] info should be added in the library documentation.
> >
> > +1 - Julius On Tue, Mar 20, 2018 at 5:26 AM, Stéphane Letz <
> l...@grame.fr>
> > wrote:
> >
> > ba.take ==> complexity O(n^2) I think that this kind of info should be
> added
> > in the library documentation. And also as a general rule in the «
> > Contributing » section of
> > https://github.com/grame-cncm/faustlibraries/blob/master/README.md, to
> push
> > library writers to document this kind of things. Stéphane
> >
> > Le 20 mars 2018 à 04:32, Yann Orlarey <orla...@grame.fr> a écrit : HI,
> I did
> > some tests and I don't see any problem with fi.fir(), it supports very
> large
> > lists. Here is the test file I used: // ------- fir500.dsp ------
> > import("stdfaust.lib"); process = fi.fir(( 1,2,3,4,5,6,7,8,9,10, ...48
> > copies... 1,2,3,4,5,6,7,8,9,10)); //---------------------------------
> time
> > faust fir500.dsp -o /dev/null real 0m0.446s user 0m0.375s sys 0m0.030s If
> > instead, I use the second code you mentioned // ------- fur500.dsp ------
> > import("stdfaust.lib"); fur(coeffs) = _ <: par(i, 500, @(i) * ba.take(i
> + 1,
> > coeffs)) :> _; process = fur(( 1,2,3,4,5,6,7,8,9,10, ...48 copies...
> > 1,2,3,4,5,6,7,8,9,10)); //--------------------------------- The
> compilation
> > will take a very long time because ba.take() is really not the way to go
> in
> > this case (complexity O(n^2)). Here are the results I get: time faust
> > fur500.dsp -o /dev/null real 1m18.270s user 1m16.947s sys 0m0.900s The
> > difference is enormous (x170)! If in your case you don't see any
> difference
> > of performances between the two, then there is a problem with the fi.fir
> > implementation you are using. Can you try with the latest version of
> Faust
> > (version 2.5.25)? Cheers Yann 2018-03-19 15:01 GMT-07:00 Oliver Larkin
> via
> > Faudiostream-users <faudiostream-users@lists.sourceforge.net>:
> depending on
> > what faust version you are using, a foreign function might help. I had
> to do
> > this to do a convolution in my tambura synthesiser for exactly the same
> > reason https://github.com/olilarkin/Tambura/blob/master/bridgeIR.dsp
> > https://github.com/olilarkin/Tambura/blob/master/bridgeIR.h it would be
> > great if faust’s FIR didn’t bork like this oli
> >
> > On 19 Mar 2018, at 21:32, CrocoDuck o'Ducks <crocoduck.odu...@gmail.com>
> > wrote: Hi again! Thank you for all your tips!
> >
> > I suggest placing all of your coefficients into a large parallel signal
> > bank: coeffs = (b0, b1, b2, ..., b511); // FIR filter coefficients for
> > length 512 and then use par() etc.
> >
> > I tried both of these: process = fi.fir(coeffs); process = _ <: par(i,
> 512,
> > @(i) * ba.take(i + 1, coeffs)) :> _; Which, unfortunately, both suffer
> from
> > the same problem. Did I got the suggestion right?
> >
> > You can set unlimited time by adding -t 0 to your compile command.
> >
> > I am currently trying this.
> >
> > Interesting ! Do you have some code to show? Is is part of an official
> JULIA
> > ==> Faust project?
> >
> > No, it isn't an official project. I just design some filters using DSP.jl
> > then I try to generate Faust code that implements them. I just open a
> file
> > for writing and I fill it with Faust code. I guess I can cook a few
> minimal
> > examples to share, I cannot share my code right away as it is sort of
> > confidential. On Mon, 19 Mar, 2018 at 8:20 AM, Stéphane Letz <
> l...@grame.fr>
> > wrote:
> >
> > Le 18 mars 2018 à 23:06, CrocoDuck o'Ducks <crocoduck.odu...@gmail.com
> > a
> > écrit : Hi there! I currently have some Julia code producing 512 taps
> for an
> > FIR filter. Interesting ! Do you have some code to show? Is is part of an
> > official JULIA ==> Faust project? 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-users mailing list Faudiostream-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/faudiostream-users
> >
> > ------------------------------------------------------------
> ------------------
> > Check out the vibrant tech community on one of the world's most engaging
> > tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________ Faudiostream-users
> mailing
> > list Faudiostream-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/faudiostream-users
> > ------------------------------------------------------------
> ------------------
> > Check out the vibrant tech community on one of the world's most engaging
> > tech sites, Slashdot.org!
> > http://sdm.link/slashdot_______________________________________________
> > Faudiostream-users mailing list Faudiostream-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/faudiostream-users
> >
> > ------------------------------------------------------------
> ------------------
> > Check out the vibrant tech community on one of the world's most engaging
> > tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________ Faudiostream-users
> mailing
> > list Faudiostream-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/faudiostream-users
> >
> > --
> > Julius O. Smith III <j...@ccrma.stanford.edu> Professor of Music and, by
> > courtesy, Electrical Engineering CCRMA, Stanford University
> > http://ccrma.stanford.edu/~jos/
> > ------------------------------------------------------------
> ------------------
> > Check out the vibrant tech community on one of the world's most engaging
> > tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________ Faudiostream-users
> mailing
> > list Faudiostream-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/faudiostream-users
> >
> >
> > ------------------------------------------------------------
> ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > _______________________________________________
> > Faudiostream-users mailing list
> > Faudiostream-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/faudiostream-users
> >
>
>
>
> --
> Julius O. Smith III <j...@ccrma.stanford.edu>
> Professor of Music and, by courtesy, Electrical Engineering
> CCRMA, Stanford University
> http://ccrma.stanford.edu/~jos/
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Faudiostream-users mailing list
> Faudiostream-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users
