Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #6948
| Path | csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail |
|---|---|
| From | Joshua Cranmer <Pidgeot18@verizon.invalid> |
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: higher precision doubles |
| Date | Tue, 09 Aug 2011 22:06:00 -0500 |
| Organization | A noiseless patient Spider |
| Lines | 44 |
| Message-ID | <j1ssit$nc0$1@dont-email.me> (permalink) |
| References | <j1hqc1$1ch$1@news.albasani.net> <cOqdnfXfM99lhaDTnZ2dnUVZ_vednZ2d@earthlink.com> <j1qdrt$30a$1@speranza.aioe.org> <j1rio5$ucd$1@dont-email.me> <4e41ef89$0$306$14726298@news.sunsite.dk> |
| Mime-Version | 1.0 |
| Content-Type | text/plain; charset=UTF-8; format=flowed |
| Content-Transfer-Encoding | 8bit |
| Injection-Date | Wed, 10 Aug 2011 03:06:06 +0000 (UTC) |
| Injection-Info | mx04.eternal-september.org; posting-host="B3q1fNdvNsCxx/IZ4idKGA"; logging-data="23936"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+ha2MnWPzsj3T6oU6StD1gAZ/vanSVPbM=" |
| User-Agent | Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 |
| In-Reply-To | <4e41ef89$0$306$14726298@news.sunsite.dk> |
| Cancel-Lock | sha1:WTDAH+mZfb3BPIFb1yU/rDXjEKo= |
| Xref | x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:6948 |
Show key headers only | View raw
On 8/9/2011 9:40 PM, Arne Vajhøj wrote: > On 8/9/2011 11:11 AM, Joshua Cranmer wrote: >> On 8/8/2011 11:42 PM, >> supercalifragilisticexpialadiamaticonormalizeringelimatisticantations >> wrote: >>> How does that interact with JIT, though? On x86, the simplest way for >>> JIT to make non-strictfp code use the FPU would be to just load the >>> initial values into the (80-bit-wide!) registers and perform FADDs, >>> FMULs, etc. on them. As long as the computation stayed in registers the >>> higher precision then ought to remain in effect -- for JITted code. >>> Adding extra code to mask off 16 of the register bits (or the mantissa >>> subset of the extra bits) after every FP op would slow things down. Is >>> the JLS interpreted to require the JIT do this (for non-strictfp code)? >>> And, if not, what does the HotSpot JIT do in actuality? >> >> All modern x86 processors sport the SSE-style instructions, which can do >> 32-bit and 64-bit instructions (also in a SIMD format) without touching >> the FPU, and I suspect that these are slightly faster than using the x87 >> FPU instructions. I wouldn't be surprised if the JIT emitted SSE in the >> vast majority of cases, so that JIT'd non-strictfp code would end up >> returning the same results as JIT'd strictfp code. > > Is that possible in 32 bit mode? > > Practically all CPU's today are 64 bit capable, but many still run > 32 bit desktop OS'es. I don't recall x86's mode-switching semantics off the top of my head, but I do believe that it is possible to run 64-bit instructions in 32-bit mode. The problem is the C ABI, particularly register saves and restores, don't handle 64-bit stuff properly when compiled with 32-bit targets for compilers. SSE2 dates back to something like the Pentium II, so it's not a 64-bit mode thing. Although I think SSE2 itself may only be limited to single precision floats. Poking around the hotspot source code for Java 7 does indicate that sse2 support is in the JIT, although I don't know the entire set of circumstances that triggers it. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar
higher precision doubles Jan Burse <janburse@fastmail.fm> - 2011-08-06 00:20 +0200
Re: higher precision doubles Patricia Shanahan <pats@acm.org> - 2011-08-06 03:35 -0700
Re: higher precision doubles Jan Burse <janburse@fastmail.fm> - 2011-08-06 13:03 +0200
Re: higher precision doubles BGB <cr88192@hotmail.com> - 2011-08-06 12:20 -0700
Re: higher precision doubles Jan Burse <janburse@fastmail.fm> - 2011-08-06 23:30 +0200
Re: higher precision doubles BGB <cr88192@hotmail.com> - 2011-08-06 16:12 -0700
Re: higher precision doubles Jan Burse <janburse@fastmail.fm> - 2011-08-07 01:35 +0200
Re: higher precision doubles BGB <cr88192@hotmail.com> - 2011-08-06 19:26 -0700
Re: higher precision doubles supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-08-09 00:42 -0400
Re: higher precision doubles Patricia Shanahan <pats@acm.org> - 2011-08-09 04:07 -0700
Re: higher precision doubles Jan Burse <janburse@fastmail.fm> - 2011-08-09 14:00 +0200
Re: higher precision doubles Patricia Shanahan <pats@acm.org> - 2011-08-09 09:07 -0700
Re: higher precision doubles Jan Burse <janburse@fastmail.fm> - 2011-08-10 08:50 +0200
Re: higher precision doubles supercalifragilisticexpialadiamaticonormalizeringelimatisticantations <supercalifragilisticexpialadiamaticonormalizeringelimatisticantations@averylongandannoyingdomainname.com> - 2011-08-10 20:16 -0400
Re: higher precision doubles Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-08-09 10:11 -0500
Re: higher precision doubles Arne Vajhøj <arne@vajhoej.dk> - 2011-08-09 22:40 -0400
Re: higher precision doubles Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-08-09 22:06 -0500
Re: higher precision doubles BGB <cr88192@hotmail.com> - 2011-08-10 08:53 -0700
Re: higher precision doubles Jan Burse <janburse@fastmail.fm> - 2011-08-06 21:24 +0200
Re: higher precision doubles markspace <-@.> - 2011-08-06 13:29 -0700
Re: higher precision doubles Jan Burse <janburse@fastmail.fm> - 2011-08-06 23:20 +0200
Re: higher precision doubles markspace <-@.> - 2011-08-06 15:43 -0700
Re: higher precision doubles Jan Burse <janburse@fastmail.fm> - 2011-08-07 01:06 +0200
Re: higher precision doubles Patricia Shanahan <pats@acm.org> - 2011-08-06 16:21 -0700
Re: higher precision doubles Jan Burse <janburse@fastmail.fm> - 2011-08-07 01:34 +0200
Re: higher precision doubles Patricia Shanahan <pats@acm.org> - 2011-08-06 21:32 -0700
Re: higher precision doubles Jan Burse <janburse@fastmail.fm> - 2011-08-07 17:24 +0200
Re: higher precision doubles Jan Burse <janburse@fastmail.fm> - 2011-08-07 17:39 +0200
Re: higher precision doubles Patricia Shanahan <pats@acm.org> - 2011-08-07 09:26 -0700
Re: higher precision doubles Jan Burse <janburse@fastmail.fm> - 2011-08-07 21:23 +0200
Re: higher precision doubles Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-08-07 20:48 -0400
Re: higher precision doubles Jan Burse <janburse@fastmail.fm> - 2011-08-08 09:05 +0200
Re: higher precision doubles Patricia Shanahan <pats@acm.org> - 2011-08-08 05:37 -0700
Re: higher precision doubles Jan Burse <janburse@fastmail.fm> - 2011-08-08 19:08 +0200
Re: higher precision doubles Jan Burse <janburse@fastmail.fm> - 2011-08-08 19:16 +0200
Re: higher precision doubles Jan Burse <janburse@fastmail.fm> - 2011-08-08 19:29 +0200
Re: higher precision doubles Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-08-08 21:34 -0500
Re: higher precision doubles BGB <cr88192@hotmail.com> - 2011-08-08 13:49 -0700
Re: higher precision doubles Jan Burse <janburse@fastmail.fm> - 2011-08-09 01:08 +0200
Re: higher precision doubles BGB <cr88192@hotmail.com> - 2011-08-09 02:44 -0700
Re: higher precision doubles Jan Burse <janburse@fastmail.fm> - 2011-08-09 12:52 +0200
Re: higher precision doubles BGB <cr88192@hotmail.com> - 2011-08-09 13:15 -0700
Re: higher precision doubles BGB <cr88192@hotmail.com> - 2011-08-07 13:51 -0700
Re: higher precision doubles Jan Burse <janburse@fastmail.fm> - 2011-08-07 01:59 +0200
Re: higher precision doubles Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-08-08 21:03 -0500
Re: higher precision doubles Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-08-06 17:33 -0400
Re: higher precision doubles Patricia Shanahan <pats@acm.org> - 2011-08-06 14:51 -0700
Re: higher precision doubles Jan Burse <janburse@fastmail.fm> - 2011-08-07 00:57 +0200
csiph-web