[PD] devel_37 CVS compile error [solved, but not really...]

[derek holzer]

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 holzer ::: http://www.umatic.nl
---Oblique Strategy # 134:
"Remove a restriction"