|
»
« Return to Thread: Building both floats and doubles
Re: Building both floats and doubles
by Michael Gogins-2
::
Rate this Message:
I propose that we simply move to support only one sample size. I would
prefer double, but I can live with float.
The motive for double was a hypothesis that audio precision would
improve. It did improve, but the cases where the improvement is
audible are few and subtle. Therefore, I believe we should standardize
on the audio sample size whose performance is optimum.
This fastest sample size seems to be different on different
architectures, but I don't see why that is a problem. In a sense, it's
even an advantage, as it would ensure that we continue to maintain the
build for both sample sizes.
I propose that we conduct tests of representative performance use
cases on OS X, Windows, and Linux, and standardize packages for the
best performing sample size on each platform. I also propose that we
repeat my double blind tests of audio rendering precision with more
formal use cases and on different platforms.
Your use of 'R' shows that we could write Python scripts that can
automate the builds and the performance testing, and analyze the
results. We could do the same with ABX comparison if we write a little
Python GUI for the ABX tests.
Regards,
Mike
On 5/26/09, victor <Victor.Lazzarini@...> wrote:
> My opinion on this matter is that we should perhaps start moving
> towards support doubles only and have clear roadmap for that.
> Eventually floats could still be built from sources, but not supported
> in binary distributions.
>
> Victor
> ----- Original Message -----
> From: "Felipe Sateler" <fsateler@...>
> To: "Developer discussions" <csound-devel@...>
> Sent: Tuesday, May 26, 2009 2:52 AM
> Subject: [Cs-dev] Building both floats and doubles
>
>
>> I've been thinking about changing the csound Debian packaging to
>> support both 32 and 64 bit builds. There is, however, one major
>> problem. While the csound library itself has a different name for each
>> version, allowing both to be installed at the same time, none of the
>> other libraries do. Plugins could be easily configured to install on
>> separate paths and define appropriate OPCODEDIR/OPCODE64DIR. However,
>> the interface libraries do not encode the floating point size in their
>> names, thus making it impossible to install both at the same time.
>> libcsnd.so would need to be renamed, and lua/python/java bindings
>> would have to conflict with each other (because there is no meaningful
>> way in which this can be done without renaming the module, and I think
>> it doesn't make much sense to have both). Alternatively, I could allow
>> the csound library to be both sizes, but only allow a single version
>> of libcsnd.so (and thus, all the bindings).
>> The second option is clearly suboptimal, but it is simpler, and is
>> better than the current situation (although, inside debian, nobody
>> uses libcsound yet, and the only prospective package I know of is
>> qutecsound, which wouldn't benefit since it uses libcsnd.so). However,
>> just supporting different versions of the same executable at the same
>> time is a significant pain, and I won't do it unless somebody shows me
>> it has some clear advantages.
>> The first option is technically superior, but it would mean breaking
>> existing users of libcsnd.so (how many of these are out there?
>> qutecsound and CsoundAC are the only ones that I am aware of). Users
>> of python/lua/java interfaces will not have a problem because those
>> wrappers would be changed at the same time as csound. I think the
>> safest way to do this (if there is need to) is to just change the name
>> and (unfortunately) requiring applications to change if they want to
>> use the 64bit version.
>>
>> Do you people think it is worth it? I only use doubles version, but
>> apparently some people have uses for floats due to its perceived
>> performance benefit (which may not always exist, as we've seen). And
>> by worth it, I mean breaking every user of the csnd C++ wrapper.
>> Developers, do you think this increase in complexity is worthwile? I
>> ask because I remember some talk about just dropping floats a while
>> ago.
>>
>>
>> Saludos,
>> Felipe Sateler
>>
>> ------------------------------------------------------------------------------
>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
>> is a gathering of tech-side developers & brand creativity professionals.
>> Meet
>> the minds behind Google Creative Lab, Visual Complexity, Processing, &
>> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
>> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@...
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals.
> Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
--
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com
------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel
prefer double, but I can live with float.
The motive for double was a hypothesis that audio precision would
improve. It did improve, but the cases where the improvement is
audible are few and subtle. Therefore, I believe we should standardize
on the audio sample size whose performance is optimum.
This fastest sample size seems to be different on different
architectures, but I don't see why that is a problem. In a sense, it's
even an advantage, as it would ensure that we continue to maintain the
build for both sample sizes.
I propose that we conduct tests of representative performance use
cases on OS X, Windows, and Linux, and standardize packages for the
best performing sample size on each platform. I also propose that we
repeat my double blind tests of audio rendering precision with more
formal use cases and on different platforms.
Your use of 'R' shows that we could write Python scripts that can
automate the builds and the performance testing, and analyze the
results. We could do the same with ABX comparison if we write a little
Python GUI for the ABX tests.
Regards,
Mike
On 5/26/09, victor <Victor.Lazzarini@...> wrote:
> My opinion on this matter is that we should perhaps start moving
> towards support doubles only and have clear roadmap for that.
> Eventually floats could still be built from sources, but not supported
> in binary distributions.
>
> Victor
> ----- Original Message -----
> From: "Felipe Sateler" <fsateler@...>
> To: "Developer discussions" <csound-devel@...>
> Sent: Tuesday, May 26, 2009 2:52 AM
> Subject: [Cs-dev] Building both floats and doubles
>
>
>> I've been thinking about changing the csound Debian packaging to
>> support both 32 and 64 bit builds. There is, however, one major
>> problem. While the csound library itself has a different name for each
>> version, allowing both to be installed at the same time, none of the
>> other libraries do. Plugins could be easily configured to install on
>> separate paths and define appropriate OPCODEDIR/OPCODE64DIR. However,
>> the interface libraries do not encode the floating point size in their
>> names, thus making it impossible to install both at the same time.
>> libcsnd.so would need to be renamed, and lua/python/java bindings
>> would have to conflict with each other (because there is no meaningful
>> way in which this can be done without renaming the module, and I think
>> it doesn't make much sense to have both). Alternatively, I could allow
>> the csound library to be both sizes, but only allow a single version
>> of libcsnd.so (and thus, all the bindings).
>> The second option is clearly suboptimal, but it is simpler, and is
>> better than the current situation (although, inside debian, nobody
>> uses libcsound yet, and the only prospective package I know of is
>> qutecsound, which wouldn't benefit since it uses libcsnd.so). However,
>> just supporting different versions of the same executable at the same
>> time is a significant pain, and I won't do it unless somebody shows me
>> it has some clear advantages.
>> The first option is technically superior, but it would mean breaking
>> existing users of libcsnd.so (how many of these are out there?
>> qutecsound and CsoundAC are the only ones that I am aware of). Users
>> of python/lua/java interfaces will not have a problem because those
>> wrappers would be changed at the same time as csound. I think the
>> safest way to do this (if there is need to) is to just change the name
>> and (unfortunately) requiring applications to change if they want to
>> use the 64bit version.
>>
>> Do you people think it is worth it? I only use doubles version, but
>> apparently some people have uses for floats due to its perceived
>> performance benefit (which may not always exist, as we've seen). And
>> by worth it, I mean breaking every user of the csnd C++ wrapper.
>> Developers, do you think this increase in complexity is worthwile? I
>> ask because I remember some talk about just dropping floats a while
>> ago.
>>
>>
>> Saludos,
>> Felipe Sateler
>>
>> ------------------------------------------------------------------------------
>> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
>> is a gathering of tech-side developers & brand creativity professionals.
>> Meet
>> the minds behind Google Creative Lab, Visual Complexity, Processing, &
>> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
>> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@...
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
> ------------------------------------------------------------------------------
> Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
> is a gathering of tech-side developers & brand creativity professionals.
> Meet
> the minds behind Google Creative Lab, Visual Complexity, Processing, &
> iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
> Group, R/GA, & Big Spaceship. http://www.creativitycat.com
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@...
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
--
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com
------------------------------------------------------------------------------
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers & brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing, &
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, & Big Spaceship. http://www.creativitycat.com
_______________________________________________
Csound-devel mailing list
Csound-devel@...
https://lists.sourceforge.net/lists/listinfo/csound-devel
« Return to Thread: Building both floats and doubles
| Free embeddable forum powered by Nabble | Forum Help |
