So thanks to Frank Barknecht I got onto cvs, downloaded the pd source and compiled it, easy as pie (it occurs to me that baking a pie isn't that easy, as we're about to see). So then I downloaded the externals in to my cvs/pure-data/ directory, alongside the pd directory in cvs/pure-data/ . I cd to externals/build/linux and type 'make' as per the readme. It chugs along for a bit and stopped at loudspeaker.c with a very similar error to the one below. After some thought and looking at the readme I deleted /src/loudspeaker.c and typed make again and it chugged further into unknown territories. When I had another error like the first, though, I stopped for help, because willy-nilly deletion of externals may not be the sharpest strategy. The second error is below.
../src/getenv.c:1:32: ../../motex/getenv.c: No such file or directory make: *** [getenv.pd_linux] Error 1
I then moved the externals directory into /cvs/pure-data/pd/ thinking that it was looking for a dependency in the pd directory, typed 'make clean' and tried again, with the same error. Thanks for any help, it's greatly appreciated.
-Ian Smith-Heisters
Hello,
I am getting the following compile error on the current devel_37 branch of PD from CVS:
d_dac.c: In function dac_dsp': d_dac.c:60:plus_perf8' undeclared (first use in this function)
d_dac.c:60: (Each undeclared identifier is reported only once
d_dac.c:60: for each function it appears in.)
make: *** [d_dac.o] Error 1
even with a clean ./configure & make
I'm trying to compile PD with sse2 support to get rid of denormals, but I haven't even gotten that far yet...suggestions?
Tim mentioned that he put some code to activate the DAZ switch, I assume that this is only in the devel branch, right?
d.
Hi Derek, did you run autoconf to update your configure and make files? Also, m_simd.c is a new file added to the cvs.
best greetings, Thomas
----- Original Message ----- From: "derek holzer" derek@x-i.net To: pd-list@iem.at Cc: "Tim Blechmann" TimBlechmann@gmx.net Sent: Sunday, October 10, 2004 3:08 PM Subject: [PD] devel_37 CVS compile error
Hello,
I am getting the following compile error on the current devel_37 branch of PD from CVS:
d_dac.c: In function
dac_dsp': d_dac.c:60:plus_perf8' undeclared (first use in this function) d_dac.c:60: (Each undeclared identifier is reported only once d_dac.c:60: for each function it appears in.) make: *** [d_dac.o] Error 1even with a clean ./configure & make
I'm trying to compile PD with sse2 support to get rid of denormals, but I haven't even gotten that far yet...suggestions?
Tim mentioned that he put some code to activate the DAZ switch, I assume that this is only in the devel branch, right?
d.
-- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 202: "Back up a few steps. What else could you have done?"
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
Hi Thomas,
this is exactly what I did, as a clean test. This is also happening with the "vanilla" PD CVS, so I wonder what else I might be doing wrong at this end. I've never had this problem before!!!
at what point is autoconf supposed to be run???
d.
root 17:03:56> rm -rf pd/src
root 17:04:11> cvs -z3
-d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/pure-data co -r
devel_0_37 pd
[snip!!!!]
root 17:04:28> cd pd/src/
root 17:04:32> autoconf
root 17:04:36> ./configure
creating cache ./config.cache
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for a BSD compatible install... /bin/install -c
checking whether make sets ${MAKE}... yes
checking how to run the C preprocessor... gcc -E
checking for working const... yes
checking for ANSI C header files... yes
checking for pid_t... yes
checking for size_t... yes
checking whether time.h and sys/time.h may both be included... yes
checking for ANSI C header files... (cached) yes
checking for fcntl.h... yes
checking for limits.h... yes
checking for malloc.h... yes
checking for sys/ioctl.h... yes
checking for sys/time.h... yes
checking for unistd.h... yes
checking for bstring.h... no
checking whether gcc needs -traditional... no
checking return type of signal handlers... void
checking for vprintf... yes
checking for gettimeofday... yes
checking for select... yes
checking for socket... yes
checking for strerror... yes
checking for dlopen in -ldl... yes
checking for sin in -lm... yes
checking for pthread_create in -lpthread... yes
checking for snd_pcm_info in -lasound... yes
checking for X... libraries /usr/X11R6/lib, headers
checking for XCreateWindow in -lX11... yes
checking for main in -ltcl8.7... no
checking for main in -ltcl8.6... no
checking for main in -ltcl8.5... no
checking for main in -ltcl8.4... yes
checking for main in -ltk8.4... yes
checking for tcl.h... yes
OPT_CFLAGS --------------- -O3 -funroll-loops -fomit-frame-pointer
updating cache ./config.cache
creating ./config.status
creating makefile
root 17:04:42> make
gcc -DSTDC_HEADERS=1 -DTIME_WITH_SYS_TIME=1 -DSTDC_HEADERS=1
-DHAVE_FCNTL_H=1 -DHAVE_LIMITS_H=1 -DHAVE_MALLOC_H=1
-DHAVE_SYS_IOCTL_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_UNISTD_H=1
-DRETSIGTYPE=void -DHAVE_VPRINTF=1 -DHAVE_GETTIMEOFDAY=1 -DHAVE_SELECT=1
-DHAVE_SOCKET=1 -DHAVE_STRERROR=1 -DHAVE_LIBDL=1 -DHAVE_LIBM=1
-DHAVE_LIBPTHREAD=1 -DHAVE_LIBASOUND=1 -DHAVE_LIBX11=1 -DHAVE_LIBTK8_4=1
-DPD -DUNIX -Wall -W -Wstrict-prototypes -Wno-unused -Wno-parentheses
-Wno-switch -O3 -funroll-loops -fomit-frame-pointer -DDONTUSESIMD
-DDONTUSESIMD -DPA_USE_OSS -DPA_LITTLE_ENDIAN -DUSEAPI_OSS
-I../portaudio/pa_common -I../portaudio/pablio
-I../portaudio/portmidi-macosx -fno-strict-aliasing
-DINSTALL_PREFIX="/usr/local" -I. -c -o ../obj/d_dac.o d_dac.c
d_dac.c: In function dac_dsp': d_dac.c:60:plus_perf8' undeclared (first use in this function)
d_dac.c:60: (Each undeclared identifier is reported only once
d_dac.c:60: for each function it appears in.)
make: *** [d_dac.o] Error 1
Thomas Grill wrote:
Hi Derek, did you run autoconf to update your configure and make files? Also, m_simd.c is a new file added to the cvs.
best greetings, Thomas
----- Original Message ----- From: "derek holzer" derek@x-i.net To: pd-list@iem.at Cc: "Tim Blechmann" TimBlechmann@gmx.net Sent: Sunday, October 10, 2004 3:08 PM Subject: [PD] devel_37 CVS compile error
Hello,
I am getting the following compile error on the current devel_37 branch of PD from CVS:
d_dac.c: In function
dac_dsp': d_dac.c:60:plus_perf8' undeclared (first use in this function) d_dac.c:60: (Each undeclared identifier is reported only once d_dac.c:60: for each function it appears in.) make: *** [d_dac.o] Error 1even with a clean ./configure & make
I'm trying to compile PD with sse2 support to get rid of denormals, but I haven't even gotten that far yet...suggestions?
Tim mentioned that he put some code to activate the DAZ switch, I assume that this is only in the devel branch, right?
d.
-- derek holzer ::: http://www.umatic.nl ---Oblique Strategy # 202: "Back up a few steps. What else could you have done?"
PD-list@iem.at mailing list UNSUBSCRIBE and account-management ->
d_dac.c: In function
dac_dsp': d_dac.c:60:plus_perf8' undeclared (first use in this function) d_dac.c:60: (Each undeclared identifier is reported only once d_dac.c:60: for each function it appears in.) make: *** [d_dac.o] Error 1
hmm ... i think i fixed that yesterday ... please check out, again ...
Tim mentioned that he put some code to activate the DAZ switch, I assume that this is only in the devel branch, right?
yes ... please configure with --enable-optimize=pentium4 --enable-simd
cheers ... tim
Tim Blechmann wrote:
d_dac.c: In function
dac_dsp': d_dac.c:60:plus_perf8' undeclared (first use in this function) d_dac.c:60: (Each undeclared identifier is reported only once d_dac.c:60: for each function it appears in.) make: *** [d_dac.o] Error 1hmm ... i think i fixed that yesterday ... please check out, again ...
OK, trying again!
Tim mentioned that he put some code to activate the DAZ switch, I assume that this is only in the devel branch, right?
yes ... please configure with --enable-optimize=pentium4 --enable-simd
BOOM!!!:
cc1: invalid option `tune=pentium4'
what does -mtune do, anyway???
d.
cc1: invalid option `tune=pentium4'
what does -mtune do, anyway???
hm ... old compiler ... i'll remove that ...
cheers ... tim
compiling without -mtune gives:
d_global.o(.text+0xfbc): In function sigthrow_perfsimd': : undefined reference toaccvec_sse_gcc'
collect2: ld returned 1 exit status
make: *** [../bin/pd] Error 1
d.
Tim Blechmann wrote:
d_dac.c: In function
dac_dsp': d_dac.c:60:plus_perf8' undeclared (first use in this function) d_dac.c:60: (Each undeclared identifier is reported only once d_dac.c:60: for each function it appears in.) make: *** [d_dac.o] Error 1hmm ... i think i fixed that yesterday ... please check out, again ...
Tim mentioned that he put some code to activate the DAZ switch, I assume that this is only in the devel branch, right?
yes ... please configure with --enable-optimize=pentium4 --enable-simd
cheers ... tim
d_global.o(.text+0xfbc): In function
sigthrow_perfsimd': : undefined reference toaccvec_sse_gcc' collect2: ld returned 1 exit status make: *** [../bin/pd] Error 1
has m_simd_sse_gcc.c been compiled?
currently i don't have a working build system on my machine, so i can't test ...
cheers ... tim
Tim Blechmann wrote:
d_global.o(.text+0xfbc): In function
sigthrow_perfsimd': : undefined reference toaccvec_sse_gcc' collect2: ld returned 1 exit status make: *** [../bin/pd] Error 1has m_simd_sse_gcc.c been compiled?
derek 23:16:32> find m_simd_sse_gcc* -print m_simd_sse_gcc.c m_simd_sse_gcc.h
does this have to be done seperately than the rest of the PD compile?
d.
d_global.o(.text+0xfbc): In function
sigthrow_perfsimd': : undefined reference toaccvec_sse_gcc' collect2: ld returned 1 exit status make: *** [../bin/pd] Error 1
sorry, that was a typo... corrected
best greetings, Thomas
Hi Thomas and Tim,
and thanks. I got it compiled this morning. The devel branch has a pretty font, I must say.
However, it still didn't solve my problem. A patch which runs on Linux at comfortably less than half of my Athlon XP 1.8 GHz shuttle's CPU goes *way* over the line on my P4 1.6 Ghz laptop.
I am really at wit's end trying to figure out what else I can optimize! I recompiled *every* external, plugin, etc with "-march=pentium4 -O2 -mfpmath=sse -msse -msse2 -mmmx" again yesterday, and used all the P4 optimizations which Tim has included in the cvs branch. This craptop is about to go out the window, really....
best, d.
Thomas Grill wrote:
d_global.o(.text+0xfbc): In function
sigthrow_perfsimd': : undefined reference toaccvec_sse_gcc' collect2: ld returned 1 exit status make: *** [../bin/pd] Error 1sorry, that was a typo... corrected
However, it still didn't solve my problem. A patch which runs on Linux at comfortably less than half of my Athlon XP 1.8 GHz shuttle's CPU goes *way* over the line on my P4 1.6 Ghz laptop.
this is just a ballpark guess, but a p4 1.6g is proably equivalent to something like a 1.0 or 1.2g athlon. 50% cpu in one could be 70-80 in the other, and since dropouts may happen before reaching 100 due to system/driver overhead...at least many vst hosts seem to max out before the meter does..
back in the days of WindowsXP, there was a great program called "Iarsn TaskInfo" which is like some crazy combination of gtop/gkrellm/netstat/ps and not only breaks down cpu/mem usage per process, but has a realtime cpu/mem graph for each thread and loaded library. so for example, if creb.dll is running away with CPU, or something in zexy is chewing up your RAM, you can see it quite clearly..therse similar stuff for linux (see http://kcachegrind.sourceforge.net/cgi-bin/show.cgi/KcacheGrindShot3 ), im just saying you might want to check and make sure its not something silly before chucking it out the window and buying that mobile athlon64...
I am really at wit's end trying to figure out what else I can optimize! I recompiled *every* external, plugin, etc with "-march=pentium4 -O2 -mfpmath=sse -msse -msse2 -mmmx" again yesterday, and used all the P4 optimizations which Tim has included in the cvs branch. This craptop is about to go out the window, really....
I am really at wit's end trying to figure out what else I can optimize! I recompiled *every* external, plugin, etc with "-march=pentium4 -O2 -mfpmath=sse -msse -msse2 -mmmx" again yesterday, and used all the P4 optimizations which Tim has included in the cvs branch. This craptop is about to go out the window, really....
could you try to remove the && !defined(DAZ) from m_pd.h and change in m_simd_sse_gcc.h #ifdef DAZ to #ifndef DAZ (line 49)
if you still have problems, please get rid of all externals to figure out, if the problem is still a pd problem ... also send my the output of cat /proc/cpuinfo
cheers ... tim
Tim,
could you try to remove the && !defined(DAZ) from m_pd.h and change in m_simd_sse_gcc.h #ifdef DAZ to #ifndef DAZ (line 49)
if you still have problems, please get rid of all externals to figure out, if the problem is still a pd problem ...
Recompiled with the changes you asked for, got rid of all externals [except ggge's stripfilename, which was needed to load samples into the test patch] and reloaded my "performance patch". Same problems. Climbing CPU use which kills the audio dead.
also send my the output of cat /proc/cpuinfo
derek 21:59:12> cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 1.60GHz stepping : 4 cpu MHz : 1600.381 cache size : 512 KB physical id : 0 siblings : 1 fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm bogomips : 3153.92
My assumption this whole time has been that PD under Linux is just badly optimized for the Pentium 4, and that the poor performance can be blamed on denormalized numbers and other such P4 related problems. I have in fact seen this denormal problem cripple much simpler patches than the one I am using to test with right now. In fact, if anyone has worked out a good test patch for denormals [a battery of feedback delays driven by an impulse, maybe???], could they send it this way?
However, if the following is true, then it might be time to ditch this machine as hopelessly underpowered for my needs anyway:
cdr wrote:
this is just a ballpark guess, but a p4 1.6g is proably equivalent to something like a 1.0 or 1.2g athlon. 50% cpu in one could be 70-80 in the other, and since dropouts may happen before reaching 100 due to system/driver overhead...
OTOH, I'd like to see some more...um...scientific benchmarks before I follow this line of thinking ;-)
Thanks for the help so far! d.
Tim Blechmann wrote:
I am really at wit's end trying to figure out what else I can optimize! I recompiled *every* external, plugin, etc with "-march=pentium4 -O2 -mfpmath=sse -msse -msse2 -mmmx" again yesterday, and used all the P4 optimizations which Tim has included in the cvs branch. This craptop is about to go out the window, really....
could you try to remove the && !defined(DAZ) from m_pd.h and change in m_simd_sse_gcc.h #ifdef DAZ to #ifndef DAZ (line 49)
if you still have problems, please get rid of all externals to figure out, if the problem is still a pd problem ... also send my the output of cat /proc/cpuinfo
cheers ... tim
derek 21:59:12> cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 1.60GHz stepping : 4 cpu MHz : 1600.381 cache size : 512 KB physical id : 0 siblings : 1
you seem to have a very early stepping of the processor ... 4 ... i read, that early versions of the p4 can't handle the DAZ and FTZ flags on the sse unit ... this might be a problem (sorry for that bad news)
thomas musil told me about the approach he used ... adding noise~ *~ 1e-14 to every feedback loop, filter ...
could you try that? (of course you can't do that if the feedback loop is in poorly written externals or plugins)
cheers ... tim
Hi Tim,
Tim Blechmann wrote:
derek 21:59:12> cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 15 model : 2 model name : Intel(R) Pentium(R) 4 CPU 1.60GHz stepping : 4 cpu MHz : 1600.381 cache size : 512 KB physical id : 0 siblings : 1
you seem to have a very early stepping of the processor ... 4 ... i read, that early versions of the p4 can't handle the DAZ and FTZ flags on the sse unit ... this might be a problem (sorry for that bad news)
I suspected it might be something like that. I can't imagine that *anybody* could run PD on a computer which performs as badly as this one. I do maintain, however, that PD ran better under windoze on *this* laptop than it does under Linux [i.e. no crashing denormal freezes, etc], leading me to wonder why this is the case.
thomas musil told me about the approach he used ... adding noise~ *~ 1e-14 to every feedback loop, filter ...
Yes, Thomas was the first to point out this Pentium bug. I laughed when I heard it at first, but then the processor had its revenge after all when my patches started to evolve.
could you try that? (of course you can't do that if the feedback loop is in poorly written externals or plugins)
I could try to tear everything apart and track down the individual offenders, but I've tried this before and it's a bit of a waste of time. I've also noticed that objects like [line] sometimes give trouble when set to very long interpolation times, and other such nonsense which only affects this laptop. Seems like a more "structural" solution is in order. If PD and other Linux audio apps can't be made more denormal-tolerant for this laptop, then it's probably time to replace it, espc if others aren't having the same degree of problems with their own P4s. I've been suffering for two years now with this machine, and I think that's long enough.
Thanks for your help and patience in trying to sort this out, d.
Tim,
after further testing, I can report that these changes:
could you try to remove the && !defined(DAZ) from m_pd.h and change in m_simd_sse_gcc.h #ifdef DAZ to #ifndef DAZ (line 49)
make pd_37_devel perform about the same here as a stock PD 37.1 from CVS compiled with the following flags:
-march=pentium4 -O2 -mfpmath=sse -msse -msse2 -mmmx
This probably isn't news to you, as these changes are just shutting off the DAZ switching, right?
Anyway, maybe my craptop is haunted...
d.
Tim Blechmann wrote:
I am really at wit's end trying to figure out what else I can optimize! I recompiled *every* external, plugin, etc with "-march=pentium4 -O2 -mfpmath=sse -msse -msse2 -mmmx" again yesterday, and used all the P4 optimizations which Tim has included in the cvs branch. This craptop is about to go out the window, really....
could you try to remove the && !defined(DAZ) from m_pd.h and change in m_simd_sse_gcc.h #ifdef DAZ to #ifndef DAZ (line 49)
if you still have problems, please get rid of all externals to figure out, if the problem is still a pd problem ... also send my the output of cat /proc/cpuinfo
cheers ... tim
-
cdr -
derek holzer -
Ian Smith-Heisters -
Thomas Grill -
Tim Blechmann