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

Groups > comp.programming > #2302 > unrolled thread

64 bit code

Back to article view | Back to comp.programming

Contents

  64 bit code bob <bob@coolfone.comze.com> - 2012-10-10 08:22 -0700
    Re: 64 bit code Jongware <jongware@no-spam.plz> - 2012-10-10 17:35 +0200
      Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-10 17:37 +0100
        Re: 64 bit code Robert Wessel <robertwessel2@yahoo.com> - 2012-10-10 12:54 -0500
        Re: 64 bit code Fritz Wuehler <fritz@spamexpire-201210.rodent.frell.theremailer.net> - 2012-10-10 21:37 +0200
          Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-10 21:46 -0500
        Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-10 20:43 +0100
          Re: 64 bit code "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-10-12 08:40 +0100
            Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-12 12:36 -0500
            Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-12 20:57 +0100
              Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-12 21:30 +0100
                Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-12 16:33 -0500
                  Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-13 00:44 +0100
                  Re: 64 bit code Ben Pfaff <blp@cs.stanford.edu> - 2012-10-12 20:07 -0700
                Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-13 11:11 +0100
                  Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-13 13:11 +0100
                    Re: 64 bit code Willem <willem@turtle.stack.nl> - 2012-10-13 12:34 +0000
                      Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-13 09:50 -0500
                      Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-13 17:25 +0100
                        Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-13 17:53 +0100
                    Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-13 17:05 +0100
            Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-13 10:37 +0200
              Re: 64 bit code "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-10-27 12:18 +0100
                Re: 64 bit code "Chris Uppal" <chris.uppal@metagnostic.REMOVE-THIS.org> - 2012-10-27 12:54 +0100
                Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-27 15:13 +0200
                  Re: 64 bit code Robert Miles <milesrf@Usenet-News.net> - 2012-10-28 04:12 -0500
                    Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-28 13:10 +0100
                      Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-29 04:38 +0000
                        Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-29 09:30 +0100
                          Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-30 22:09 +0000
                            Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-31 09:47 +0100
                              Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-31 09:55 +0100
                              Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-31 14:32 +0000
              Re: 64 bit code Patricia Shanahan <pats@acm.org> - 2012-10-27 08:51 -0700
                Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-27 17:23 +0100
                Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-27 20:43 +0200
                  Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-30 22:16 +0000
                    Re: 64 bit code "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2012-10-31 09:53 +0100
                      Re: 64 bit code "LudovicoVan" <julio@diegidio.name> - 2012-10-31 14:33 +0000
                        Re: 64 bit code Fritz Wuehler <fritz@spamexpire-201211.rodent.frell.theremailer.net> - 2012-11-01 00:25 +0100
        Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-10 21:04 +0100
          Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-10 21:52 +0100
            Re: 64 bit code Ian Collins <ian-news@hotmail.com> - 2012-10-11 10:50 +1300
              Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-10 21:54 -0500
                Re: 64 bit code "BartC" <bc@freeuk.com> - 2012-10-11 13:11 +0100
                  Re: 64 bit code BGB <cr88192@hotmail.com> - 2012-10-11 11:17 -0500
        Re: 64 bit code Ben Pfaff <blp@cs.stanford.edu> - 2012-10-10 13:17 -0700
          Re: 64 bit code Fritz Wuehler <fritz@spamexpire-201210.rodent.frell.theremailer.net> - 2012-10-11 19:36 +0200
            Re: 64 bit code Ben Pfaff <blp@cs.stanford.edu> - 2012-10-12 08:13 -0700
      Re: 64 bit code Rui Maciel <rui.maciel@gmail.com> - 2012-10-10 20:38 +0100
      Re: 64 bit code Robin Vowels <robin.vowels@gmail.com> - 2012-10-10 15:22 -0700
    Re: 64 bit code Robert Miles <milesrf@Usenet-News.net> - 2012-10-12 02:13 -0500

Page 1 of 3  [1] 2 3  Next page →

#2302 — 64 bit code

Was the move to 64 bit code primarily to break the 4 gig memory barrier?

Or were there other equally compelling incentives?

[toc] | [next] | [standalone]

#2305

