Krystian wrote:Julio: "I actually made teh class with mutiplaform in mind." - thanks, translation was fair easy, even for me who never worked with SIMD/VFP/NEON before
In core200 when I tried to do that translation, I faced mainly problem with lack of SHUFPS-equivalent in NEON.
yes that was the idea, shuffe operation are hard to deal with, with macros, but a class can eassyly us ethe best possible intructions.
for example in altivec it would use the correct permute instruction, on newer Intel it can also use the new shuffler instructions, but on old Intel if can simple emulate the shuffle in c code because the shuffle on older simd is very primitive, the end user will not have to worried about.
I like it that you successfully ported to Neon/VFP,
Krystian wrote:@Julio
What's the status of Core300? Is it 'ready' for replacement of Core200, I mean is 'everything' works as in Core200. I'm asking because I saw in one Tutorial from Newton, that for example in Core300 car wheels 'does not works' (I mean there is no collision with terrain).
core 300 in by far superior to core 200, however I have not converted all the feature yet, i took a break, until I complete the new scripting languare I am working on.
I am actually writing a trully hybrid between using eh besst feature of Java c sharp and objective. It will be integrated with core 300 and the level editor.
I am having too many problems with the visual interface in C++. I realized that the trick in to make a language with build in gui functionality and that integrates seamlessly with C++ and C.
after I have the script language in a stable state, it will resume back the core 300 integration.
however core 300 is usable as it now, but not all feature are ported yet.
it has a far superior multithreading support. The multithreading was change from data parallel base to first in first served threading system.
this may have some problem with platforms with slow atomics or with no atomic at all,
but all we need to worried about is that the atoms dispatched to each thread had enough instrutions to outwait the cores on the semaphore.
in core 300, 100% of the engine is multithreaded, while in core 200 the solver had a very hard time separation the work among cores. and only part of the broad phase is multithreaded.
so far in all my test core 300 is faster that core 200 using multithread, and in some case the different is up to three time better.
I had run test in core 300 with 8 an 10 thousand falling objects, and still run at iterative time using the 4 cores available.
also in core 300 not longer the number of thread has to be equal to the number of core for best performance, in core 300 I can set 32 thread and it surprisingly it run even better.
the scene with 8 thousand object does runs much, much slower in core 200 than it does in core 300 when using for example 16 threads, in my Intel core 7 with 8 hardware threads.
amazingly even hyper threaded system yield better performance with the new threading system.
