Did you consider the Line2D.intersects(Rectangle2D r) and Line2D.intersectsLine methods? These are quite fast as they don't use any trig methods.

I get these results on a 3.06GHz P4



As I noted on the other thread, some P4 processors have a very slow shift operation.

It may not be so efficient on processors that lack a fast shifter. While many processors will do a 31 bit shift in 1 or 2 clock cycles some require 31 clock cycles.

Graphics performance has been rather slower to improve than computational performance. Especially if you consider the basic Java API (AWT, Java2D, Swing) as opposed to extensions allowing access to OpenGL.

Otherwise there has been a lot of unjustified performance stigma.

When I was first looking at using Java (> 5 years ago) I tested some of my own code and even then the speed difference between Java and C++ was modest on that code. Since then a greater variety of code now approaches C++ performance, and fewer coding tricks are required. Adding stuff like escape analysis may not speed up code which has been optimised by the programmer, but rather allow ordinary straight forward code to run as fast as that written by the performance specialist.

Try using the imageio package (javax.imageio). This allows you to read an image and reduce its size in a single step. Depending on the implementation this may not require as much memory as would be required to read in the entire original image. The downside is that the quality of rescaling is likely yo be reduced. Alternatively it also allows you to read in parts of an image, so you could divide the larger image into many pieces and rescale each separately (you will need some overlap) and finally recombine the reduced pieces.

Usually where you have special case code for the zero case, so that you know the loop will run at least once but don't want to redundantly repeat the test on that first iteration.

Thanks, the midlet works as expected.
My work email adress my be better: mthornton at optrak.co.uk

Thanks for the offer, I have sent an email to your hotmail address.

I've written my first midlet, now I just need somewhere to put it. It isn't actually a game --- I needed to start with something more trivial. Any suggestions as to where I could put it without going to the trouble of setting up a server myself?

Impossible, I'm already married to that one! ;-)

Anyway, congratulations.

Mark

One way to implement multiple heaps might be to make use of JSR 121 (Isolates).
http://www.jcp.org/en/jsr/detail?id=121

Each isolate would have its own heap which is discarded when the isolate completes.

Well that was the original proposal, and there are now rather a lot of comments to read. Working out what the current consensus proposal would be from that JRE is no trivial task.

Higher values would further increase the whining about how much space Java uses.

It would be nice to be able to give the gc a hint at run time to the effect that you were about to allocate ~40MB of data. In effect to override the -Xms value. I have code that allocates several hundred megabytes of data and the run time is very dependent on the minimum heap size. I understand that there are difficulties changing the maximum heap size at runtime, but surely changing the minimum size is much easier.

There was a JSR:
http://jcp.org/en/jsr/detail?id=84

Not quite the precision is always as specified. Without strictfp the range of the exponent can be extended for intermediate values only.

As for "fastfp" I think a complete anything goes would be  bad idea --- there should still be some minimum requirements.

strictfp does not change the accuracy requirements at all, instead not using it allows the use of an extended exponent range. So that instead of overflowing at about 1e308, much larger values can be represented. This is only permitted for the intermediate values of an expression. On Intel hardware it allows intermediate values to be kept on the FP stack which uses an 80 bit representation. With strictfp each intermediate value has to be saved to memory and then reloaded to force overflow to occur at the expected point. Note that although the FP stack has 80 bits for each entry calculations do not necessarily use the full 64 bit mantissa --- there is a mode setting which controls the accuracy required (float, double, extended).

Fused multiply and add is a separate issue usually relating to Power cpus, and this is still not permitted because it uses additional accuracy for the intermediate result.

Which memory size column in Task Manager are you refering to? Note that the VM size column also includes memory which has been reserved but not allocated (i.e. there is no real memory used).

Relaxing the operation order of expressions and statements in Java is probably a non starter. Not enough interest in the potential benefits and too many people who find floating point baffling enough as it is.

A standard card had 80 columns each with twelve rows. The common encodings produced a 64 character set, thus each column was equivalent to 6 bits. Programs were stored in boxes which held 2000 cards.

http://www.cs.uiowa.edu/~jones/cards/codes.html

and this paper seems to describe one of the systems I used in Adelaide back in 1973

http://portal.acm.org/citation.cfm?id=810798&jmp=cit&dl=portal&dl=ACM

I knew the program was somewhat experimental, but hadn't previously realised that it had resulted in published papers. This system used cards which you marked using a soft pencil instead of using a punch, thus avoiding the problem of sharing a limited number of punch machines amongst lots of students.

The better card punch machines could be set to automatically put a sequence number in specified columns. Then if you dropped a deck, you just fed the cards into the automatic sorting machine. Paper tape was slower and more fragile than cards.
The first computer I used (1973) was an IBM 1130:
http://www-03.ibm.com/ibm/history/exhibits/1130/1130_intro.html

I'm finding that over the past 24 hours or so this site has frequently stopped responding. Anyone else had similar problems?

Not only punch cards, but also paper tape. In the project for my honours degree, I used one of these:

http://www.brouhaha.com/~eric/retrocomputing/dec/gt40/

which used paper tape for loading programs. I even remember playing the lunar landing game (1979). The project was on the "Mathematical evaluation of facial expressions", and paper later appeared in the British Journal of Psychiatry (1984).

Yes. I even remember a computer that was programmed using a plug panel. It was used to produce the program list for Channel 7 (I think) in Perth. At the time I was an exchange visit, staying with the family of the man responsible for programming it. Long out of date at the time it was kept in use on the basis of "if it ain't broke don't fix it".

The upcoming birthday list is full of youngsters ... I'll be 47 on Monday!
 

Exactly right. The peculiar characteristic that NaN isn't equal to itself was something I ought to have remembered. At the time I was concentrating on the fact that the String conversion should round trip the values exactly (including the NaN case) and forgot that the equality test is tricky.

Very likely. However I don't think that just turning of the checks is the correct approach. It would be far preferable to improve the JIT's ability to tell when the checks weren't necessary. For example good Pascal compilers were able to eliminate more checks when the integer subrange types were used appropriately.
Could we add attributes to declarations in Java that made similar assertions. Then so long as the assertion was true the JIT could make more aggressive optimizations. If an assertion was found false then either an exception could be thrown, or the optimizations unwound and the application left to continue and fail in the normal manner when the bad value was used.
Also would it be reasonable for a JIT to take notice of assert statements even when they were 'disabled' --- but of course only when the assert condition is helpful to the optimiser.

I think this gets more attention than it deserves. In a number of important cases the HotSpot server can remove these checks safely (or at least hoist them out of loops). Even when they remain they aren't as expensive as many people seem to think (and a lot less expensive than overrunning buffers as Microsoft can no doubt attest).

Argh, because of course Float.NaN != Float.NaN
The round trip through String does recover the identical value even for NaN, it is just the test which is tricky.
The test should read
Float.toIntBits(z) == Float.toIntBits(x)

Using naked bit operations to represent set operations is a bad hack too, albeit one of long standing.

I concede that the recursive generic declaration takes some understanding, but most people will just gloss over it and accept that it does the right thing. however without generics we have a semi-staticly type checked language which seems intellectually unsatisfactory. A sort of half way house between the fully dynamic languages and a complete static type checking. While some type casts are always likely to be necessary, without generics I find I have just too many of them for my peace of mind.