Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: Nancy 3 Newsgroups: comp.lang.java.programmer Subject: Re: Java puzzler Date: Thu, 12 May 2011 20:47:21 -0400 Organization: N3 Solutions Inc. Lines: 14 Message-ID: References: <4db69c13-878f-4806-adb2-a3c5adb1c48c@glegroupsg2000goo.googlegroups.com> <-8mdnSRPEIdA21HQnZ2dnUVZ_j2dnZ2d@earthlink.com> NNTP-Posting-Host: taZaw1fZzaqFzuo6ews1KQ.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Forte Agent 2.0/32.652 X-Notice: Filtered by postfilter v. 0.8.2 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:4028 On 12/05/2011 5:32 PM, markspace wrote: > On 5/12/2011 1:56 PM, Nancy 3 wrote: >> There's also the minor little matter of number crunching performance >> going straight to hell if every little add or multiply suddenly has >> some test-and-branch instructions added near it. > > I believe arithmetic overflow could be handled efficiently at the > machine level, without the need for an explicit test-and-branch. I > haven't looked at any datasheets recently, but I recall most CPUs have > an option to trap, automatically, on overflow detection. I'm sorry. I assumed you wanted an ArithmeticException or some other Java exception on overflow, rather than an application fault ala SIGSEGV that brings down the whole JVM. :)