Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #9662

Re: particle container in Java

Show all headers | View raw

On 11/6/2011 7:15 AM, Giovanni Azua wrote:
> Hi Roedy,
>
> On 11/6/11 12:07 PM, in article 8dqcb7dpnonje061cp69hr944tinltg0eq@4ax.com,
> "Roedy Green"<see_website@mindprod.com.invalid>  wrote:
>> On Sat, 05 Nov 2011 09:16:03 -0700, BGB<cr88192@hotmail.com>  wrote,
>> quoted or indirectly quoted someone who said :
>>
>>> I try where possible to keep things in the 40-60fps range,
>>
>> Another totally different approach is to fob the work off on the GPU.
>> I have not coded at low level for a very long time, so I don't know
>> what modern video cards can do, and how standard the APIs are.
>>

except:
GPGPU requires newer cards (excludes older cards and many laptops and 
entry-level PCs with "Intel GMA" GPUs or similar, ...);
doesn't really work as well when the card is already busy doing 
"everything else";
it is at-present, a bit of a hassle;
...

more so, it is not so relevant when ones' engine is mostly getting 
bogged down trying to shove stuff through the video card (in this case, 
the raw performance on the CPU is not nearly as important...).


>> But, it seem to me what you are doing is common to many games, and
>> surely modern video cards have some way of helping out.  They have
>> some skookum processing power.  I would think some parallel processing
>> hardware would really make this sort of thing fly.
>>
> Absolutely :) when I saw this OP, the first thing that crossed my mind was
> "why is he using Java for this ... ?". These are the reasons I would stay
> away from Java and rather use C++ to do such a job:
>
> 1) Manual optimization for the memory hierarchies e.g. Scalar replacement;
>     optimizing loops with the level of unrolling that maximizes the cache hit
>     for the underlying system cache specification. This needs "manual
>     analysis and manual doing" since e.g. memory aliasing and function calls
>     prevent C++ compilers from doing such optimizations automatically. Same
>     concepts apply to CUDA 3) below.
>

above: probably overkill, FWIW...

though, in my case, pretty much all of my 3D rendering and "core 
functionality" is mostly in C (a few things use C++, but these are 
elsewhere in the project).

I also use Java and BGBScript (my own language) in a few places, but 
this is not anywhere near the 3D renderer (both were used in my case 
with the intention of being for "server side" functionality, which 
mostly means AI/NPC behavior world entities/events and similar).

as-is, much of the "server side" functionality is still in C as well though.


a major downside of Java here was mostly that JNI is not terribly 
usable, and that with a naive VM, it tends to spew a lot of garbage (not 
so good if ones' GC is also not very good).

I was able to make my own language much nicer WRT cross-language 
interfacing.

decided to leave out a glob of history here (interactions and 
developments in my own project WRT the creation of VMs and relations 
between programming languages...).


> 2) Same reason as 1) to do manual vectorization i.e. SSE, SSE2, SSE3, SSE4
>     etc e.g.
>      float a[4] = {1.0, 2.0, 3.0, 4.0};
>      __m128 t = _mm_load_ps(a);
>      b = _mm_mul_ps(a, a);
>

I also do this, but mostly wrapped the intrinsics to make them look more 
like a nicer (GLSL-style) vector API (with fallback logic for if SSE 
wasn't enabled as a compiler switch, where plain structs and scalar math 
are used instead).

sadly, the way it was implemented doesn't currently allow operator 
overloading (in C++), so I have to be more like:
vec3 u, v;
float f, g;
u=vec3(1,2,3,4);
v=v3mul(u, u);
f=v3dot(u, v);
g=v3dot(u, v3scale(v, f));
...

but, it works.

it is implemented as a mix of macros and "static inline" functions.


gradually, this is replacing my "older strategy", which was to represent 
all vectors directly as arrays of floats, and perform operations by 
passing pointers to these float arrays.

the new style can somewhat outperform the old style with SSE enabled, 
but is slightly slower without SSE enabled (mostly due to the added 
memory-copying in passing/returning structs). either way, it is more 
convenient.



> 3) CUDA nVidia C++ extensions that allows embedding GPU code and invoking it
>     from CPU. Here an example that matches the OP:
>     http://http.developer.nvidia.com/GPUGems3/gpugems3_ch31.html
>
>     Needs a lot of brainwork to make get it right i.e. To be able
>     to outperform CPU in numerical methods e.g. MMM, MVM.
>     Trying to implement a Fast Multipole with CUDA would be a daunting task
>     ... but is not impossible:
>
> <http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCEQFjA
> A&url=http%3A%2F%2Farxiv.org%2Fpdf%2F1010.1482&ei=wZW2TpHAI4mJ4gTX5f37Aw&usg
> =AFQjCNGln1eVVemPaPZRP3RtOxKcYeNWjw&sig2=WONUfOoU5zSEYjzUfWLR3w>
>
> <http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CCoQFjA
> B&url=http%3A%2F%2Farxiv.org%2Fabs%2F1010.1482&ei=wZW2TpHAI4mJ4gTX5f37Aw&usg
> =AFQjCNH8rO4vBk9E-p8W2Le11kDPiQYjkg&sig2=x0t31s43D22f6yN7cq8l6Q>
>

FWIW, there is also OpenCL.

OpenCL is to CUDA sort of like what OpenGL is to DirectX...

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

particle container in Java bob <bob@coolgroups.com> - 2011-11-03 01:05 -0700
  Re: particle container in Java Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-11-03 08:33 +0000
  Re: particle container in Java Roedy Green <see_website@mindprod.com.invalid> - 2011-11-03 08:12 -0700
    Re: particle container in Java BGB <cr88192@hotmail.com> - 2011-11-03 13:51 -0700
      Re: particle container in Java Roedy Green <see_website@mindprod.com.invalid> - 2011-11-04 15:54 -0700
        Re: particle container in Java BGB <cr88192@hotmail.com> - 2011-11-04 19:48 -0700
          Re: particle container in Java Roedy Green <see_website@mindprod.com.invalid> - 2011-11-05 06:42 -0700
  Re: particle container in Java Giovanni Azua <bravegag@hotmail.com> - 2011-11-03 23:38 +0100
    Re: particle container in Java BGB <cr88192@hotmail.com> - 2011-11-03 22:41 -0700
      Re: particle container in Java Roedy Green <see_website@mindprod.com.invalid> - 2011-11-05 06:49 -0700
        Re: particle container in Java BGB <cr88192@hotmail.com> - 2011-11-05 09:16 -0700
          Re: particle container in Java Roedy Green <see_website@mindprod.com.invalid> - 2011-11-06 03:07 -0800
            Re: particle container in Java Giovanni Azua <bravegag@hotmail.com> - 2011-11-06 15:15 +0100
              Re: particle container in Java BGB <cr88192@hotmail.com> - 2011-11-06 11:06 -0700
  Re: particle container in Java Arne Vajhøj <arne@vajhoej.dk> - 2011-11-03 19:03 -0400

csiph-web