Patches for Linux Makefile

[Julio Jerez]

not the compiler do not do good vetorizie code. The best vetorized code out there is the intel compiler, and it does a really poor job.
my solver using hand code intrisics achives 3 to 4 time the performance of the x87 or scalar sse code. while using intel I am lucky if I get 5% speed up.

the problem is not just vectorizing simple loops, the problem is how to predicate complex code with sematics that only the algorithm knows.
in most case auto vetorized code has so much extra code that it result in a net lost in performance and very few loops do really provide real gain.

for a vetorizing compiler to be effective the only way to do that is by making the language extension to handle teh problem, stuff liek data time and way to predicate conditinals, etc.
this is why OpenCL, Direct compute, and vertex shaders, can make such effitive loops, the compiler had the extra sematics rules from language, C and C++ do not provide that and the compiler make a very simple guess.
Beleive me I am the number one person that would like ot remove all the SSE mombojumbo. Unfortunally the evidecne that compilers can do better autovetorization and auto parallelism more efficient than a prograemer is just not there.

anyway, I check in the make files with the 32 and 64 bit linux last night with the modification to use SSE2, unfortunally all I can do is compile it.
for some reason it does no run in my machine, but nothing else runs either, some how after I install the DDD debugger all hell broke lose and even if I unistalle the system does not works.
I beleive DDD changed lots of system libraries but I do not know how to fix that.

I am considering reinstalling unbutu from scratch again.

try build the Linux demosando again see if it works for you.

[Julio Jerez]

Hurray the Linux build is now working.
The biggest bug was that some of the Tools the makefiles was still invoking -sse4.1 option
This made the code crash on the startup and kgdb is not capable of debugging code if it crashes before main.

anyway the code now works in linux, and multithreading just work as well, the cool thing is that in my old Intel 2.4 hg Pentium, which is a hyper threaded but that I have it turned off at the bios level,
if I set the treading code to 16 threads, most demo run a bit faster.
This is threading on a single core, therefore I expect that in real dual and quad core the code should yield linear or better than linear performance gain by increasing the number of cores.
It seems that four threads per core is the optimal ratio at least in this machine, however adding more thread does not make it worse.
It also seems that threading in Linux is better than in windows 7, or at least it is not worse.

In the demos, mouse picking and the keyboard does not work yet, next time I will fix those, but for now all demo run and it confirmed the thread seem to offer performance game linear with the thread count. 1
6 thread in my single core yield 34 fps in the terrain demos, while a single core is only 21.
This is better than I was expecting for an older machine.

edit:
now all input shoudl be working and all systems

[carli2]

Thank you for your effort.
The minimal newton program works now and I will port my code to core300 when I find time to do so.

One further question to port my code: Where is the AddReference and Release for NewtonCollision gone? Do I have to handle references by myself?

[Julio Jerez]

the collision now are all instances, you do no need to handle references it is all taken care internally. I was never happy with ref conted and I had to fix that.
bascially you call createcollsion and destroy collision, check it out it is much better now.

[carli2]

bascially you call createcollsion and destroy collision, check it out it is much better now.

Well, I liked the reference model because it fits into my garbage collection model of the script engine. I will see if I write wrappers for that or if I simply do not release/destroy collisions while runtime.

[Julio Jerez]

Now it much better than it was before.
see how it work, I am sure you will have no problme with it.

each collision shape is a unique instance, this unify all collision in he engine.
before becam same shape we shape and ref conted, I have to have special case watepr for shpe that cod no be shape, or shape with user data,
now the instance, say for example you have a box shape.
you can resuse the same shape with many boxes and each one will shared the common geometry,
but each instance now supports userdata, shape id, scale, transform matrix, and few more other things .
beleive me, this is much better than the ref counted shapes.

I will add a new interface function for people who want to have the shape data.
you can use that as a key for your manager.

Like I said, exposing ref counted objects is too high lever compset for a low level library like Netwon.
In newton I alway found that awkwark because the collision was the only ref counted object.

[carli2]

[deleted]

[carli2]

each collision shape is a unique instance, this unify all collision in he engine.
before becam same shape we shape and ref conted, I have to have special case watepr for shpe that cod no be shape, or shape with user data,
now the instance, say for example you have a box shape.
you can resuse the same shape with many boxes and each one will shared the common geometry,
but each instance now supports userdata, shape id, scale, transform matrix, and few more other things .
beleive me, this is much better than the ref counted shapes.

In which order do I have to call CreateConvexHull, NewtonBodySetCollision, NewtonDestroyCollision, ... then?
(I also change the collision of a body and then set it back to the old value)

[carli2]

I tested Newton 3.0 now. The only things I changed were the removal of NewtonSetWorldSize and the collision reference counting.
The problem was: All objects fell through the ground. Does creating stiff bodies still work with using mass zero?
I did not retranslate the headers. Were there some fundamental changes in some data formats or parameters?

[Julio Jerez]

Ok I fixed tutorial Tutorial_101_GettingStarted and Tutorial_102_AddingRigidBodies

you can see how a body is created by opening Tutorial_102_AddingRigidBodies and lokking a function TutorialCode.cpp and CreateRigidBody
see if that helps

[carli2]

The tutorial code is abstracted a lot. You should forgeo calling Newton functions in the Common directory. Put all calls to newton function into one file, that should be more clear.

[carli2]

Btw as far as I concern, I'm calling the functions correctly. There are no major changes in the interface of the core functions except the compound collision.
Anyway, I started translating the header of newton 3.0 to pascal to let the compiler detect interface changes. (worked with the 2.0 header before)