[PD] Start Katja's Pd from command line on rpi with full path (was) Raspberry Pi does denormals

[Julian Brooks]

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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 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 at 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 at iem.at mailing list
> >> >> >> UNSUBSCRIBE and account-management ->
> >> >> >> http://lists.puredata.info/listinfo/pd-list
> >> >> >
> >> >> >
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130129/0e711dda/attachment.htm>