On 10-Oct-12 17:22 PM, bob wrote:
> Was the move to 64 bit code primarily to break the 4 gig memory barrier?
>
> Or were there other equally compelling incentives?

Memory is typically served by a separate bus. There used to be 16/32 bit 
CPUs that internally worked with 16 bit words and externally with 32 
bits (or possibly the other way around).

One compelling reason could be that Bigger = Better. A native 64 bit 
processor can handle integers up to 2^64 ~ 10^19, which admittedly is 
not a big advantage (I don't think an integer of such size is useful for 
arithmetic), but they also can process 64 bit floating point numbers in 
one stride. As far as floating point goes, bigger (more precision!) is 
most definitely better.

[Jw]

[toc] | [prev] | [next] | [standalone]

#2306

"Jongware" <jongware@no-spam.plz> wrote in message 
news:507595db$0$6898$e4fe514c@news2.news.xs4all.nl...
> On 10-Oct-12 17:22 PM, bob wrote:
>> Was the move to 64 bit code primarily to break the 4 gig memory barrier?
>>
>> Or were there other equally compelling incentives?
>
> Memory is typically served by a separate bus. There used to be 16/32 bit 
> CPUs that internally worked with 16 bit words and externally with 32 bits 
> (or possibly the other way around).
>
> One compelling reason could be that Bigger = Better. A native 64 bit 
> processor can handle integers up to 2^64 ~ 10^19, which admittedly is not 
> a big advantage (I don't think an integer of such size is useful for 
> arithmetic), but they also can process 64 bit floating point numbers in 
> one stride. As far as floating point goes, bigger (more precision!) is 
> most definitely better.

Floating point processors could deal with 64-bit numbers even with 32-bit 
processors (in fact even with 16-bit ones).

And 64-bit data/instruction busses on a processor didn't really need it to 
be 64-bits either.

And the downside of 64-bit processors is *having* to use 64-bits for things 
for which 32-bits was perfectly adequate.

They can address over 4GB in one virtual address space, sure, but how many 
programs actually need to do that?

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#2308

On Wed, 10 Oct 2012 17:37:27 +0100, "BartC" <bc@freeuk.com> wrote:

>
>
>"Jongware" <jongware@no-spam.plz> wrote in message 
>news:507595db$0$6898$e4fe514c@news2.news.xs4all.nl...
>> On 10-Oct-12 17:22 PM, bob wrote:
>>> Was the move to 64 bit code primarily to break the 4 gig memory barrier?
>>>
>>> Or were there other equally compelling incentives?
>>
>> Memory is typically served by a separate bus. There used to be 16/32 bit 
>> CPUs that internally worked with 16 bit words and externally with 32 bits 
>> (or possibly the other way around).
>>
>> One compelling reason could be that Bigger = Better. A native 64 bit 
>> processor can handle integers up to 2^64 ~ 10^19, which admittedly is not 
>> a big advantage (I don't think an integer of such size is useful for 
>> arithmetic), but they also can process 64 bit floating point numbers in 
>> one stride. As far as floating point goes, bigger (more precision!) is 
>> most definitely better.
>
>Floating point processors could deal with 64-bit numbers even with 32-bit 
>processors (in fact even with 16-bit ones).
>
>And 64-bit data/instruction busses on a processor didn't really need it to 
>be 64-bits either.
>
>And the downside of 64-bit processors is *having* to use 64-bits for things 
>for which 32-bits was perfectly adequate.
>
>They can address over 4GB in one virtual address space, sure, but how many 
>programs actually need to do that?


OS's do, and the OS guy's really hate the more complicated schemes for
address more than the native amount of memory.  In addition, some
important applications do.  Databases, for example, many HPC
workloads...

