Personal computing discussed

Moderators: morphine, SecretSquirrel

 
Waco
Gold subscriber
Minister of Gerbil Affairs
Posts: 2667
Joined: Tue Jan 20, 2009 4:14 pm
Location: Los Alamos, NM

Re: Get your salt shaker handy -- Radeon 7 too expensive to sell?

Thu Feb 07, 2019 12:55 pm

Not many for consumers on GPUS. I literally meant "just play" for the most part. :P
Desktop: Z170A Gaming Pro Carbon | 6700K @ 4.4 | 16 GB | Radeon VII | XSPC RX360 | Heatkiller R3 | Samsung 4K 40" | 2048 + 240 + LSI 9207-8i (128x8) SSD
NAS: 1950X | Designare EX | 32 GB ECC | 7x8 TB RAIDZ2 | 8x2 TB RAID10 | FreeNAS | ZFS | LSI SAS
 
dragontamer5788
Gerbil Team Leader
Posts: 220
Joined: Mon May 06, 2013 8:39 am

Re: Get your salt shaker handy -- Radeon 7 too expensive to sell?

Thu Feb 07, 2019 1:06 pm

Waco wrote:
Not many for consumers on GPUS. I literally meant "just play" for the most part. :P


Well, I was hoping for some to play with myself if you knew any. Lol.

Like, I can see double-precision being useful for Finite Element Analysis (aka: virtual car crashes). Supercomptuers and software that calculate those sorts of things are very expensive. Double-precision is necessary because of the butterfly effect: very small differences in structure can result in a grossly different result. (Even double-precision isn't a real test, but the more precision you have, the better your simulation results get).

Alas, the last time I used FEA was in college, where $5000+ pieces of software was owned by the college labs that I could use for free. I'd assume modern versions of this code would be GPU accelerated but... I really don't know.
 
cynan
Gold subscriber
Graphmaster Gerbil
Posts: 1139
Joined: Thu Feb 05, 2004 2:30 pm

Re: Get your salt shaker handy -- Radeon 7 too expensive to sell?

Thu Feb 07, 2019 2:22 pm

dragontamer5788 wrote:
Waco wrote:
I nabbed one. Looking forward to a much needed upgrade from my Titan Xm for 4K gaming.

I'm thinking about programming my own stuff, but I rarely use doubles in my own code. Actually, I hate floating points in general because they're so wonky. But I'd think that 32-bit Floats of 2^128 to 2^-127 with ~7-decimal digits precision is enough for most cases.


About the only thing I use doubles for in the little bit of programming I do are large lists of output values from random number generating algorithms (to make sure I get the same result with a constant seed).
 
dragontamer5788
Gerbil Team Leader
Posts: 220
Joined: Mon May 06, 2013 8:39 am

Re: Get your salt shaker handy -- Radeon 7 too expensive to sell?

Thu Feb 07, 2019 2:46 pm

cynan wrote:
dragontamer5788 wrote:
Waco wrote:
I nabbed one. Looking forward to a much needed upgrade from my Titan Xm for 4K gaming.

I'm thinking about programming my own stuff, but I rarely use doubles in my own code. Actually, I hate floating points in general because they're so wonky. But I'd think that 32-bit Floats of 2^128 to 2^-127 with ~7-decimal digits precision is enough for most cases.


About the only thing I use doubles for in the little bit of programming I do are large lists of output values from random number generating algorithms (to make sure I get the same result with a constant seed).


Determinism btw isn't affected by single-floats vs double-floats. Errors propagate exponentially in all floating point applications. Integers (64-bit) are best for determinism, but if you want deterministic floats... going from single-to-double won't help at all!

Instead, determinism is achieved by recognizing that Floating-point operations are NOT associative. (A+B) + C will offer different results than A + (B+C) in the general case. The easiest way to achieve determinism, is to therefore sort your numbers before performing any series of calculations. If you have a list of numbers [5, 1, 7, 2, 3], then sorting them into ((((1+2)+3)+5)+7) ensures determinism in Floating-point settings. Sorting from smallest to largest magnitude helps out with cancellation error as well.

There are other methods to achieve bitwise determinism. But the sorting methodology is both educational and practically useful.

If that's too much effort, then just represent decimals as 64-bit integers. Pretend that all 64-bit integers are a number [0, 1) with value X / 2^64. It works surprisingly well in my experience, and avoid floating-point associativity / cancellation error issues.

Who is online

Users browsing this forum: No registered users and 2 guests