Me too, but I'm not even holding my breath for stuff their actually talking about.

structures, arrays of structures, SIMD, cache preload hints, non-temporal stores, load fences, store fences.  Questions?

Shame on me for looking at the wrong column.

And that's what I said.  These benchmarks should java being between 2-37x slower than GCC, and GCC is a hunk of junk.

Taking a step back, most folks really shouldn't care about the speed difference between C/C++ and Java.  They're smallish linear differences say between 4-20x.  And most people will only see the bottom end of that range because they aren't going to be taking advantage of SIMD and cache oblivious methods (to name a couple).  And more to the point most people don't need to push tons of computations.  And since the speed difference is linear, algorithmic improvement is much more important than the choice of language.  Likewise moving away from single threaded to multi-threaded should give a nice additional linear boost.   Now of course the same changes could be applied to a C/C++ version as well, so it boils down to your point:  which language (or some other choice) can you to get the job done in the least amount of engineering time (and to spec)?  Choose that language and run with it.

What am I referring to is simple.  I only benchmark very expensive computations and C/C++ exposes a closer to the metal feature set which allow for very significant performance gains.  We've covered what Java's (actually the JVM) missing to allow to help close the gap pretty much ad nauseam.  Sometimes some programming trickery (a la Riven's structure library) can help, but mostly we're SOL until some features are added to the JVM.

Not serious mode:  Java?  compact?  And you said that with a straight face?

John Rose is mocking me...basic support is being considered for:  Tuples/structs, foreign data views & macros (templates in C++ speak).

Slides: http://cr.openjdk.java.net/~jrose/pres/201207-Arrays-2.pdf
Video: (I haven't watched this) http://medianetwork.oracle.com/video/player/1785452137001

In other words: I'm realistic.

Complete unrelated, but Java doesn't have concrete nor flattened multidimensional arrays, so type[][][] with fixed lengths should be avoided (except in cases where your using the fact to quickly swap rows...for instance).

Best case micro-optimizations are linear increases...never forget that.  Sometimes linear increases are sufficient, but really you want to be pretty sure that there isn't a reasonable high level change that would give you more "bang-for-your-buck".

Simple answer: priority queue.

Language benchmarks are mostly useful to language implementors.  Let me quote the referenced benchmark: "A team at Google created a "simple and compact" benchmark that didn't take advantage of language-specific features. An algorithm was implemented using each language's "idiomatic container classes, looping constructs, and memory/object allocation schemes.".

"Simple & compact" = can't be testing much.
"memory/object allocation schemes" = using default malloc/free in C++ which is dumb if you want high performance.
"didn't take advantage of language-specific features" = WTF?  The not much tested is totally meaningless.

Every single time I've compared code that I've implemented in Java and C, the C version completely smokes the Java...no contest...not even close.

Short answer: Cube map is easiest and cheapest.  Any simple mapping of a 2D texture to a sphere has aweful texture coverage which is also non-uniform.  Imagine wrapping a square piece of rubber around a ball and you'll get a rough idea (being a rectangle doesn't really help).

Well then: splines.  3rd order Hermite is a nice easy starting point.

I'll pass.  But it would be nice to have a very lightweight actor framework that (at least optionally) is inherently single threaded.

You mean you're talking about purely functional languages.

Probability distributions are interesting (I promise!).  A reasonable accessible overview of some basics is available here: http://www.redblobgames.com/articles/probability/damage-rolls.html

In that case: I'm pretty sure that there is a java version of qhull which probably has the code that you need.

We're already having a communication problem:  You say that all the point are on a plane.  If that is the case there's no projection needed.

search: "mesh from point cloud".

You're teacher's correct, since all the points are on a plane it's a 2D problem.  But to get an answer to your question you'll have to provide more details.  Like what are you attempting to do.

EDIT: Well, assuming that there's an outer perimeter of whatever it is you're doing, then you need to find the convex hull...well assuming you want convex containment.

Well, the next step up from the naive n² is n(n-1)/2 (still n² in Big-O, but we don't care).  Collision detection is inherently an n² problem.  The worst case of SAP is still n(n-1)/2 checks plus the cost of whatever sorting scheme.

Immutability hurts you here.  In no way does it help.  People with distributions which aren't close to uniform prefer <method-X> over uniform grids.

@Riven - sadly yes.

  I've posted in old threads.

Keep it simple.  Throw away some bottom bits, add (or sub) the dither, throw away some bottom bits.  Goof around with that...you'll need to clamp unless you account over or underflow (add vs. sub).

R = ((R & ~0xF)+D)&~0xF.

Distribution is the key litmus test.  Then it depends on the implementation.

Sweep-and-prune can be in any direction and number of dimensions, so a 2D systems can use 1 or 2.  As I said in that other thread, nobody can tell you what's fast without knowing (probably more information you can provide) information about your data set.  It'll be pretty common that a uniform grid will out-perform sweep-and-prune alone however and if your cells can contain a largest number of entities then sweep-and-prune inside the grid cells can be a win (there's a closely related technique called SAP-trees).  SAP can reduce the n(n-1)/2 by limiting how far forward your looking.  A uniform grid can be viewed as SAP where your sorting along the axises and only sorting in discrete chunks.

EDIT: No AABB requirement...but if your using the coordinate frame as sort directions then you effectively using an AABB.  Also note that for an arbitrary direction D, then choosing -D will be faster or slower.

I just ran across this: http://www.dtecta.com/files/GDC13_vandenBergen_Gino_Physics_Tut.pdf

nextInt(100) will return values between 0 and 99...so 100 possible results.  (Hint: read the documentation..if you're using an IDE it should automagically display it for you)

Let me semi-address your question of references.  The trick is that I'm not aware of much "new" that pertains to the problem.  The speed issue of UG and RQT is solely an implementation detail related to being cache obvious.  Back when I had anything to do with academia (and dinosaurs walked the earth) the references were by Hanan Samet.  You're probably better off just spending some time on citeseer, arxiv and/or mendeley.  You kids today have no idea how lucky you are to have free access to tons of research papers.  A quick search yielded this http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.148.4652 which appears (from a 2 minute skim of 160 page paper) to be a reasonable to get an overview of some various methods.

nextInt(int)

For not explicitly storing the location of all random placeables look here: http://www.java-gaming.org/topics/uniform-feature-points/28000/view.html