But to the OP, yes, the 64 bit transition was mainly driven by memory.
Once you had 64 bit addressing, you needed 64 bit registers, then 64
bit operations on those register, etc.  Not that those are bad things
(in some case they're quite useful), but it's much easier to simulate
longer operations than bigger addressing.

Note that some CPUs brought other useful enhancements with 64 bit
mode.  For example, x86 doubled the number of GPRs, but that really is
orthogonal to the addressing issue.

[toc] | [prev] | [next] | [standalone]

#2309

"BartC" <bc@freeuk.com> wrote:

> 
> 
> "Jongware" <jongware@no-spam.plz> wrote in message 
> news:507595db$0$6898$e4fe514c@news2.news.xs4all.nl...
> > On 10-Oct-12 17:22 PM, bob wrote:
> >> Was the move to 64 bit code primarily to break the 4 gig memory barrier?
> >>
> >> Or were there other equally compelling incentives?
> >
> > Memory is typically served by a separate bus. There used to be 16/32 bit 
> > CPUs that internally worked with 16 bit words and externally with 32 bits 
> > (or possibly the other way around).
> >
> > One compelling reason could be that Bigger = Better. A native 64 bit 
> > processor can handle integers up to 2^64 ~ 10^19, which admittedly is not 
> > a big advantage (I don't think an integer of such size is useful for 
> > arithmetic), but they also can process 64 bit floating point numbers in 
> > one stride. As far as floating point goes, bigger (more precision!) is 
> > most definitely better.
> 
> Floating point processors could deal with 64-bit numbers even with 32-bit 
> processors (in fact even with 16-bit ones).
> 
> And 64-bit data/instruction busses on a processor didn't really need it to 
> be 64-bits either.
> 
> And the downside of 64-bit processors is *having* to use 64-bits for things 
> for which 32-bits was perfectly adequate.
> 
> They can address over 4GB in one virtual address space, sure, but how many 
> programs actually need to do that?

The main driver for 4GB+ address spaces has been databases and even some
filesystems. Other than that, there aren't so many applications that need it
aside from number crunching (which is still possible, just slower) and
probably multimedia stuff like transcoding.

[toc] | [prev] | [next] | [standalone]

#2317

On 10/10/2012 2:37 PM, Fritz Wuehler wrote:
> "BartC" <bc@freeuk.com> wrote:
>
>>
>>
>> "Jongware" <jongware@no-spam.plz> wrote in message
>> news:507595db$0$6898$e4fe514c@news2.news.xs4all.nl...
>>> On 10-Oct-12 17:22 PM, bob wrote:
>>>> Was the move to 64 bit code primarily to break the 4 gig memory barrier?
>>>>
>>>> Or were there other equally compelling incentives?
>>>
>>> Memory is typically served by a separate bus. There used to be 16/32 bit
>>> CPUs that internally worked with 16 bit words and externally with 32 bits
>>> (or possibly the other way around).
>>>
>>> One compelling reason could be that Bigger = Better. A native 64 bit
>>> processor can handle integers up to 2^64 ~ 10^19, which admittedly is not
>>> a big advantage (I don't think an integer of such size is useful for
>>> arithmetic), but they also can process 64 bit floating point numbers in
>>> one stride. As far as floating point goes, bigger (more precision!) is
>>> most definitely better.
>>
>> Floating point processors could deal with 64-bit numbers even with 32-bit
>> processors (in fact even with 16-bit ones).
>>
>> And 64-bit data/instruction busses on a processor didn't really need it to
>> be 64-bits either.
>>
>> And the downside of 64-bit processors is *having* to use 64-bits for things
>> for which 32-bits was perfectly adequate.
>>
>> They can address over 4GB in one virtual address space, sure, but how many
>> programs actually need to do that?
>
> The main driver for 4GB+ address spaces has been databases and even some
> filesystems. Other than that, there aren't so many applications that need it
> aside from number crunching (which is still possible, just slower) and
> probably multimedia stuff like transcoding.
>

many games are pushing towards or going beyond the 4GB limit.

in the not-to-distant future, many games may require a 64-bit OS to 
work, especially if higher-density voxel based worlds start getting popular.

say a person makes a Minecraft style game, but chooses 0.25 meters as 
the block size, and suddenly the terrain takes 8x as much RAM (a 
moderate sized chunk of world needing, say, 8 or 16GB, to really be 
played effectively).

as-is, this is pretty much already the case for people running 
multiplayer Minecraft servers, where they often need around 32GB or 64GB 
of RAM for things to really run effectively.

[toc] | [prev] | [next] | [standalone]

#2311

BartC wrote:

> Floating point processors could deal with 64-bit numbers even with 32-bit
> processors (in fact even with 16-bit ones).

And let's not forget about the ever elusive 80-bit extended precision 
floating point format, also known as "why bother".


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#2328

Rui Maciel wrote:

> And let's not forget about the ever elusive 80-bit extended precision
> floating point format, also known as "why bother".

For one answer, people might like to read:

    http://www.cs.berkeley.edu/~wkahan/Stnfrd50.pdf

linked to from Kahan's page:

    http://www.cs.berkeley.edu/~wkahan/

    -- chris 

[toc] | [prev] | [next] | [standalone]

#2330

On 10/12/2012 2:40 AM, Chris Uppal wrote:
> Rui Maciel wrote:
>
>> And let's not forget about the ever elusive 80-bit extended precision
>> floating point format, also known as "why bother".
>
> For one answer, people might like to read:
>
>      http://www.cs.berkeley.edu/~wkahan/Stnfrd50.pdf
>
> linked to from Kahan's page:
>
>      http://www.cs.berkeley.edu/~wkahan/
>

the upside of 80-bit floats: higher precision than 64-bit doubles;
the downside of 80-bit floats: slightly bigger than 64-bit doubles, and 
they are an inconvenient size.

but, I remember vaguely recently running into an issue:
32-bit floats are pretty much the standard in gaming.

so, originally, I used floats, and all was well (actually, many places 
were sub-float, as I had a "float28" which basically shaved the low 4 
bits off, mostly to allow essentially twiddling a float into a 32-bit 
pointer, or a so-called "flonum").


but, then there was a problem:
much more than about 1km from the origin (in a game from a first-person 
POV), there was obvious/noticeable jitter.

there was some rendering jitter (twitching geometry), and also the 
camera movement would jitter/shake, and if a weapon was fired the 
projectile itself would jitter and shake around as it moved, ...


so, there was a problem then: floats were not really sufficient.

second problem:
doubles don't actually work in the graphics hardware (they all assume 
"floats are plenty good enough" here as well).


