similar to: [LLVMdev] -msse3 can degrade performance

On Saturday 31 January 2009 03:42:04 Eli Friedman wrote: > On Fri, Jan 30, 2009 at 5:43 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > > I just remembered an anomalous result that I stumbled upon whilst > > tweaking the command-line options to llvm-gcc. Specifically, the -msse3 > > flag > > The -msse3 flag? Does the -msse2 flag have a similar effect? Yes: $

On Feb 2, 2009, at 3:00 PM, Jon Harrop wrote: > On Monday 02 February 2009 20:37:47 you wrote: >> On Feb 2, 2009, at 12:39 PM, Jon Harrop wrote: >>> On Monday 02 February 2009 06:10:26 Chris Lattner wrote: >>>> I'm seeing exactly identical .s files with -msse2 and -msse3 on the >>>> scimark version I have. Can you please send the output of:

On Fri, Jan 30, 2009 at 5:43 PM, Jon Harrop <jon at ffconsultancy.com> wrote: > > I just remembered an anomalous result that I stumbled upon whilst tweaking the > command-line options to llvm-gcc. Specifically, the -msse3 flag The -msse3 flag? Does the -msse2 flag have a similar effect? -Eli

FYI, Yesterday's Slashdot had an article about Linux compiler benchmarks from Coyote Gulch (Scott Ladd). In this update he compares GCC and ICC. You can read the article here: http://www.coyotegulch.com/reviews/linux_compilers/ Of particular note was his use of SciMark 2.0 which is a NIST developed benchmark for scientific computing. Its available in both java and C and computes a MFLOPS

----- Original Message ----- From: "Jon Harrop" <jon at ffconsultancy.com> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Saturday, January 31, 2009 6:56 AM Subject: [LLVMdev] Performance vs other VMs > > The release of a new code generator in Mono 2.2 prompted me to benchmark > the > performance of various VMs using the SciMark2

Reid Spencer wrote: > FYI, > > Yesterday's Slashdot had an article about Linux compiler benchmarks from > Coyote Gulch (Scott Ladd). In this update he compares GCC and ICC. You > can read the article here: > http://www.coyotegulch.com/reviews/linux_compilers/ > > Of particular note was his use of SciMark 2.0 which is a NIST developed > benchmark for scientific

The release of a new code generator in Mono 2.2 prompted me to benchmark the performance of various VMs using the SciMark2 benchmark on an 8x 2.1GHz 64-bit Opteron and I have published the results here: http://flyingfrogblog.blogspot.com/2009/01/mono-22.html The LLVM results were generated using llvm-gcc 4.2.1 on the C version of SciMark2 with the following command-line options: llvm-gcc

Duncan, Do a quick check here on x86_64-apple-darwin10 with svn llvm and svn dragon-egg against release gcc 4.5.0, the results from the himenoBMTxpa benchmark compiled at -O3 look pretty good. With stock gcc-4.5.0, we get... Grid-size = M mimax = 128 mjmax = 128 mkmax = 256 imax = 127 jmax = 127 kmax =255 Start rehearsal measurement process. Measure the performance in 3 times. MFLOPS:

I finally got around to testing this on a Bloomfield processor (Early 2009 MacPro 2x2.66 GHz dual-quad core) and the regressions from http://llvm.org/bugs/show_bug.cgi?id=22589 are even more severe. For 10 runs of scimark2_1c built with "-O3 -march=native"... llvm 3.5.1 1204.16+/-2.66 Mflops 3.6 branch 866.49+/-1.26 Mflops Do you seriously want to ship with a 39% performance

They claim to max out at 1,800 MFLOPs And have a clock speed of up to 300 mhz. Jean-Marc Valin wrote: >Tell me how fast these chips are, I'll tell you if there's a chance... > > Jean-Marc > >Le jeu 18/12/2003 à 16:52, David Siebert a écrit : > > >>Anyone have any idea if the any of the Sharc or TigerSHARC DSPs are >>powerful enough to do realtime Speex?

Hello Developers, I am considering using SPEEX on an embedded processor that does not have a floating point unit. Does anybody have a SPEEX performance characterization on a fixed point processor? More specifically, I am interested in knowing how the MFLOPS values from Table 9.2 in the manual translate to fixed-point instructions when SPEEX is compiled with enable-fixed-point option. Any help

Hi, I have a module sampling raw PCM data on Win CE as 10ms time slice (160 bytes), mono, 8000HZ, 16 bits per sample. Does anyone know what is the mflops for using fixed point on a Win CE compared to using floating point? Looking at the manual, "In practice, frame_size will correspond to 20 ms when using 8, 16, or 32 kHz sampling rate." for a 8 kHz sampling, the framesize should be

Now that dragoneegg is robust in its default usage and the dragonegg svn is moderately stable with -fplugin-arg-dragonegg-enable-gcc-optzns, it is possible to gauge the impact of that feature. Comparing clang 2.9, FSF gcc 4.5.3svn, FSF gcc 4.6.0 and dragonegg svn with FSF gcc 4.5.3svn using the himenoBMTxpa benchmark, the enhancement to code performance from

On Sat, Jun 04, 2005 at 08:00:45AM -0700, Ralph Giles wrote: > The replay gain code has dos line endings in CVS, which causes problems > for the Sun compiler, among others. Attached is a patch for the lazy, > but it's probably easier to fix locally and commit. Now with actual patch... -r -------------- next part -------------- Index:

Hi Jack, > Now that dragoneegg is robust in its default usage and the dragonegg svn > is moderately stable with -fplugin-arg-dragonegg-enable-gcc-optzns, it is > possible to gauge the impact of that feature. Comparing clang 2.9, FSF gcc 4.5.3svn, > FSF gcc 4.6.0 and dragonegg svn with FSF gcc 4.5.3svn using the himenoBMTxpa benchmark, > the enhancement to code performance from

Hi Peter, > Why not do this too? I've applied this - thanks for the patch! Ciao, Duncan.

Hi all, i've to encode voice from a voicemodem. I choose speex 1.0.5 for its quality in voice encoding. I've tried to implement an encoder but unsuccesfully. Here's my code: /* ============ SPEEX stream ENCODER ============================================ */ int SPEEX_EncodePCM(struct _IDA_ClientSocket *IDA,char *buffer,unsigned char *PCM,int num_samples) { /* buffer point to the

I am seeing the same problems using 'llvm-ld' with llvm-gcc at -O4 on x86_64 Fedora 8 linux as on Darwin. Another example of this is building the scimark2_1c benchmark... http://math.nist.gov/scimark2/download_c.html as follows on x86_64 Fedora 8... /home/howarth/llvm-gcc42-work/bin/gcc -O4 -m64 -c FFT.c /home/howarth/llvm-gcc42-work/bin/gcc -O4 -m64 -c kernel.c

dear r-experts: I need to speed up my monte-carlo simulations. my code is written in R (and it was also the cause of my many questions here over the last few days). my code is almost all matrix/vector algebra on panel data sets---long-difference, fixed-effects, blundell-bond, etc.. the data set is about 10MB, so 1GB per CPU core should be plenty for my operations, and with $10/GB of

Dear R Users, Any insights into why the following occurs would be helpful.... Firstly: #Evaluating proportions p<-as.list(rep(0,times=length(n))) #creating object of appropriate size. for(j in 1:length(n)){ for(k in 1:length(n[[j]])){ p[[j]][[k]]<- (s[[j]][[k]]/n[[j]][k])}} # 31 x k x num_samples(dim) where k varies The list object s[[j]][[k]] has 3 levels, j, k, and i. j represents the