Cool! We've discovered something "very wrong". Here I get
number bcalc ecalc bcplx ecplx -------------------------------------------------------- 4 70 80 110 290 8 140 160 210 560 16 260 330 430 1130 32 560 660 1070 2300 64 1220 1490 3250 4720 with 0.39r4 on $ cat /proc/cpuinfo processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 7 model name : VIA Samuel 2 stepping : 3 cpu MHz : 533.507 cache size : 64 KB fdiv_bug : no hlt_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu de tsc msr cx8 mtrr pge mmx 3dnow bogomips : 1052.67 On Sat, 2 Dec 2006 17:07:28 +0100 Frank Barknecht <[EMAIL PROTECTED]> wrote: > Hallo, > padawan12 hat gesagt: // padawan12 wrote: > > > Is it just me though or is [expr ] really slow? I try to avoid it > > because almost every patch that uses [expr] on my machine runs about > > 50% slower than the equivilent arithmetic using atomic ops. > > Attached is a simple benchmark patch, which benchmarks taking the > inverse in e/b-calc. Here builtin and expr are almost the same speed, > builtin is only slightly faster. > > However as soon as you collect longer chains of calculations into one > expr-object it beats the crap out of atomic ops, as the e/b-complex > benchmark shows. If it doesn't pulp the atomic ops in your Pd > installation, then there's something very wrong. ;) > > Ciao > -- > Frank Barknecht _ ______footils.org_ __goto10.org__ > _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list