so, partial solution:
many intermediate (server-end) calculations (and storage), are done 
using doubles (mostly things involving the object origin);
the client-side scene-graph also uses doubles.

however, there is a "reference point" which is now subtracted out of 
origins when sending them between the client and server (the main place 
where the 28-bit truncation occurs, but sending full doubles through 
here would be much more costly), and also the client-side rendering is 
performed relative to this reference-point (it is subtracted out when 
things are sent to the renderer).

note that only about a float-28 worth of accuracy is sent, but since it 
is relative to a point near the camera, they are more "the bits that count".


suddenly, now, the scene is no longer limited to around 1km or so (or, 
at least, not by jitter), however the second problem is that scenes are 
voxel-based, similar to Minecraft, and going too much over 1km^2 
requires large amounts of RAM. a partial way to combat this issue 
essentially involves RLE-compressing the voxel-chunks in RAM, and 
decompressing the chunks as-needed, though, there is still a limit as 
there is currently still no mechanism to "unload" chunks or regions 
which are out of range.


or such...

[toc] | [prev] | [next] | [standalone]

#2331

Chris Uppal wrote:

> Rui Maciel wrote:
> 
>> And let's not forget about the ever elusive 80-bit extended precision
>> floating point format, also known as "why bother".
> 
> For one answer, people might like to read:
> 
> http://www.cs.berkeley.edu/~wkahan/Stnfrd50.pdf

It appears that this text omits some important details which weight 
significantly on this issue.  For example, in the text's part 2, where the 
author refers to discretized elliptic boundary-value problems, it is said:

«(...) For many reasons not necessarily spawned by roundoff, the solution u 
has to be computed by an iteration, and that always entails the computation 
of a residual

r := b – (A + Diag(q))·u

The final accuracy of the computed u is limited by the accuracy with which 
the residual r can be computed. The accuracy of u , which is typically a 
potential, has to be sufficient to support differencing to estimate the 
Gradient Grad U(x), a field strength, without too much loss of accuracy to 
cancellation.»


