So still lost at compilinc cyclone...
And i only need prepend to get memento running !!!!!
Error 1.
If i go to .../pd-cvs/build/linux and type make the compilation breaks because of something missing. i removed the *.c files that created the error
The rest gives me a lot of funky *.pd_linux stuff, but where is the hammer library ???
Error 2. i go by hand into the directory /usr/local/src/pd-externals_cvs/miXed/cyclone type make
and it gives me gcc-2.95 -Wall -W -Wstrict-prototypes -Werror -Wno-unused -Wno-parentheses -Wno-switch -O6 -funroll-loops -fomit-frame-pointer -DUNIX -I. -I../../../pd/src -I../shared -c -o hammer/testmess.o hammer/testmess.c make: gcc-2.95: Kommando nicht gefunden. make: *** [hammer/testmess.o] Fehler 127
I WANT HAMMER !!!
Still did not go to bed yet ;-0
Cheers
Hallo, luigi.rensinghoff hat gesagt: // luigi.rensinghoff wrote:
So still lost at compilinc cyclone...
And i only need prepend to get memento running !!!!!
Try "make prepend.pd_linux" in externals/build/linux, maybe you're already have it.
Error 1.
If i go to .../pd-cvs/build/linux and type make the compilation breaks because of something missing. i removed the *.c files that created the error
The rest gives me a lot of funky *.pd_linux stuff, but where is the hammer library ???
You don't need it, the *.pd_linux files include the Cyclone externals as single files. You only need the libraries for certain things like importing Max-files.
Error 2. i go by hand into the directory /usr/local/src/pd-externals_cvs/miXed/cyclone type make
and it gives me gcc-2.95 -Wall -W -Wstrict-prototypes -Werror -Wno-unused -Wno-parentheses -Wno-switch -O6 -funroll-loops -fomit-frame-pointer -DUNIX -I. -I../../../pd/src -I../shared -c -o hammer/testmess.o hammer/testmess.c make: gcc-2.95: Kommando nicht gefunden. make: *** [hammer/testmess.o] Fehler 127
Try "grep -l gcc-32.95" and edit the resulting file. Comment out the line containing gcc-2.95 with a # after that it should work. But you probably already have prepend.pd_linux in the build-dir.
I WANT HAMMER !!!
If I had a hammer <doohdooh, doohoo> I'd hammer in the morning <doodooh, doodooh> hammer in the evening
<dududuhduduh> hammer all day <lalala la la>
;)
Ciao
Frank Barknecht _ ______footils.org__
hi again luigi,
I really think you should get
http://suita.chopin.edu.pl/~czaja/miXed/externs/cyclone-0.1-alpha49-bin37.ta...
and from this one unpacked, copy whatever you need into your externals directory.
In case you still insist on building cyclone without having gcc-2.95 in your system, you will have to edit the file miXed/Makefile.common:
- delete the line ``CC = gcc-2.95''
- search for ``-Werror'' down there, and get rid of it as well
Btw, the reason for cyclone insisting on gcc-2.95 is that the cyclone's check for denormals, which is the same as in Pd itself, is optimized away by gcc-3.3, and I do not know about anybody out there, that has solved this problem yet...
Krzysztof
luigi.rensinghoff wrote: ...
make: gcc-2.95: Kommando nicht gefunden.
On Fri, 25 Jun 2004, Krzysztof Czaja wrote:
Btw, the reason for cyclone insisting on gcc-2.95 is that the cyclone's check for denormals, which is the same as in Pd itself, is optimized away by gcc-3.3, and I do not know about anybody out there, that has solved this problem yet...
You mean PD_BADFLOAT ? I just tested this with gcc 3.3.4 from Debian and it seems to work. at least this clause:
int i; float f = 0.0001;
for (i=0;i<25;i++) { f*=0.0001; if (PD_BADFLOAT(f)) f = 0; else printf("%d goodfloat %f\n",i,f); }
only prints 8 goodfloat values. Well, maybe it depends more on the context, who knows. I didn't try really hard to prove its working/non-working, I have to admit.
Guenter
hi Guenter,
this fails, though:
int result[25];
void pass1(void) { int i; float f = 0.0001, *fp = &f;
for (i=0;i<25;i++) {
*fp*=0.0001;
if (PD_BADFLOAT(*fp)) result[i] = 1;
else result[i] = 0;
}
}
void pass2(void) { int i; float f = 0.0001; for (i=0;i<25;i++) { f*=0.0001; if (result[i]) printf("%d badfloat %g %08x\n",i,f,*(int*)&f); else printf("%d goodfloat %g %08x\n",i,f,*(int*)&f); } }
If compiled with "gcc-3.3 -O6...", you will get:
... 8 goodfloat 9.99995e-41 000116c2 9 goodfloat 9.80909e-45 00000007 ...
while without "-O6" it works ok. The bottom line is, that I do not know the rules (if there are any).
Krzysztof
guenter geiger wrote: ...
I just tested this with gcc 3.3.4 from Debian and it seems to work.
Hallo, Krzysztof Czaja hat gesagt: // Krzysztof Czaja wrote:
while without "-O6" it works ok. The bottom line is, that I do not know the rules (if there are any).
This one was posted by Simon Jenkins last week on linux-audio-dev:
I (re)discovered the following branch-free method a while ago:
/* branch-free denormal killer (slightly blunt) */
inline float FlushToZero( volatile float f )
{
f += 9.8607615E-32f;
return f - 9.8607615E-32f;
}
/* end */
The people who discovered it first call this method "Elimination
by Quantification".
Its slightly blunt because it damages the precision of extremely
low but not yet denormal numbers: Anything of magnitude < 2 **
-103 loses one bit of precision for each binary order of magnitude
it is below that number. (This means that denormal numbers lose
/all/ of their precision and become zero).
Simon Jenkins
(Bristol, UK)
He later added:
The reason its an inline function rather than a drop-in
replacement macro is because casting macro arguments to volatile
wasn't having the desired effect on the optimiser, whereas this
does.
Maybe it's an alternative to consider in some cases?
Ciao
Frank Barknecht _ ______footils.org__
hi all,
pd's handling of denormals could definitely be inproved ...
the question is, if a branch free algorithm improves the performance... the quantization relies on two floating point performances, if the number is a denormal, it will cause one denormal operation. the PD_BADFLOAT macro does no floating point operation at all ...
another branch free possibility would be to do something like:
f*= !PD_BADFLOAT(f);
which would be branch free. the question is, it that would cause a denormal operation, concerning jan depner, it depends on the compiler, but pd is supposed to built on various compilers (gcc, icc, msvc ...)
it would probably be neccessary to do a few benchmarks in order to figure out, what's giving the best performance ... the most efficient solution would probably be to rewrite the specific functions using sse instructions if available, on the specific platform...
cheers ... tim
another branch free possibility would be to do something like:
f*= !PD_BADFLOAT(f);
which would be branch free.
Hmmm, but the PD_BADFLOAT macro isn't branch free at the moment, so the above code won't be either.
#define IS_ALMOST_DENORMAL(f) (fabs(f) < 3.e-34)
well, isn't this, what the PD_BADFLOAT is doing?
No, in devel_0_37 this is (((*(unsigned int*)&(f))&0x7f800000) < 0x08000000), which means that the mantissa is tested for leading bits (real denormals). However, the question is if all almost denormals can be realiably bashed to zero before they become real denormals and stress the cpu.
best greetings, Thomas
Hi all, am i right suspecting that only the first half of the PD_BADFLOAT macro is optimized away? (because otherwise the optimizer were buggy, weren't it?) Then, there's another possibility to test for almost denormals, suggested on the musicdsp site:
#define IS_ALMOST_DENORMAL(f) (fabs(f) < 3.e-34)
probably that's not much slower on modern cpus... should be profiled though
best, Thomas
----- Original Message ----- From: "Krzysztof Czaja" czaja@chopin.edu.pl To: "guenter geiger" geiger@xdv.org Cc: pd-list@iem.at Sent: Saturday, June 26, 2004 5:14 PM Subject: Re: [PD] Lost at compilig cyclone ;-((((
hi Guenter,
this fails, though:
int result[25];
void pass1(void) { int i; float f = 0.0001, *fp = &f;
for (i=0;i<25;i++) { *fp*=0.0001; if (PD_BADFLOAT(*fp)) result[i] = 1; else result[i] = 0; }}
void pass2(void) { int i; float f = 0.0001; for (i=0;i<25;i++) { f*=0.0001; if (result[i]) printf("%d badfloat %g %08x\n",i,f,*(int*)&f); else printf("%d goodfloat %g %08x\n",i,f,*(int*)&f); } }
If compiled with "gcc-3.3 -O6...", you will get:
... 8 goodfloat 9.99995e-41 000116c2 9 goodfloat 9.80909e-45 00000007 ...
while without "-O6" it works ok. The bottom line is, that I do not know the rules (if there are any).
Krzysztof
guenter geiger wrote: ...
I just tested this with gcc 3.3.4 from Debian and it seems to work.
PD-list mailing list PD-list@iem.at to manage your subscription (including un-subscription) see http://iem.at/cgi-bin/mailman/listinfo/pd-list
am i right suspecting that only the first half of the PD_BADFLOAT macro is optimized away? (because otherwise the optimizer were buggy, weren't it?) Then, there's another possibility to test for almost denormals, suggested on the musicdsp site:
#define IS_ALMOST_DENORMAL(f) (fabs(f) < 3.e-34)
well, isn't this, what the PD_BADFLOAT is doing?
cheers ... tim
On Fri, 25 Jun 2004, luigi.rensinghoff wrote:
The rest gives me a lot of funky *.pd_linux stuff, but where is the hammer library ???
The funky pd_linux stuff are the externals compiled on linux. The same files have the extension .dll on windows or .pd_darwin od OSX (pd_irix5 on SGI aso.) Externals are binary files that act like pd abstractions (funky .pd files).
Cyclone is not included in the general build system, because it is not a standalone external, but a library (a collection of externals)
Guenter
Hallo, guenter geiger hat gesagt: // guenter geiger wrote:
Cyclone is not included in the general build system, because it is not a standalone external, but a library (a collection of externals)
Ah, you're right, I'm sorry for the confusion, I might have cause by this...
But maybe Cyclone could go into the build system as well?
Ciao
Frank Barknecht _ ______footils.org__
On Fri, 25 Jun 2004, Frank Barknecht wrote:
But maybe Cyclone could go into the build system as well?
Well, as I see it there are two reasons why it is not there yet. One is purely technical. We decided that only single externals go into that section. The section is huge, and having single externals is important to keep it maintainable and to to keep the memory footprint low. I am not sure if cyclone can be compiled as single externals collection.
The other reason it time. Putting externals there and maintaining it costs time. A precious good ... there are so many things and ideas I actually had for the external collection which I just can't realize because of lack of time, or because I want to spend some part of my time without a computer :(
Guenter
-
Frank Barknecht -
guenter geiger -
Krzysztof Czaja -
luigi.rensinghoff -
Thomas Grill -
Tim Blechmann