similar to: [LLVMdev] Help adding the Bullet physics sdk benchmark to the LLVM test suite?

Hello, Erwin > The physics engine includes collision detection, rigid body dynamics and > soft body dynamics. This sounds really promising addition to LLVM testsuite! > to compile our source tree and benchmarks. Bullet 2.75 uses a lot of > SIMD-friendly vector operations, Which archs are currently supported for SIMD operations? > The SDK is under Bullet/src and the benchmarks

Hi Anton, Thanks a lot for offering help. Bullet uses basic linear algebra with 4-way vectors, quaternion and matrices. Although most of this is plain portable C++ perhaps LLVM can auto-vectorize some of this? There is a little bit of hand optimized x86 SSE code. This is only enabled on 32bit Windows and Mac OSX Intel builds. >> Should I just use the 2.75 release? If you are interested,

Hello, Erwin > If you are interested, I think it is best to start with Bullet 2.75. > If it turns out that LLVM requires some modifications (due to current C++ > limitations), > we can modify Bullet and go for an uncoming release such as Bullet 2.76 > (planned around January 2010). I added bullet to LLVM testsuite. Basically I had to flatten source directories since this is a

The linux builds are not using SSE right now, but the vector data is 16-byte aligned on all platforms. So if you port this SSE code to another platform (Linux, Altivec, NEON), you could contribute it back to Bullet? The most interesting SSE part is the innerloop of the constraint solver: http://tinyurl.com/ydoapct Some developers replaced some linear algebra functions (in Bullet/LinearMath) with

Hello, Erwin > So if you port this SSE code to another platform (Linux, Altivec, > NEON), you could contribute it back to Bullet? I believe this should work as-is on linux. Am I missing something? > optimizations, but haven't contributed this back. > This NEON/VFP, part of the an open source iPhone project, could be a > starting point for this: > http://tinyurl.com/y9gv3e8

Hi Anton, and happy new year all, >>One questions though: is it possible to "verify" the results of all >>the computations somehow? Good point, and there is no automated way currently, but we can work on that. Note that simulation suffers from the 'butterfly effect', so the smallest change anywhere, (cpu, compiler etc) diverges into totally different results after a

Hello, Erwin > Although most of this is plain portable C++ perhaps LLVM can auto-vectorize > some of this? Well, I doubt so, unfortunately - LLVM does not have any autopar these days > There is a little bit of hand optimized x86 SSE code. This is only enabled > on 32bit Windows and Mac OSX Intel builds. Ok. What's about Linux builds? Are there any other implementations e.g.

On Tuesday 05 January 2010 15:57, Dan Gohman wrote: > On Jan 5, 2010, at 1:38 PM, David Greene wrote: > > I don't think there's a flag that says "don't do anything risky, > > ever." > > "Don't do anything risky with floating-point" is the default mode. If > you're aware of any unsafe floating-point optimizations being done by >

We haven't determined what 'failing' means or what the 'correct' behaviour is. Imagine a ball at the top of a rounded hill. If the ball is not exactly at the top but a tiny amount on the left it will roll left, but a tiny amount on the right it will roll right. The difference in initial position can be negligible but the final result is miles away. Is there a irc channel or

On Jan 5, 2010, at 1:38 PM, David Greene wrote: > I don't think there's a flag that says "don't do anything risky, > ever." "Don't do anything risky with floating-point" is the default mode. If you're aware of any unsafe floating-point optimizations being done by default, please file a bug. > For example, a gfortran-fronted LLVM should have a way

On Dec 15, 2009, at 5:15 PM, Erwin Coumans wrote: > The linux builds are not using SSE right now, but the vector data is > 16-byte aligned on all platforms. > So if you port this SSE code to another platform (Linux, Altivec, > NEON), you could contribute it back to Bullet? > The most interesting SSE part is the innerloop of the constraint > solver: http://tinyurl.com/ydoapct

How do other benchmarks deal with unstable algorithms or differences in floating point results? >> haven't been following this thread, but this sounds like a typical >> unstable algorithm problem. Are you always operating that close to >> the tolerance level of the algorithm or are there some sets of inputs >> that will behave reasonably? What do you mean by

Hello, Erwin > I suggest working on a better benchmark that tests independent parts of the > pipeline, > so we don't accumulate results (several frames) but we test a single > algorithm at a time, > with known input and expected output. This avoid unstability and we can > measure the error of the output. > Anton, are you interested in working together on such improved

On Tuesday 05 January 2010 14:53, Erwin Coumans wrote: > How do other benchmarks deal with unstable algorithms or differences in > floating point results? > > >> haven't been following this thread, but this sounds like a typical > >> unstable algorithm problem. Are you always operating that close to > >> the tolerance level of the algorithm or are there

Hello, Everyone > Sounds like a very interesting SSE test. I'm working on it. Hopefully it will be added today or tomorrow to LLVM testsuite. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Eliminate undefined references to powf, sqrtf and friends. Index: MultiSource/Benchmarks/Bullet/Makefile =================================================================== --- MultiSource/Benchmarks/Bullet/Makefile (revision 92512) +++ MultiSource/Benchmarks/Bullet/Makefile (working copy) @@ -1,7 +1,7 @@ LEVEL = ../../../ PROG = bullet CPPFLAGS += -I$(PROJ_SRC_DIR)/include -DNO_TIME -LDFLAGS

Index: MultiSource/Benchmarks/Bullet/Makefile =================================================================== --- MultiSource/Benchmarks/Bullet/Makefile (revision 92478) +++ MultiSource/Benchmarks/Bullet/Makefile (working copy) @@ -1,6 +1,6 @@ LEVEL = ../../../ PROG = bullet -CPPFLAGS += -Iinclude -DNO_TIME +CPPFLAGS += -I$(PROJ_SRC_DIR)/include -DNO_TIME LDFLAGS = -lstdc++ include

Hi. I was wondering if anyone has compiled Bullet Physics for WindRiver's vxWorks (or know of anyone who may have done so). Any insight / info / help would be very much appreciated. Thanks! -Ryan (aka keppy) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100120/53f5b439/attachment.html>

We are the marketing specialists www.host4bulk.com that provide cheap bullet proof bulk email friendly hosting for your website ($400 for one month of bullet proof hosting) and cheap bulk email campaigns ($200 for 1 million emails sent) As you may already know, many web hosting companies have Terms of Service (TOS) or Acceptable Use Policies (AUP) against the delivery of emails advertising or

Hi, LLVM’s SLP-vectorizer is a new pass that combines similar independent instructions in a straight-line code. It is currently not enabled by default, and people who want to experiment with it can use the clang command line flag “-fslp-vectorize”. I ran LLVM’s test suite with and without the SLP vectorizer on a Sandybridge mac (using SSE4, w/o AVX). Based on my performance measurements