What must be taken under consideration in this regard is that the 
coefficients of A, q and b tend to assume the form of integral expressions, 
whose values are generally obtained by employing quadrature and cubature 
rules.  

The problem with this approach is that, in general, these 
quadrature/cubature rules were developed so that their result is only exact 
if they are used to integrate functions of a specific type.  For example, a 
popular choise, the set of Gauss-Legendre quadrature rules, were devised to 
return the exact value of an integral if and only if the integrand function 
is a polynomial up to a certain degree.  When these quadrature rules are 
employed to integrate functions other than the one they actually can 
integrate, which is what happens in practice, they only return approximate 
results.

In other words, in this example, Matrix A and vectors q and b generally are 
themselves the result of an approximate calculation, and their error isn't 
small. To put things in perspective, It's not uncommon for these errors to 
be in the 1%-0.1% range.  In some commercial number crunching applications 
that implement this class of methods, the error even goes up to 3%-4% in 
come applications.

Meanwhile, discussing whether floats or doubles should be used is equivalent 
to discussing the significance of an error in the range of 0.0001%-0.00001%.

Hence, why bother?

To add insult to injury, discretized elliptic boundary-value problems only 
provide approximate solutions, unless we are dealing with a very specific 
problem.  This means that if somehow it was possible to run all floating 
point operations without introducing any rounding error or any precision 
degradation, the end result would always be an approximate solution, not the 
exact one.

So, although it might be nice to have heaps of precision at our disposal and 
a profound knowledge on how to leverage the existing tools to minimize this 
type of errors, spending time on this type of optimization, considering the 
returns that can be had from that investment, represents a complete waste of 
time.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#2332

"Rui Maciel" <rui.maciel@gmail.com> wrote in message
news:k59snb$oqm$1@speranza.aioe.org...
> Chris Uppal wrote:
>
>> Rui Maciel wrote:
>>
>>> And let's not forget about the ever elusive 80-bit extended precision
>>> floating point format, also known as "why bother".
>>
>> For one answer, people might like to read:
>>
>> http://www.cs.berkeley.edu/~wkahan/Stnfrd50.pdf

> In other words, in this example, Matrix A and vectors q and b generally
> are
> themselves the result of an approximate calculation, and their error isn't
> small. To put things in perspective, It's not uncommon for these errors to
> be in the 1%-0.1% range.  In some commercial number crunching applications
> that implement this class of methods, the error even goes up to 3%-4% in
> come applications.
>
> Meanwhile, discussing whether floats or doubles should be used is
> equivalent
> to discussing the significance of an error in the range of
> 0.0001%-0.00001%.
>
> Hence, why bother?

I didn't understand any of your argument. Using more precision is always
going to help some types of calculations. The difference between float and
double is a matter of 29 or so bits, about 500 million times more precision,
not the 10 to 100 million your figures suggest.

And the real reason for 80 bits, is probably that the mantissa is exactly 64
bits; that makes it attractive for the same sorts of reasons that 64-bit
processors are more popular than 52-bit ones. An 80-bit floating-point value 
can also represent a 64-bit integer exactly (signed *or* unsigned I 
believe). It's worth bothering with!

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#2333

On 10/12/2012 3:30 PM, BartC wrote:
> "Rui Maciel" <rui.maciel@gmail.com> wrote in message
> news:k59snb$oqm$1@speranza.aioe.org...
>> Chris Uppal wrote:
>>
>>> Rui Maciel wrote:
>>>
>>>> And let's not forget about the ever elusive 80-bit extended precision
>>>> floating point format, also known as "why bother".
>>>
>>> For one answer, people might like to read:
>>>
>>> http://www.cs.berkeley.edu/~wkahan/Stnfrd50.pdf
>
>> In other words, in this example, Matrix A and vectors q and b generally
>> are
>> themselves the result of an approximate calculation, and their error
>> isn't
>> small. To put things in perspective, It's not uncommon for these
>> errors to
>> be in the 1%-0.1% range.  In some commercial number crunching
>> applications
>> that implement this class of methods, the error even goes up to 3%-4% in
>> come applications.
>>
>> Meanwhile, discussing whether floats or doubles should be used is
>> equivalent
>> to discussing the significance of an error in the range of
>> 0.0001%-0.00001%.
>>
>> Hence, why bother?
>
> I didn't understand any of your argument. Using more precision is always
> going to help some types of calculations. The difference between float and
> double is a matter of 29 or so bits, about 500 million times more
> precision,
> not the 10 to 100 million your figures suggest.
>
> And the real reason for 80 bits, is probably that the mantissa is
> exactly 64
> bits; that makes it attractive for the same sorts of reasons that 64-bit
> processors are more popular than 52-bit ones. An 80-bit floating-point
> value can also represent a 64-bit integer exactly (signed *or* unsigned
> I believe). It's worth bothering with!
>

