llvm dev - Jan 2010 - [LLVMdev] Help adding the Bullet physics sdk benchmark to the LLVM test suite?

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, 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).

There is also ongoing work, together with AMD, to add OpenCL optimizations
for Bullet 3.x,
but that is not available yet in the short term.

>> Anything special I should be aware of (e.g. special
"benchmark" mode,
If you compile the Bullet SDK using one of the included build systems, such
as cmake or autotools,
it will try to compile all of the demos, many of them are using OpenGL/glut
graphics,
and a lot of optional 'extras'. I suggest removing all of that
(Bullet/Extras folder etc).
We modified the Bullet/Demos/Benchmarks so it runs as a console program,
without graphics by default.

You could take Bullet/Demos/Benchmarks as a starting point, and modify it so
it fits the LLVM test suite?

What hardware/platforms does the LLVM test suite run on typically?
Thanks,
Erwin



2009/12/15 Anton Korobeynikov <anton at korobeynikov.info>
> 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 Bullet/Demos/Benchmarks
> > I'm not very familiar with the LLVM test-suite. Is someone
interested to
> > help integrating Bullet in the test suite?
> Yes, I am. Should I just use the 2.75 release?
> Anything special I should be aware of (e.g. special "benchmark"
mode,
> or "small" mode for embedded systems) ?
>
> --
> With best regards, Anton Korobeynikov
> Faculty of Mathematics and Mechanics, Saint Petersburg State University
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20091215/b2d4a3e8/attachment.html>

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. altivec / NEON ?
> You could take Bullet/Demos/Benchmarks as a starting point, and modify it
so
> it fits the LLVM test suite?
Ok, will do.
> What hardware/platforms does the LLVM test suite run on typically?
So far 32 and 64 bit Linux and MacOS, 32-bit ppc/darwin. Also, there
is special "small" mode mainly designed for stuff like ARM.
It will be nice (in theory) to have some NEON/VFP code, since the
testsuite currently lacks any beanchmark for this.

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

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 VFP/Neon
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

Thanks,
Erwin








2009/12/15 Anton Korobeynikov <anton at
korobeynikov.info>
>
> 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. altivec / NEON ?
>
> > You could take Bullet/Demos/Benchmarks as a starting point, and modify
it so
> > it fits the LLVM test suite?
> Ok, will do.
>
> > What hardware/platforms does the LLVM test suite run on typically?
> So far 32 and 64 bit Linux and MacOS, 32-bit ppc/darwin. Also, there
> is special "small" mode mainly designed for stuff like ARM.
> It will be nice (in theory) to have some NEON/VFP code, since the
> testsuite currently lacks any beanchmark for this.
>
> --
> With best regards, Anton Korobeynikov
> Faculty of Mathematics and Mechanics, Saint Petersburg State University

2009/12/16 Anton Korobeynikov <anton at
korobeynikov.info>:
> Well, I doubt so, unfortunately - LLVM does not have any autopar these days
Speaking of which, I've been looking into the loop passes and noticed
we do alias analysis and scalar evolution only, trying to clean up the
loop as far as possible.

I suppose that, if we were to define SCCs, split them into groups and
re-arranging into multiple loops, we would still do it in the IR,
right? Would that spoil any other pass? What passes should run
before/after such a pass?

I believe that would be a FunctionPass and registered in the
LoopDependencyAnalysis "runOnLoop()", so it can run when such pass is
called by the PassManager. Or should it be a completely separate pass
(VectorizationPass?) so we can control it from a separate command-line
flag?

cheers,
--renato

http://systemcall.org/

Reclaim your digital rights, eliminate DRM, learn more at
http://www.defectivebydesign.org/what_is_drm

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 current requirement of the llvm testsuite
harness.
Some include paths tweaks were required due to this. Also, I disabled
the time reports, since otherwise we cannot compare the outputs.

bullet appeared to be ~20% slower for me compared to gcc 4.2.4, so,
definitely something should be worked on :)

One questions though: is it possible to "verify" the results of all
the computations somehow? We need to care not only about speed, but
about correctness too :)

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

This is an excellent addition, thanks a lot Anton!

So far it looks like its working on ppc/x86_64 and some ARM testers.
It's not working on smoosh-01 yet (the buildbot driven nightly
tester), I will try to investigate...

 - Daniel

On Sat, Dec 19, 2009 at 12:13 PM, Anton Korobeynikov
<anton at korobeynikov.info> wrote:
> 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 current requirement of the llvm testsuite
> harness.
> Some include paths tweaks were required due to this. Also, I disabled
> the time reports, since otherwise we cannot compare the outputs.
>
> bullet appeared to be ~20% slower for me compared to gcc 4.2.4, so,
> definitely something should be worked on :)
>
> One questions though: is it possible to "verify" the results of
all
> the computations somehow? We need to care not only about speed, but
> about correctness too :)
>
> --
> With best regards, Anton Korobeynikov
> Faculty of Mathematics and Mechanics, Saint Petersburg State University
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

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 while.

There are a few ways of verification I can think of:

1) verifying by adding unit tests for all stages in the physics pipeline
(broadphase acceleration structures, closest point computation, constraint
solver)
Given known input and output we can check if the solution is within a
certain tolerance.

2) using the benchmark simulation and verifying the results frame by frame
and check for unusual behaviour

3) modify the benchmark so that it is easier to test the end result, even
through it might be different.
For example, we can drop a number of boxes above a bowl, and after a while
make sure all boxes are 'in' the bowl in a resting pose.

What are your thoughts?
Thanks,
Erwin


2009/12/19 Anton Korobeynikov <anton at korobeynikov.info>
> 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 current requirement of the llvm testsuite
> harness.
> Some include paths tweaks were required due to this. Also, I disabled
> the time reports, since otherwise we cannot compare the outputs.
>
> bullet appeared to be ~20% slower for me compared to gcc 4.2.4, so,
> definitely something should be worked on :)
>
> One questions though: is it possible to "verify" the results of
all
> the computations somehow? We need to care not only about speed, but
> about correctness too :)
>
> --
> With best regards, Anton Korobeynikov
> Faculty of Mathematics and Mechanics, Saint Petersburg State University
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100104/186ad3fa/attachment.html>