Start Katja's Pd from command line on rpi with full path (was) Raspberry Pi does denormals
Excuse my ignorance: not sure how to start the below version of pd on the rpi?
I have the full path but then what?
if I do (in command line) pd /place/where/new/pd/is/bin/pd It signals watchdog.
I also still have regular pd 0.44.0 installed btw.
Sorry if this is dumb dumb dumb dumb Duuummmbbb.
Jb
On 24 January 2013 09:14, katja katjavetter@gmail.com wrote:
'Undenormalized' Pd build for Raspberry Pi is temporarily parked here for testing purposes (will be removed when Miller's release is fixed in this sense):
www.katjaas.nl/temp/pd-0.44-0-normalized.tar.gz
This is a locally installed Pd, like Miller's distribution. You can start it from command line with the full path to pd-0.44-0-normalized/bin/pd. It's not a .deb, so it can't be installed under supervision of package manager.
Katja
On Wed, Jan 23, 2013 at 9:15 PM, Julian Brooks jbeezez@gmail.com wrote:
Hey Katja,
Would you mind sharing the 'normalised' Pd-0.44.0 for RPi please.
Cheers,
Julian
On 23 January 2013 18:23, katja katjavetter@gmail.com wrote:
Now I recompiled the Pd-0.44.0 release on Raspberry Pi (took me a few hours, not only because Pi is so slow) with PD_BIGORSMALL enabled for arm in m_pd.h. Using bigorsmalltest.pd from my previous mail I verified that the macro is implemented indeed.
Martin Brinkmann's patch chaosmonster1 (http://www.martin-brinkmann.de) gives a beautiful illustration of the improvement. This patch is full of filters and delay lines. At it's initial settings, there is no subnormals problem. But if you set the bottom slider to the right, it gets silent. With Pd-0.44-0 release, CPU load explodes. With the 'normalized' Pd, nothing special happens.
And indeed, the PD_BIGORSMALL conditional checks come for free: with initial settings of the chaosmonster1, performance is equivalent in both Pd's. Cool! Hopefully this is similar on armv7.
Katja
On Wed, Jan 23, 2013 at 5:01 PM, Hans-Christoph Steiner hans@at.or.at wrote:
hey Katya,
This also sounds like good evidence for your idea of writing C code
that
modern compilers optimize well. Using unions for aliasing allows the compiler to do all the new tricks, then writing loops that auto-vectorize gives us the real benefits. Also, I think we can see some gains by using memcpy() since on modern libc version, those are highly optimized for the given CPU, dynamically choosing the routines based on what instructions are available. memcpy will use things like SSSE2 if its available.
.hc
On 01/23/2013 07:47 AM, katja wrote:
Finally some good news on this topic. Earlier I stated that 'big or small tests' are expensive for the Pi, but that is not by definition the case. There must have been other conditions blurring my impression. I've now done a systematic test where other influences
are
ruled out. A test class [lopass~] with exactly the same routine as [lop~] was made, but compiled with PD_BIGORSMALL() macro enabled. It was verified that [lopass~] is not affected by denormals. Performance comparison of [lop~] and [lopass~] shows that both objects cause equivalent CPU load. Meaning, Raspberry Pi gives the 'big or small checks' for free! At least in the case of this simple filter. Please try attached bigorsmalltest.zip on the Pi to see if I'm not dreaming.
While I was at the topic anyway, I also tried a big or small test
with
union instead of direct type aliasing. It has the advantage that the compiler can apply strict aliasing rules. This test with unions did not cause extra CPU load either on the Pi. If you want to verify this result, enable the call to bigorsmall() instead of PD_BIGORSMALL in lopass~.c and recompile.
The fact that these tests do not cause extra CPU load, indicate that they are done in parallel with other instructions. Float and int registers are apparently strictly separated on armv6, there's no such thing like Intel's xmm registers or armv7's NEON. As it happens, the big or small tests are done on ints, aliases of the floats that must be tested. Initially I assumed that the transport of floats from vfp to the arm integer processor would be expensive, but if the instructions are done simultaneously it may be an advantage instead. Another thing is that ARM implements branch predication instead of branch prediction. Those terms look almost the same but the routines are very different. Predication is when instructions for both
branches
are executed, and the wrong result is simply discarded later.
Conclusions from the limited test with [lop~] and [lopass~] do not mean that all sorts of conditional checks are cheap on the Pi, or on ARM in general. If PD_BIGORSMALL is enabled for RPi using
compile-time
definition __arm__, it will also hold for armv7, but it may have very different result there. At the moment I have no access yet to an
armv7
device. Maybe someone can recompile test class [lopass~] and do the tests on Beagleboard or Cubieboard? Otherwise I may be able to do it on my friend's PengPod when that has arrived.
Katja
On Tue, Jan 22, 2013 at 8:54 PM, Miller Puckette msp@ucsd.edu
wrote:
thanks - I'd better try this and find out what's going on :)
M
On Mon, Jan 21, 2013 at 11:54:29AM +0100, katja wrote: > Tried the 0.44.0 build from your website. It has the same issue
with
> subnormal values. My test patch is with [lop~]. If inf or nan is
fed
> into [lop~], these 'values' keep circulating in the object, it can
no
> longer process normal signal values. > > I also tried my reverb stuff with specific compiler options for
Pi's
> processor: > > -march=armv6zk > -mcpu=arm1176jzf-s > -mtune=arm1176jzf-s > > With these options, gcc should be able to decide that RunFast mode
is
> permitted. But even in combination with -ffast-math (which in turn > sets -funsafe-math-optimizations and -fno-trapping-math amongst > others), denormals are still there. I'm literally out of options
for
> the moment. Sorry for not having better news. > > Katja > >
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Julian,
Most convenient is to go in the bin directory of that 'local' Pd with
cd /place/where/new/pd/is/bin
From there you can start (and restart) the local Pd with
./pd
In my case, the recompiled Pd would not start because it could not find libportaudio.so.2. After installing libportaudio2 via Synaptic, 'normalized' Pd would finally start.
It is no problem to have the regular Pd still installed. Maybe you can install the local Pd over the regular Pd using the gnumakefile. Didn't try that, I don't like to install things without package manager.
Katja
On Fri, Jan 25, 2013 at 3:41 PM, Julian Brooks jbeezez@gmail.com wrote:
Excuse my ignorance: not sure how to start the below version of pd on the rpi?
I have the full path but then what?
if I do (in command line) pd /place/where/new/pd/is/bin/pd It signals watchdog.
I also still have regular pd 0.44.0 installed btw.
Sorry if this is dumb dumb dumb dumb Duuummmbbb.
Jb
On 24 January 2013 09:14, katja katjavetter@gmail.com wrote:
'Undenormalized' Pd build for Raspberry Pi is temporarily parked here for testing purposes (will be removed when Miller's release is fixed in this sense):
www.katjaas.nl/temp/pd-0.44-0-normalized.tar.gz
This is a locally installed Pd, like Miller's distribution. You can start it from command line with the full path to pd-0.44-0-normalized/bin/pd. It's not a .deb, so it can't be installed under supervision of package manager.
Katja
On Wed, Jan 23, 2013 at 9:15 PM, Julian Brooks jbeezez@gmail.com wrote:
Hey Katja,
Would you mind sharing the 'normalised' Pd-0.44.0 for RPi please.
Cheers,
Julian
On 23 January 2013 18:23, katja katjavetter@gmail.com wrote:
Now I recompiled the Pd-0.44.0 release on Raspberry Pi (took me a few hours, not only because Pi is so slow) with PD_BIGORSMALL enabled for arm in m_pd.h. Using bigorsmalltest.pd from my previous mail I verified that the macro is implemented indeed.
Martin Brinkmann's patch chaosmonster1 (http://www.martin-brinkmann.de) gives a beautiful illustration of the improvement. This patch is full of filters and delay lines. At it's initial settings, there is no subnormals problem. But if you set the bottom slider to the right, it gets silent. With Pd-0.44-0 release, CPU load explodes. With the 'normalized' Pd, nothing special happens.
And indeed, the PD_BIGORSMALL conditional checks come for free: with initial settings of the chaosmonster1, performance is equivalent in both Pd's. Cool! Hopefully this is similar on armv7.
Katja
On Wed, Jan 23, 2013 at 5:01 PM, Hans-Christoph Steiner hans@at.or.at wrote:
hey Katya,
This also sounds like good evidence for your idea of writing C code that modern compilers optimize well. Using unions for aliasing allows the compiler to do all the new tricks, then writing loops that auto-vectorize gives us the real benefits. Also, I think we can see some gains by using memcpy() since on modern libc version, those are highly optimized for the given CPU, dynamically choosing the routines based on what instructions are available. memcpy will use things like SSSE2 if its available.
.hc
On 01/23/2013 07:47 AM, katja wrote:
Finally some good news on this topic. Earlier I stated that 'big or small tests' are expensive for the Pi, but that is not by definition the case. There must have been other conditions blurring my impression. I've now done a systematic test where other influences are ruled out. A test class [lopass~] with exactly the same routine as [lop~] was made, but compiled with PD_BIGORSMALL() macro enabled. It was verified that [lopass~] is not affected by denormals. Performance comparison of [lop~] and [lopass~] shows that both objects cause equivalent CPU load. Meaning, Raspberry Pi gives the 'big or small checks' for free! At least in the case of this simple filter. Please try attached bigorsmalltest.zip on the Pi to see if I'm not dreaming.
While I was at the topic anyway, I also tried a big or small test with union instead of direct type aliasing. It has the advantage that the compiler can apply strict aliasing rules. This test with unions did not cause extra CPU load either on the Pi. If you want to verify this result, enable the call to bigorsmall() instead of PD_BIGORSMALL in lopass~.c and recompile.
The fact that these tests do not cause extra CPU load, indicate that they are done in parallel with other instructions. Float and int registers are apparently strictly separated on armv6, there's no such thing like Intel's xmm registers or armv7's NEON. As it happens, the big or small tests are done on ints, aliases of the floats that must be tested. Initially I assumed that the transport of floats from vfp to the arm integer processor would be expensive, but if the instructions are done simultaneously it may be an advantage instead. Another thing is that ARM implements branch predication instead of branch prediction. Those terms look almost the same but the routines are very different. Predication is when instructions for both branches are executed, and the wrong result is simply discarded later.
Conclusions from the limited test with [lop~] and [lopass~] do not mean that all sorts of conditional checks are cheap on the Pi, or on ARM in general. If PD_BIGORSMALL is enabled for RPi using compile-time definition __arm__, it will also hold for armv7, but it may have very different result there. At the moment I have no access yet to an armv7 device. Maybe someone can recompile test class [lopass~] and do the tests on Beagleboard or Cubieboard? Otherwise I may be able to do it on my friend's PengPod when that has arrived.
Katja
On Tue, Jan 22, 2013 at 8:54 PM, Miller Puckette msp@ucsd.edu wrote: > thanks - I'd better try this and find out what's going on :) > > M > > On Mon, Jan 21, 2013 at 11:54:29AM +0100, katja wrote: >> Tried the 0.44.0 build from your website. It has the same issue >> with >> subnormal values. My test patch is with [lop~]. If inf or nan is >> fed >> into [lop~], these 'values' keep circulating in the object, it can >> no >> longer process normal signal values. >> >> I also tried my reverb stuff with specific compiler options for >> Pi's >> processor: >> >> -march=armv6zk >> -mcpu=arm1176jzf-s >> -mtune=arm1176jzf-s >> >> With these options, gcc should be able to decide that RunFast mode >> is >> permitted. But even in combination with -ffast-math (which in turn >> sets -funsafe-math-optimizations and -fno-trapping-math amongst >> others), denormals are still there. I'm literally out of options >> for >> the moment. Sorry for not having better news. >> >> Katja >> >>
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hi Katja,
Thanks for this.
When I cd into bin then ./pd I get 'permission denied'. And sudo'd I get 'command not found'.
Any other ideas?
Jb
On 25 January 2013 15:36, katja katjavetter@gmail.com wrote:
Hi Julian,
Most convenient is to go in the bin directory of that 'local' Pd with
cd /place/where/new/pd/is/bin
From there you can start (and restart) the local Pd with
./pd
In my case, the recompiled Pd would not start because it could not find libportaudio.so.2. After installing libportaudio2 via Synaptic, 'normalized' Pd would finally start.
It is no problem to have the regular Pd still installed. Maybe you can install the local Pd over the regular Pd using the gnumakefile. Didn't try that, I don't like to install things without package manager.
Katja
On Fri, Jan 25, 2013 at 3:41 PM, Julian Brooks jbeezez@gmail.com wrote:
Excuse my ignorance: not sure how to start the below version of pd on the rpi?
I have the full path but then what?
if I do (in command line) pd /place/where/new/pd/is/bin/pd It signals watchdog.
I also still have regular pd 0.44.0 installed btw.
Sorry if this is dumb dumb dumb dumb Duuummmbbb.
Jb
On 24 January 2013 09:14, katja katjavetter@gmail.com wrote:
'Undenormalized' Pd build for Raspberry Pi is temporarily parked here for testing purposes (will be removed when Miller's release is fixed in this sense):
www.katjaas.nl/temp/pd-0.44-0-normalized.tar.gz
This is a locally installed Pd, like Miller's distribution. You can start it from command line with the full path to pd-0.44-0-normalized/bin/pd. It's not a .deb, so it can't be installed under supervision of package manager.
Katja
On Wed, Jan 23, 2013 at 9:15 PM, Julian Brooks jbeezez@gmail.com
wrote:
Hey Katja,
Would you mind sharing the 'normalised' Pd-0.44.0 for RPi please.
Cheers,
Julian
On 23 January 2013 18:23, katja katjavetter@gmail.com wrote:
Now I recompiled the Pd-0.44.0 release on Raspberry Pi (took me a few hours, not only because Pi is so slow) with PD_BIGORSMALL enabled for arm in m_pd.h. Using bigorsmalltest.pd from my previous mail I verified that the macro is implemented indeed.
Martin Brinkmann's patch chaosmonster1 (http://www.martin-brinkmann.de) gives a beautiful illustration of
the
improvement. This patch is full of filters and delay lines. At it's initial settings, there is no subnormals problem. But if you set the bottom slider to the right, it gets silent. With Pd-0.44-0 release, CPU load explodes. With the 'normalized' Pd, nothing special happens.
And indeed, the PD_BIGORSMALL conditional checks come for free: with initial settings of the chaosmonster1, performance is equivalent in both Pd's. Cool! Hopefully this is similar on armv7.
Katja
On Wed, Jan 23, 2013 at 5:01 PM, Hans-Christoph Steiner <
hans@at.or.at>
wrote:
hey Katya,
This also sounds like good evidence for your idea of writing C code that modern compilers optimize well. Using unions for aliasing allows
the
compiler to do all the new tricks, then writing loops that auto-vectorize gives us the real benefits. Also, I think we can see some gains by using
memcpy()
since on modern libc version, those are highly optimized for the given CPU, dynamically choosing the routines based on what instructions are available. memcpy will use things like SSSE2 if its available.
.hc
On 01/23/2013 07:47 AM, katja wrote: > Finally some good news on this topic. Earlier I stated that 'big
or
> small tests' are expensive for the Pi, but that is not by
definition
> the case. There must have been other conditions blurring my > impression. I've now done a systematic test where other influences > are > ruled out. A test class [lopass~] with exactly the same routine as > [lop~] was made, but compiled with PD_BIGORSMALL() macro enabled.
It
> was verified that [lopass~] is not affected by denormals. > Performance > comparison of [lop~] and [lopass~] shows that both objects cause > equivalent CPU load. Meaning, Raspberry Pi gives the 'big or small > checks' for free! At least in the case of this simple filter.
Please
> try attached bigorsmalltest.zip on the Pi to see if I'm not > dreaming. > > While I was at the topic anyway, I also tried a big or small test > with > union instead of direct type aliasing. It has the advantage that
the
> compiler can apply strict aliasing rules. This test with unions
did
> not cause extra CPU load either on the Pi. If you want to verify > this > result, enable the call to bigorsmall() instead of PD_BIGORSMALL
in
> lopass~.c and recompile. > > The fact that these tests do not cause extra CPU load, indicate
that
> they are done in parallel with other instructions. Float and int > registers are apparently strictly separated on armv6, there's no > such > thing like Intel's xmm registers or armv7's NEON. As it happens,
the
> big or small tests are done on ints, aliases of the floats that
must
> be tested. Initially I assumed that the transport of floats from
vfp
> to the arm integer processor would be expensive, but if the > instructions are done simultaneously it may be an advantage
instead.
> Another thing is that ARM implements branch predication instead of > branch prediction. Those terms look almost the same but the
routines
> are very different. Predication is when instructions for both > branches > are executed, and the wrong result is simply discarded later. > > Conclusions from the limited test with [lop~] and [lopass~] do not > mean that all sorts of conditional checks are cheap on the Pi, or
on
> ARM in general. If PD_BIGORSMALL is enabled for RPi using > compile-time > definition __arm__, it will also hold for armv7, but it may have > very > different result there. At the moment I have no access yet to an > armv7 > device. Maybe someone can recompile test class [lopass~] and do
the
> tests on Beagleboard or Cubieboard? Otherwise I may be able to do
it
> on my friend's PengPod when that has arrived. > > Katja > > > On Tue, Jan 22, 2013 at 8:54 PM, Miller Puckette msp@ucsd.edu > wrote: >> thanks - I'd better try this and find out what's going on :) >> >> M >> >> On Mon, Jan 21, 2013 at 11:54:29AM +0100, katja wrote: >>> Tried the 0.44.0 build from your website. It has the same issue >>> with >>> subnormal values. My test patch is with [lop~]. If inf or nan is >>> fed >>> into [lop~], these 'values' keep circulating in the object, it
can
>>> no >>> longer process normal signal values. >>> >>> I also tried my reverb stuff with specific compiler options for >>> Pi's >>> processor: >>> >>> -march=armv6zk >>> -mcpu=arm1176jzf-s >>> -mtune=arm1176jzf-s >>> >>> With these options, gcc should be able to decide that RunFast
mode
>>> is >>> permitted. But even in combination with -ffast-math (which in
turn
>>> sets -funsafe-math-optimizations and -fno-trapping-math amongst >>> others), denormals are still there. I'm literally out of options >>> for >>> the moment. Sorry for not having better news. >>> >>> Katja >>> >>>
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Sorry that must be my fault, archived it with default options. I'll have a look into that and let you know when a better .tar is uploaded.
Katja
On Fri, Jan 25, 2013 at 4:53 PM, Julian Brooks jbeezez@gmail.com wrote:
Hi Katja,
Thanks for this.
When I cd into bin then ./pd I get 'permission denied'. And sudo'd I get 'command not found'.
Any other ideas?
Jb
On 25 January 2013 15:36, katja katjavetter@gmail.com wrote:
Hi Julian,
Most convenient is to go in the bin directory of that 'local' Pd with
cd /place/where/new/pd/is/bin
From there you can start (and restart) the local Pd with
./pd
In my case, the recompiled Pd would not start because it could not find libportaudio.so.2. After installing libportaudio2 via Synaptic, 'normalized' Pd would finally start.
It is no problem to have the regular Pd still installed. Maybe you can install the local Pd over the regular Pd using the gnumakefile. Didn't try that, I don't like to install things without package manager.
Katja
On Fri, Jan 25, 2013 at 3:41 PM, Julian Brooks jbeezez@gmail.com wrote:
Excuse my ignorance: not sure how to start the below version of pd on the rpi?
I have the full path but then what?
if I do (in command line) pd /place/where/new/pd/is/bin/pd It signals watchdog.
I also still have regular pd 0.44.0 installed btw.
Sorry if this is dumb dumb dumb dumb Duuummmbbb.
Jb
On 24 January 2013 09:14, katja katjavetter@gmail.com wrote:
'Undenormalized' Pd build for Raspberry Pi is temporarily parked here for testing purposes (will be removed when Miller's release is fixed in this sense):
www.katjaas.nl/temp/pd-0.44-0-normalized.tar.gz
This is a locally installed Pd, like Miller's distribution. You can start it from command line with the full path to pd-0.44-0-normalized/bin/pd. It's not a .deb, so it can't be installed under supervision of package manager.
Katja
On Wed, Jan 23, 2013 at 9:15 PM, Julian Brooks jbeezez@gmail.com wrote:
Hey Katja,
Would you mind sharing the 'normalised' Pd-0.44.0 for RPi please.
Cheers,
Julian
On 23 January 2013 18:23, katja katjavetter@gmail.com wrote:
Now I recompiled the Pd-0.44.0 release on Raspberry Pi (took me a few hours, not only because Pi is so slow) with PD_BIGORSMALL enabled for arm in m_pd.h. Using bigorsmalltest.pd from my previous mail I verified that the macro is implemented indeed.
Martin Brinkmann's patch chaosmonster1 (http://www.martin-brinkmann.de) gives a beautiful illustration of the improvement. This patch is full of filters and delay lines. At it's initial settings, there is no subnormals problem. But if you set the bottom slider to the right, it gets silent. With Pd-0.44-0 release, CPU load explodes. With the 'normalized' Pd, nothing special happens.
And indeed, the PD_BIGORSMALL conditional checks come for free: with initial settings of the chaosmonster1, performance is equivalent in both Pd's. Cool! Hopefully this is similar on armv7.
Katja
On Wed, Jan 23, 2013 at 5:01 PM, Hans-Christoph Steiner hans@at.or.at wrote: > > hey Katya, > > This also sounds like good evidence for your idea of writing C > code > that > modern compilers optimize well. Using unions for aliasing allows > the > compiler > to do all the new tricks, then writing loops that auto-vectorize > gives > us the > real benefits. Also, I think we can see some gains by using > memcpy() > since on > modern libc version, those are highly optimized for the given CPU, > dynamically > choosing the routines based on what instructions are available. > memcpy > will > use things like SSSE2 if its available. > > .hc > > On 01/23/2013 07:47 AM, katja wrote: >> Finally some good news on this topic. Earlier I stated that 'big >> or >> small tests' are expensive for the Pi, but that is not by >> definition >> the case. There must have been other conditions blurring my >> impression. I've now done a systematic test where other >> influences >> are >> ruled out. A test class [lopass~] with exactly the same routine >> as >> [lop~] was made, but compiled with PD_BIGORSMALL() macro enabled. >> It >> was verified that [lopass~] is not affected by denormals. >> Performance >> comparison of [lop~] and [lopass~] shows that both objects cause >> equivalent CPU load. Meaning, Raspberry Pi gives the 'big or >> small >> checks' for free! At least in the case of this simple filter. >> Please >> try attached bigorsmalltest.zip on the Pi to see if I'm not >> dreaming. >> >> While I was at the topic anyway, I also tried a big or small test >> with >> union instead of direct type aliasing. It has the advantage that >> the >> compiler can apply strict aliasing rules. This test with unions >> did >> not cause extra CPU load either on the Pi. If you want to verify >> this >> result, enable the call to bigorsmall() instead of PD_BIGORSMALL >> in >> lopass~.c and recompile. >> >> The fact that these tests do not cause extra CPU load, indicate >> that >> they are done in parallel with other instructions. Float and int >> registers are apparently strictly separated on armv6, there's no >> such >> thing like Intel's xmm registers or armv7's NEON. As it happens, >> the >> big or small tests are done on ints, aliases of the floats that >> must >> be tested. Initially I assumed that the transport of floats from >> vfp >> to the arm integer processor would be expensive, but if the >> instructions are done simultaneously it may be an advantage >> instead. >> Another thing is that ARM implements branch predication instead >> of >> branch prediction. Those terms look almost the same but the >> routines >> are very different. Predication is when instructions for both >> branches >> are executed, and the wrong result is simply discarded later. >> >> Conclusions from the limited test with [lop~] and [lopass~] do >> not >> mean that all sorts of conditional checks are cheap on the Pi, or >> on >> ARM in general. If PD_BIGORSMALL is enabled for RPi using >> compile-time >> definition __arm__, it will also hold for armv7, but it may have >> very >> different result there. At the moment I have no access yet to an >> armv7 >> device. Maybe someone can recompile test class [lopass~] and do >> the >> tests on Beagleboard or Cubieboard? Otherwise I may be able to do >> it >> on my friend's PengPod when that has arrived. >> >> Katja >> >> >> On Tue, Jan 22, 2013 at 8:54 PM, Miller Puckette msp@ucsd.edu >> wrote: >>> thanks - I'd better try this and find out what's going on :) >>> >>> M >>> >>> On Mon, Jan 21, 2013 at 11:54:29AM +0100, katja wrote: >>>> Tried the 0.44.0 build from your website. It has the same issue >>>> with >>>> subnormal values. My test patch is with [lop~]. If inf or nan >>>> is >>>> fed >>>> into [lop~], these 'values' keep circulating in the object, it >>>> can >>>> no >>>> longer process normal signal values. >>>> >>>> I also tried my reverb stuff with specific compiler options for >>>> Pi's >>>> processor: >>>> >>>> -march=armv6zk >>>> -mcpu=arm1176jzf-s >>>> -mtune=arm1176jzf-s >>>> >>>> With these options, gcc should be able to decide that RunFast >>>> mode >>>> is >>>> permitted. But even in combination with -ffast-math (which in >>>> turn >>>> sets -funsafe-math-optimizations and -fno-trapping-math amongst >>>> others), denormals are still there. I'm literally out of >>>> options >>>> for >>>> the moment. Sorry for not having better news. >>>> >>>> Katja >>>> >>>>
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Hey,
So after rechecking my unpacking of the tar.gz it was a user-error rather than a problem with permissions. So Katja build should work fine (does here).
Best wishes,
Julian
On 25 January 2013 20:43, katja katjavetter@gmail.com wrote:
Sorry that must be my fault, archived it with default options. I'll have a look into that and let you know when a better .tar is uploaded.
Katja
On Fri, Jan 25, 2013 at 4:53 PM, Julian Brooks jbeezez@gmail.com wrote:
Hi Katja,
Thanks for this.
When I cd into bin then ./pd I get 'permission denied'. And sudo'd I get 'command not found'.
Any other ideas?
Jb
On 25 January 2013 15:36, katja katjavetter@gmail.com wrote:
Hi Julian,
Most convenient is to go in the bin directory of that 'local' Pd with
cd /place/where/new/pd/is/bin
From there you can start (and restart) the local Pd with
./pd
In my case, the recompiled Pd would not start because it could not find libportaudio.so.2. After installing libportaudio2 via Synaptic, 'normalized' Pd would finally start.
It is no problem to have the regular Pd still installed. Maybe you can install the local Pd over the regular Pd using the gnumakefile. Didn't try that, I don't like to install things without package manager.
Katja
On Fri, Jan 25, 2013 at 3:41 PM, Julian Brooks jbeezez@gmail.com
wrote:
Excuse my ignorance: not sure how to start the below version of pd on the rpi?
I have the full path but then what?
if I do (in command line) pd /place/where/new/pd/is/bin/pd It signals watchdog.
I also still have regular pd 0.44.0 installed btw.
Sorry if this is dumb dumb dumb dumb Duuummmbbb.
Jb
On 24 January 2013 09:14, katja katjavetter@gmail.com wrote:
'Undenormalized' Pd build for Raspberry Pi is temporarily parked here for testing purposes (will be removed when Miller's release is fixed in this sense):
www.katjaas.nl/temp/pd-0.44-0-normalized.tar.gz
This is a locally installed Pd, like Miller's distribution. You can start it from command line with the full path to pd-0.44-0-normalized/bin/pd. It's not a .deb, so it can't be
installed
under supervision of package manager.
Katja
On Wed, Jan 23, 2013 at 9:15 PM, Julian Brooks jbeezez@gmail.com wrote:
Hey Katja,
Would you mind sharing the 'normalised' Pd-0.44.0 for RPi please.
Cheers,
Julian
On 23 January 2013 18:23, katja katjavetter@gmail.com wrote: > > Now I recompiled the Pd-0.44.0 release on Raspberry Pi (took me a > few > hours, not only because Pi is so slow) with PD_BIGORSMALL enabled > for > arm in m_pd.h. Using bigorsmalltest.pd from my previous mail I > verified that the macro is implemented indeed. > > Martin Brinkmann's patch chaosmonster1 > (http://www.martin-brinkmann.de) gives a beautiful illustration
of
> the > improvement. This patch is full of filters and delay lines. At
it's
> initial settings, there is no subnormals problem. But if you set
the
> bottom slider to the right, it gets silent. With Pd-0.44-0
release,
> CPU load explodes. With the 'normalized' Pd, nothing special > happens. > > And indeed, the PD_BIGORSMALL conditional checks come for free:
with
> initial settings of the chaosmonster1, performance is equivalent
in
> both Pd's. Cool! Hopefully this is similar on armv7. > > Katja > > > > On Wed, Jan 23, 2013 at 5:01 PM, Hans-Christoph Steiner > hans@at.or.at > wrote: > > > > hey Katya, > > > > This also sounds like good evidence for your idea of writing C > > code > > that > > modern compilers optimize well. Using unions for aliasing
allows
> > the > > compiler > > to do all the new tricks, then writing loops that auto-vectorize > > gives > > us the > > real benefits. Also, I think we can see some gains by using > > memcpy() > > since on > > modern libc version, those are highly optimized for the given
CPU,
> > dynamically > > choosing the routines based on what instructions are available. > > memcpy > > will > > use things like SSSE2 if its available. > > > > .hc > > > > On 01/23/2013 07:47 AM, katja wrote: > >> Finally some good news on this topic. Earlier I stated that
'big
> >> or > >> small tests' are expensive for the Pi, but that is not by > >> definition > >> the case. There must have been other conditions blurring my > >> impression. I've now done a systematic test where other > >> influences > >> are > >> ruled out. A test class [lopass~] with exactly the same routine > >> as > >> [lop~] was made, but compiled with PD_BIGORSMALL() macro
enabled.
> >> It > >> was verified that [lopass~] is not affected by denormals. > >> Performance > >> comparison of [lop~] and [lopass~] shows that both objects
cause
> >> equivalent CPU load. Meaning, Raspberry Pi gives the 'big or > >> small > >> checks' for free! At least in the case of this simple filter. > >> Please > >> try attached bigorsmalltest.zip on the Pi to see if I'm not > >> dreaming. > >> > >> While I was at the topic anyway, I also tried a big or small
test
> >> with > >> union instead of direct type aliasing. It has the advantage
that
> >> the > >> compiler can apply strict aliasing rules. This test with unions > >> did > >> not cause extra CPU load either on the Pi. If you want to
verify
> >> this > >> result, enable the call to bigorsmall() instead of
PD_BIGORSMALL
> >> in > >> lopass~.c and recompile. > >> > >> The fact that these tests do not cause extra CPU load, indicate > >> that > >> they are done in parallel with other instructions. Float and
int
> >> registers are apparently strictly separated on armv6, there's
no
> >> such > >> thing like Intel's xmm registers or armv7's NEON. As it
happens,
> >> the > >> big or small tests are done on ints, aliases of the floats that > >> must > >> be tested. Initially I assumed that the transport of floats
from
> >> vfp > >> to the arm integer processor would be expensive, but if the > >> instructions are done simultaneously it may be an advantage > >> instead. > >> Another thing is that ARM implements branch predication instead > >> of > >> branch prediction. Those terms look almost the same but the > >> routines > >> are very different. Predication is when instructions for both > >> branches > >> are executed, and the wrong result is simply discarded later. > >> > >> Conclusions from the limited test with [lop~] and [lopass~] do > >> not > >> mean that all sorts of conditional checks are cheap on the Pi,
or
> >> on > >> ARM in general. If PD_BIGORSMALL is enabled for RPi using > >> compile-time > >> definition __arm__, it will also hold for armv7, but it may
have
> >> very > >> different result there. At the moment I have no access yet to
an
> >> armv7 > >> device. Maybe someone can recompile test class [lopass~] and do > >> the > >> tests on Beagleboard or Cubieboard? Otherwise I may be able to
do
> >> it > >> on my friend's PengPod when that has arrived. > >> > >> Katja > >> > >> > >> On Tue, Jan 22, 2013 at 8:54 PM, Miller Puckette <msp@ucsd.edu
> >> wrote: > >>> thanks - I'd better try this and find out what's going on :) > >>> > >>> M > >>> > >>> On Mon, Jan 21, 2013 at 11:54:29AM +0100, katja wrote: > >>>> Tried the 0.44.0 build from your website. It has the same
issue
> >>>> with > >>>> subnormal values. My test patch is with [lop~]. If inf or nan > >>>> is > >>>> fed > >>>> into [lop~], these 'values' keep circulating in the object,
it
> >>>> can > >>>> no > >>>> longer process normal signal values. > >>>> > >>>> I also tried my reverb stuff with specific compiler options
for
> >>>> Pi's > >>>> processor: > >>>> > >>>> -march=armv6zk > >>>> -mcpu=arm1176jzf-s > >>>> -mtune=arm1176jzf-s > >>>> > >>>> With these options, gcc should be able to decide that RunFast > >>>> mode > >>>> is > >>>> permitted. But even in combination with -ffast-math (which in > >>>> turn > >>>> sets -funsafe-math-optimizations and -fno-trapping-math
amongst
> >>>> others), denormals are still there. I'm literally out of > >>>> options > >>>> for > >>>> the moment. Sorry for not having better news. > >>>> > >>>> Katja > >>>> > >>>> > > _______________________________________________ > Pd-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list
-
Julian Brooks -
katja