but it is an inconvenient size in that it requires 80 bits to store, 
which is not much more than 64 bits, but kills power-of-2 alignment, 
whereas a 64-bit double is still aligned by a power-of-2.

the next power-of-2 size is 128 bits, but using a 128-bit space to store 
an 80-bit value isn't very good, as nearly 1/2 of it is wasted (this is 
often what ends up in compilers though).

a float128 value is better, but then the drawback is a lack of hardware 
support, making it slow.

so, the cost/benefit tradeoffs point to double, which can exactly 
represent a value up to 52 bits, still goes pretty fast, and has a 
convenient storage size.

or such...

[toc] | [prev] | [next] | [standalone]

#2334

"BGB" <cr88192@hotmail.com> wrote in message 
news:k5a2hk$dve$1@news.albasani.net...
> On 10/12/2012 3:30 PM, BartC wrote:
>> "Rui Maciel" <rui.maciel@gmail.com> wrote in message

>>> Hence, why bother?

>> It's worth bothering with!
>>
>
> but it is an inconvenient size in that it requires 80 bits to store, which 
> is not much more than 64 bits, but kills power-of-2 alignment, whereas a 
> 64-bit double is still aligned by a power-of-2.

80-bits might have been intended for intermediate results only, hence no 
need to store them in that form in memory, although it was possible to do 
so. And when they were stored, it was more likely for individual results, 
rather than an array of such values.

> the next power-of-2 size is 128 bits, but using a 128-bit space to store 
> an 80-bit value isn't very good, as nearly 1/2 of it is wasted (this is 
> often what ends up in compilers though).

But, this thread also discussed shorter pointers (such as 40-bit ones, 
enough to address approx 1TB of RAM) needing 64 bits to store them in. That 
40/64 ratio is the same as 80/128! While the spare 48 bits between 80-bit 
floats could be used to store useful data in a way not possible with the 
pointers.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#2335

BGB <cr88192@hotmail.com> writes:

> On 10/12/2012 3:30 PM, BartC wrote:
>> And the real reason for 80 bits, is probably that the mantissa is
>> exactly 64
>> bits; that makes it attractive for the same sorts of reasons that 64-bit
>> processors are more popular than 52-bit ones. An 80-bit floating-point
>> value can also represent a 64-bit integer exactly (signed *or* unsigned
>> I believe). It's worth bothering with!
>
> but it is an inconvenient size in that it requires 80 bits to store,
> which is not much more than 64 bits, but kills power-of-2 alignment,
> whereas a 64-bit double is still aligned by a power-of-2.

The 8087, that introduced this 80-bit format, was coupled with
the 8086, which did not benefit from alignment beyond 16 bits.
And the 8088 that the 8087 was perhaps more often coupled with
did not benefit from alignment beyond 8-bit.

[toc] | [prev] | [next] | [standalone]

#2337

BartC wrote:

> I didn't understand any of your argument. Using more precision is always
> going to help some types of calculations.

Some, not all.  And if we really look into it, probably not most, at least 
in a meaningful way.  

Then, the argument I made in the previous post was that in a significant 
number of applications, the precision loss brought by relying on single 
precision types instead of higher-precision ones is completely irrelevant, 
as it is dwarfed when compared to other errors introduced by the 
implementation.  So, as it was the case in the "part 2" example I referred 
to, we see tons of attention invested in floating point while, at best, it 
is responsible for introducing an error which is orders of magnitude smaller 
than the error already introduced by the method itself.

