| |||||||||||||
|
| |||||||||||||
OpenOffice.org 3.0 releasedOpenOffice.org 3.0 releasedPosted Oct 14, 2008 5:17 UTC (Tue) by k8to (subscriber, #15413)In reply to: OpenOffice.org 3.0 released by efexis Parent article: OpenOffice.org 3.0 released
That problem was solved long ago. Pre-written code exists to use the machine values until you overflow and then trap the processor exception and special case from there on out.
Even if that wasn't true, the cost of doing slightly more math to figure out what memory to pull in is trivial compared to the slowness of pulling it in. The only downside is consuming more memory in the addressing.
(Log in to post comments)
The ONLY downside? Ha! Posted Oct 14, 2008 9:48 UTC (Tue) by khim (subscriber, #9252) [Link] The REAL downside is neither speed nor complexity. The REAL downside is the need to rewrite millions of already existing code which is designed to use fixed width numbers. I presume 256=>1024 was just a change in #define plus some testing, "unlimited" will be HUGE undertaking...
OpenOffice.org 3.0 released Posted Oct 14, 2008 10:40 UTC (Tue) by efexis (guest, #26355) [Link] "Pre-written code exists to use the machine values until you overflow and then trap the processor exception and special case from there on out"Yep, that's the conditional loop bit... you loop loading/comparing each byte/word at a time, until the condition (overflow) hits and says to stop. There might be prewritten code (like the gmp library I mentioned) but it's still orders of magnitude slower than what it would be for a fixed bit width. which can be aligned to fit many into cachelines etc. This wouldn't just need to be resolved for loading cells in, but all reference pointers (think loop variables that iterate through cells updating them) would need to be as this too. Quite how much noticable difference this makes on a modern processor though... couldn't say without some profiling info.
|
|
||||||||||||