No subject
Thu Aug 23 10:31:50 CEST 2012
<br>
./pd<br>
<br>
In my case, the recompiled Pd would not start because it could not<br>
find libportaudio.so.2. After installing libportaudio2 via Synaptic,<br>
'normalized' Pd would finally start.<br>
<br>
It is no problem to have the regular Pd still installed. Maybe you can<br>
install the local Pd over the regular Pd using the gnumakefile. Didn't<=
br>
try that, I don't like to install things without package manager.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Katja<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
On Fri, Jan 25, 2013 at 3:41 PM, Julian Brooks <<a href=3D"mailto:jbeeze=
z at gmail.com">jbeezez at gmail.com</a>> wrote:<br>
> Excuse my ignorance:<br>
> not sure how to start the below version of pd on the rpi?<br>
><br>
> I have the full path but then what?<br>
><br>
> if I do (in command line)<br>
> pd /place/where/new/pd/is/bin/pd<br>
> It signals watchdog.<br>
><br>
> I also still have regular pd 0.44.0 installed btw.<br>
><br>
> Sorry if this is dumb dumb dumb dumb Duuummmbbb.<br>
><br>
> Jb<br>
><br>
> On 24 January 2013 09:14, katja <<a href=3D"mailto:katjavetter at gmai=
l.com">katjavetter at gmail.com</a>> wrote:<br>
>><br>
>> 'Undenormalized' Pd build for Raspberry Pi is temporarily =
parked here<br>
>> for testing purposes (will be removed when Miller's release is=
fixed<br>
>> in this sense):<br>
>><br>
>> <a href=3D"http://www.katjaas.nl/temp/pd-0.44-0-normalized.tar.gz"=
target=3D"_blank">www.katjaas.nl/temp/pd-0.44-0-normalized.tar.gz</a><br>
>><br>
>> This is a locally installed Pd, like Miller's distribution. Yo=
u can<br>
>> start it from command line with the full path to<br>
>> pd-0.44-0-normalized/bin/pd. It's not a .deb, so it can't =
be installed<br>
>> under supervision of package manager.<br>
>><br>
>> Katja<br>
>><br>
>><br>
>> On Wed, Jan 23, 2013 at 9:15 PM, Julian Brooks <<a href=3D"mail=
to:jbeezez at gmail.com">jbeezez at gmail.com</a>> wrote:<br>
>> > Hey Katja,<br>
>> ><br>
>> > Would you mind sharing the 'normalised' Pd-0.44.0 for=
RPi please.<br>
>> ><br>
>> > Cheers,<br>
>> ><br>
>> > Julian<br>
>> ><br>
>> ><br>
>> ><br>
>> > On 23 January 2013 18:23, katja <<a href=3D"mailto:katjave=
tter at gmail.com">katjavetter at gmail.com</a>> wrote:<br>
>> >><br>
>> >> Now I recompiled the Pd-0.44.0 release on Raspberry Pi (t=
ook me a few<br>
>> >> hours, not only because Pi is so slow) with PD_BIGORSMALL=
enabled for<br>
>> >> arm in m_pd.h. Using bigorsmalltest.pd from my previous m=
ail I<br>
>> >> verified that the macro is implemented indeed.<br>
>> >><br>
>> >> Martin Brinkmann's patch chaosmonster1<br>
>> >> (<a href=3D"http://www.martin-brinkmann.de" target=3D"_bl=
ank">http://www.martin-brinkmann.de</a>) gives a beautiful illustration of =
the<br>
>> >> improvement. This patch is full of filters and delay line=
s. At it's<br>
>> >> initial settings, there is no subnormals problem. But if =
you set the<br>
>> >> bottom slider to the right, it gets silent. With Pd-0.44-=
0 release,<br>
>> >> CPU load explodes. With the 'normalized' Pd, noth=
ing special happens.<br>
>> >><br>
>> >> And indeed, the PD_BIGORSMALL conditional checks come for=
free: with<br>
>> >> initial settings of the chaosmonster1, performance is equ=
ivalent in<br>
>> >> both Pd's. Cool! Hopefully this is similar on armv7.<=
br>
>> >><br>
>> >> Katja<br>
>> >><br>
>> >><br>
>> >><br>
>> >> On Wed, Jan 23, 2013 at 5:01 PM, Hans-Christoph Steiner &=
lt;<a href=3D"mailto:hans at at.or.at">hans at at.or.at</a>><br>
>> >> wrote:<br>
>> >> ><br>
>> >> > hey Katya,<br>
>> >> ><br>
>> >> > This also sounds like good evidence for your idea of=
writing C code<br>
>> >> > that<br>
>> >> > modern compilers optimize well. =A0Using unions for =
aliasing allows the<br>
>> >> > compiler<br>
>> >> > to do all the new tricks, then writing loops that au=
to-vectorize<br>
>> >> > gives<br>
>> >> > us the<br>
>> >> > real benefits. =A0Also, I think we can see some gain=
s by using memcpy()<br>
>> >> > since on<br>
>> >> > modern libc version, those are highly optimized for =
the given CPU,<br>
>> >> > dynamically<br>
>> >> > choosing the routines based on what instructions are=
available.<br>
>> >> > memcpy<br>
>> >> > will<br>
>> >> > use things like SSSE2 if its available.<br>
>> >> ><br>
>> >> > .hc<br>
>> >> ><br>
>> >> > On 01/23/2013 07:47 AM, katja wrote:<br>
>> >> >> Finally some good news on this topic. Earlier I =
stated that 'big or<br>
>> >> >> small tests' are expensive for the Pi, but t=
hat is not by definition<br>
>> >> >> the case. There must have been other conditions =
blurring my<br>
>> >> >> impression. I've now done a systematic test =
where other influences<br>
>> >> >> are<br>
>> >> >> ruled out. A test class [lopass~] with exactly t=
he same routine as<br>
>> >> >> [lop~] was made, but compiled with PD_BIGORSMALL=
() macro enabled. It<br>
>> >> >> was verified that [lopass~] is not affected by d=
enormals.<br>
>> >> >> Performance<br>
>> >> >> comparison of [lop~] and [lopass~] shows that bo=
th objects cause<br>
>> >> >> equivalent CPU load. Meaning, Raspberry Pi gives=
the 'big or small<br>
>> >> >> checks' for free! At least in the case of th=
is simple filter. Please<br>
>> >> >> try attached bigorsmalltest.zip on the Pi to see=
if I'm not<br>
>> >> >> dreaming.<br>
>> >> >><br>
>> >> >> While I was at the topic anyway, I also tried a =
big or small test<br>
>> >> >> with<br>
>> >> >> union instead of direct type aliasing. It has th=
e advantage that the<br>
>> >> >> compiler can apply strict aliasing rules. This t=
est with unions did<br>
>> >> >> not cause extra CPU load either on the Pi. If yo=
u want to verify<br>
>> >> >> this<br>
>> >> >> result, enable the call to bigorsmall() instead =
of PD_BIGORSMALL in<br>
>> >> >> lopass~.c and recompile.<br>
>> >> >><br>
>> >> >> The fact that these tests do not cause extra CPU=
load, indicate that<br>
>> >> >> they are done in parallel with other instruction=
s. Float and int<br>
>> >> >> registers are apparently strictly separated on a=
rmv6, there's no<br>
>> >> >> such<br>
>> >> >> thing like Intel's xmm registers or armv7=
9;s NEON. As it happens, the<br>
>> >> >> big or small tests are done on ints, aliases of =
the floats that must<br>
>> >> >> be tested. Initially I assumed that the transpor=
t of floats from vfp<br>
>> >> >> to the arm integer processor would be expensive,=
but if the<br>
>> >> >> instructions are done simultaneously it may be a=
n advantage instead.<br>
>> >> >> Another thing is that ARM implements branch pred=
ication instead of<br>
>> >> >> branch prediction. Those terms look almost the s=
ame but the routines<br>
>> >> >> are very different. Predication is when instruct=
ions for both<br>
>> >> >> branches<br>
>> >> >> are executed, and the wrong result is simply dis=
carded later.<br>
>> >> >><br>
>> >> >> Conclusions from the limited test with [lop~] an=
d [lopass~] do not<br>
>> >> >> mean that all sorts of conditional checks are ch=
eap on the Pi, or on<br>
>> >> >> ARM in general. If PD_BIGORSMALL is enabled for =
RPi using<br>
>> >> >> compile-time<br>
>> >> >> definition __arm__, it will also hold for armv7,=
but it may have<br>
>> >> >> very<br>
>> >> >> different result there. At the moment I have no =
access yet to an<br>
>> >> >> armv7<br>
>> >> >> device. Maybe someone can recompile test class [=
lopass~] and do the<br>
>> >> >> tests on Beagleboard or Cubieboard? Otherwise I =
may be able to do it<br>
>> >> >> on my friend's PengPod when that has arrived=
.<br>
>> >> >><br>
>> >> >> Katja<br>
>> >> >><br>
>> >> >><br>
>> >> >> On Tue, Jan 22, 2013 at 8:54 PM, Miller Puckette=
<<a href=3D"mailto:msp at ucsd.edu">msp at ucsd.edu</a>><br>
>> >> >> wrote:<br>
>> >> >>> thanks - I'd better try this and find ou=
t what's going on :)<br>
>> >> >>><br>
>> >> >>> M<br>
>> >> >>><br>
>> >> >>> On Mon, Jan 21, 2013 at 11:54:29AM +0100, ka=
tja wrote:<br>
>> >> >>>> Tried the 0.44.0 build from your website=
. It has the same issue<br>
>> >> >>>> with<br>
>> >> >>>> subnormal values. My test patch is with =
[lop~]. If inf or nan is<br>
>> >> >>>> fed<br>
>> >> >>>> into [lop~], these 'values' keep=
circulating in the object, it can<br>
>> >> >>>> no<br>
>> >> >>>> longer process normal signal values.<br>
>> >> >>>><br>
>> >> >>>> I also tried my reverb stuff with specif=
ic compiler options for<br>
>> >> >>>> Pi's<br>
>> >> >>>> processor:<br>
>> >> >>>><br>
>> >> >>>> -march=3Darmv6zk<br>
>> >> >>>> -mcpu=3Darm1176jzf-s<br>
>> >> >>>> -mtune=3Darm1176jzf-s<br>
>> >> >>>><br>
>> >> >>>> With these options, gcc should be able t=
o decide that RunFast mode<br>
>> >> >>>> is<br>
>> >> >>>> permitted. But even in combination with =
-ffast-math (which in turn<br>
>> >> >>>> sets -funsafe-math-optimizations and -fn=
o-trapping-math amongst<br>
>> >> >>>> others), denormals are still there. I=
9;m literally out of options<br>
>> >> >>>> for<br>
>> >> >>>> the moment. Sorry for not having better =
news.<br>
>> >> >>>><br>
>> >> >>>> Katja<br>
>> >> >>>><br>
>> >> >>>><br>
>> >><br>
>> >> _______________________________________________<br>
>> >> <a href=3D"mailto:Pd-list at iem.at">Pd-list at iem.at</a> mail=
ing list<br>
>> >> UNSUBSCRIBE and account-management -><br>
>> >> <a href=3D"http://lists.puredata.info/listinfo/pd-list" t=
arget=3D"_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
>> ><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br>
--20cf3078104c9284be04d41eeedd--
More information about the Pd-list
mailing list