Finally, when we factor in the performance penalty associated with using 
higher precision types, the irrelevant effect on precision factored with the 
higher computational cost does show that picking a higher precision floating 
point type can and does pose a problem.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#2338

"Rui Maciel" <rui.maciel@gmail.com> wrote in message 
news:k5beod$t0h$1@speranza.aioe.org...
> BartC wrote:
>
>> I didn't understand any of your argument. Using more precision is always
>> going to help some types of calculations.
>
> Some, not all.  And if we really look into it, probably not most, at least
> in a meaningful way.

> Finally, when we factor in the performance penalty associated with using
> higher precision types, the irrelevant effect on precision factored with 
> the
> higher computational cost does show that picking a higher precision 
> floating
> point type can and does pose a problem.

If the hardware can directly deal with 64-bit floats, then there is little 
performance loss (compared with attempting 64-bit arithmetic on 32-bit 
hardware, or in software).

The only issue might be memory bandwidth when dealing with large numbers of 
floating point values, although if they are accessed mainly for calculation, 
then it's possible the calculation will dominate the timings.

Anyway, I remember using 32-bit floats in an application (originally using 
software emulation), and they weren't of sufficient accuracy for some types 
of problems (mapping for example). They only have 1 in 8 million precision 
after all. Switching to 64-bits solved that problem.

Sometimes there are ways to get around such problems, and continue using 
32-bits, but sometimes also it's simpler to just use 64!

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#2339

BartC wrote:
) If the hardware can directly deal with 64-bit floats, then there is little 
) performance loss (compared with attempting 64-bit arithmetic on 32-bit 
) hardware, or in software).
)
) The only issue might be memory bandwidth when dealing with large numbers of 
) floating point values, although if they are accessed mainly for calculation, 
) then it's possible the calculation will dominate the timings.

Most CPU's nowadays can do parallel computations on 4 32-bit floats at the
same time, thus effectively quadrupling the speed.

) Anyway, I remember using 32-bit floats in an application (originally using 
) software emulation), and they weren't of sufficient accuracy for some types 
) of problems (mapping for example). They only have 1 in 8 million precision 
) after all. Switching to 64-bits solved that problem.
)
) Sometimes there are ways to get around such problems, and continue using 
) 32-bits, but sometimes also it's simpler to just use 64!

The point is that sometimes, using 32-bit floats is the best option.
Showing cases where 64-bit is the best option is irrelevant to that
position.


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

[toc] | [prev] | [next] | [standalone]

#2340

On 10/13/2012 7:34 AM, Willem wrote:
> BartC wrote:
> ) If the hardware can directly deal with 64-bit floats, then there is little
> ) performance loss (compared with attempting 64-bit arithmetic on 32-bit
> ) hardware, or in software).
> )
> ) The only issue might be memory bandwidth when dealing with large numbers of
> ) floating point values, although if they are accessed mainly for calculation,
> ) then it's possible the calculation will dominate the timings.
>
> Most CPU's nowadays can do parallel computations on 4 32-bit floats at the
> same time, thus effectively quadrupling the speed.
>

yep.

though in some cases there ends up being the funkiness of multiple types 
of FPUs:
the x87 style FPU;
the SSE SIMD FPU.

though in other cases, there just ends up being a lot more FPUs 
in-general, with lots of pipelining for x87 code.


> ) Anyway, I remember using 32-bit floats in an application (originally using
> ) software emulation), and they weren't of sufficient accuracy for some types
> ) of problems (mapping for example). They only have 1 in 8 million precision
> ) after all. Switching to 64-bits solved that problem.
> )
> ) Sometimes there are ways to get around such problems, and continue using
> ) 32-bits, but sometimes also it's simpler to just use 64!
>
> The point is that sometimes, using 32-bit floats is the best option.
> Showing cases where 64-bit is the best option is irrelevant to that
> position.
>

yep.

in some cases, double is needed.

in many cases, float is plenty sufficient, and a person is hard-pressed 
the huge memory waste that using doubles would bring.

sometimes, we can't even really afford the memory used by floats, and 
have to resort to more compact representations (storing values in 8 or 
16-bit representations).


for example, my recent foray into colored-lighting for voxels, left me 
with this particular scheme:
4 bits, light intensity, following a power curve;
4 bits, light color, based on a modified 16-color palette (6 pure 
colors, 6 half-saturation colors, white, orange/'greenish'/'sky').

and to speed up calculations ended up resorting to (*cough*) 
color-blending tables.

why all this? because these voxels eat up a fair chunk of RAM.
presently, each voxel is only about 8 bytes, but uses up a good chunk of 
a 4GB address space doing so (hence, why the previous RLE hack). such is 
the cost of x^3.

now, what about all the vertex-arrays?...
well, these are big as well, can't really afford doubles there either 
(nor does the graphics hardware really support them).

the vertex arrays eat lots of RAM, but have a more limited view-distance.


like, having lots more RAM doesn't help much when one puts lots more 
into it. a lot of this stuff couldn't really be done on older hardware.


or such...

[toc] | [prev] | [next] | [standalone]

#2342

"Willem" <willem@turtle.stack.nl> wrote in message
news:slrnk7invh.3eh.willem@turtle.stack.nl...
> BartC wrote:
> ) If the hardware can directly deal with 64-bit floats, then there is
> little
> ) performance loss (compared with attempting 64-bit arithmetic on 32-bit
> ) hardware, or in software).
> )
> ) The only issue might be memory bandwidth when dealing with large numbers
> of
> ) floating point values, although if they are accessed mainly for
> calculation,
> ) then it's possible the calculation will dominate the timings.
>
> Most CPU's nowadays can do parallel computations on 4 32-bit floats at the
> same time, thus effectively quadrupling the speed.

So? Perhaps they can do parallel computations on integer or fixed point
values even faster, so you need to look at that option too.

If speed is that much of an issue, then you look at all the options. But
given a floating point requirement which I can't immediately parallelise, I
tend to use the 64-bit floating point unit on my machine unless there is an
advantage to using 32-bits  (which of course applies to the representation
in memory, since the calculation is always 64-bits (or 80-bits) anyway).

> ) Sometimes there are ways to get around such problems, and continue using
> ) 32-bits, but sometimes also it's simpler to just use 64!
>
> The point is that sometimes, using 32-bit floats is the best option.
> Showing cases where 64-bit is the best option is irrelevant to that
> position.

And maybe 24 or 16-bits floats are best sometimes. Or maybe I don't
understand your point! I was replying to the implication that using higher
precision always imposes a "performance penalty"; I'm saying that sometimes
it doesn't!


-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#2344

BartC wrote:

>> Most CPU's nowadays can do parallel computations on 4 32-bit floats at
>> the same time, thus effectively quadrupling the speed.
> 
> So? Perhaps they can do parallel computations on integer or fixed point
> values even faster, so you need to look at that option too.
> 
> If speed is that much of an issue, then you look at all the options. 

In number crunching applications, speed is always an issue, only taking 
second place to correctness.  


> But
> given a floating point requirement which I can't immediately parallelise,
> I tend to use the 64-bit floating point unit on my machine unless there is
> an
> advantage to using 32-bits  (which of course applies to the representation
> in memory, since the calculation is always 64-bits (or 80-bits) anyway).

Nowadays, a programmer doesn't necessarily has to explicitly parallelize 
their code to benefit from that.  Compilers are able to pull some tricks 
automatically, even with the default options.


>> ) Sometimes there are ways to get around such problems, and continue
>> using ) 32-bits, but sometimes also it's simpler to just use 64!
>>
>> The point is that sometimes, using 32-bit floats is the best option.
>> Showing cases where 64-bit is the best option is irrelevant to that
>> position.
> 
> And maybe 24 or 16-bits floats are best sometimes. Or maybe I don't
> understand your point! I was replying to the implication that using higher
> precision always imposes a "performance penalty"; I'm saying that
> sometimes it doesn't!

The main point is that this "higher precision is always better" mantra is 
patently false.  There are plenty of cases where higher precision types are 
only able to provide an insignificant improvement while causing a 
significant performance penalty.  Having to pay a higher cost to get nothing 
in return is always a bad thing.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.programming

csiph-web