| |||||||||||||
|
| |||||||||||||
I fail to see the point...I fail to see the point...Posted Aug 6, 2009 8:29 UTC (Thu) by khim (guest, #9252)In reply to: A default desktop for openSUSE? by horen Parent article: A default desktop for openSUSE?
Even if the government starts giving "cash for clunkers" for computers, some of us will continue to run older PII and PIII workstations and laptops; don't plan on us going away, any time soon. There are no need. You can use your ancient PII or PIII workstation - just like you can use your ancient car. Just don't expect to buy spares and compatible addons in normal shop! For example I see no point in default GCC flags of Suse/Ubuntu/Fedora. Come on: why -msse2 -mfpmath=sse is not default today? Such changes should be no-brainer, but somehow every time it's rejected because some ancient CPUs don't support SSE2... Sigh...
(Log in to post comments)
I fail to see the point... Posted Aug 6, 2009 8:54 UTC (Thu) by james (subscriber, #1325) [Link]
And modern CPUs should be running x86_64, where those flags are the default.
Tell this to Intel! Posted Aug 9, 2009 12:24 UTC (Sun) by khim (guest, #9252) [Link] Sure, but they don't. Millions of netbooks sold today are sold without x86-64 support. Yet even distributions like Ubuntu Netbook Remix don't use SSE2 by defalut...
Tell this to Intel! Posted Aug 9, 2009 12:43 UTC (Sun) by nix (subscriber, #2304) [Link]
You can't just change the x86-32 ABI like that. You'd need to recompile
absolutely everything that used float/double/long double (at least in the interface and any exported variables). Every closed-source thing would also break and need recompilation (unless glibc took special measures to keep non-relinked stuff working against an old-ABI version of libm, and why would it?)
There's a reason the SSE2 shift only happened when we moved to x86-64:
Tell this to Intel! Posted Aug 14, 2009 4:44 UTC (Fri) by khim (guest, #9252) [Link] Every closed-source thing would also break and need recompilation (unless glibc took special measures to keep non-relinked stuff working against an old-ABI version of libm, and why would it? ) Why not? GlibC developers already introduced symbol visibility and versioning mechanisms in version 2.1 to solve this problem - and it works (there were quite a few changes in GlibC ABI over the years - all 99%- backward compatible; it's rare to see program which works with GLibC 2.x but not with GLibC 2.x+1 if x is at least "1"). Biggest win of "-msse2 -mfpmath=sse" mode is not fact that it's faster (it's roughly the same in speed) but the fact that it generates predictable code! Your program works the same way with -O0 and with -O2, it conforms to IEEE 754, etc. If you are doing a lot of math the benefits are enormous so you should switch and if not then you don't have a lot of FP in interfaces and/or exported variables so switch is no big deal...
Tell this to Intel! Posted Aug 14, 2009 7:26 UTC (Fri) by nix (subscriber, #2304) [Link]
So, you suggest... what? Versioning *every symbol* in *every shared
library* that uses a double anywhere in its interfaces? That's going to fly. (I wish symbol versioning were used more widely, but let's face it, upstreams mostly don't care and just stick to older techniques.)
Not exactly Posted Aug 14, 2009 9:29 UTC (Fri) by khim (guest, #9252) [Link] So, you suggest... what? Versioning *every symbol* in *every shared library* that uses a double anywhere in its interfaces? You only need this for libraries used by closed-source programs. Everything else can be just recompiled (with usual bump of library version). It's not a rocket science...
Not exactly Posted Aug 15, 2009 10:24 UTC (Sat) by nix (subscriber, #2304) [Link]
It's not rocket science, but still the upstreams of most major shared
libraries would simply laugh at you for suggesting it (except Ulrich, who'd snap at you instead).
I fail to see the point... Posted Aug 6, 2009 19:11 UTC (Thu) by jlokier (guest, #52227) [Link]
Distros have a version for older computers (32-bit), and a version for new computers (64-bit). New desktops and laptops are 64-bit now, so use the 64-bit version.
So why do you think the 32-bit version should drop support for computers which don't have SSE2? It's only purpose is to support old or unusual computers anyway.
I fail to see the point... Posted Aug 7, 2009 8:11 UTC (Fri) by farnz (guest, #17727) [Link] New computers and laptops are 32-bit, and are running CPUs that benefit from SSE2 math. Quite why Intel's Nxxx Atoms don't have EM64T or whatever they're calling it today is a different question.
I fail to see the point... Posted Aug 7, 2009 9:57 UTC (Fri) by jlokier (guest, #52227) [Link]
I see. I'm sympathetic, having a 32-bit Core Duo myself, and I guess I've been led astray by the KVM people who keep implying that 32-bit host support is some kind of anachronism which doesn't apply to new machines.
I fail to see the point... Posted Aug 11, 2009 11:42 UTC (Tue) by alankila (subscriber, #47141) [Link]
Before hyping all that 64-bit stuff one might do well to ensure that it works even half as good as 32 bits first. I'm dismayed to see that there is very little actual benefit to 64-bit system, yet a neverending sequence of downsides. Pretty much all advanced features in any new thing are delayed by years before they finally make it to 64 bits.
- firefox 3.5: no tracemonkey jit for 64 bits
In other words, the world is still firmly in 32-bit camp and 64-bit is an oddity looming in the horizon. The situation is probably changing, I guess, but in the meantime the practical choice is to improve 32-bit support as much as possible.
I fail to see the point... Posted Aug 11, 2009 21:41 UTC (Tue) by nix (subscriber, #2304) [Link]
Uh, doubling the size of pointers is *expected* with 64-bit. It's one of
the normal costs. Complaining about that is like complaining that 32-bit systems don't have 16-bit pointers.
I'm not sure tracemonkey JIT is terribly necessary on 64-bit systems right
I don't use Mono, but 'no support for SSE math' is very unlikely: the FPU
KVM has worse virtualization in 64-bit? Where? A good few virtualization
In the end, 64-bit is all that matters for larger systems.
Yes and no Posted Aug 14, 2009 4:36 UTC (Fri) by khim (guest, #9252) [Link] In the end, 64-bit is all that matters for larger systems. Actually for most tasks on "big systems" 32-bit mode is still better. The only piece of software which must be 64-bit is kernel. Sparc systems used this mode (64-kernel, 32-bit userspace) for years, funny how Linux world decided to skip this step and inflict unnecessary pain from the start...
Yes and no Posted Aug 14, 2009 4:52 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
there is one key difference between 64 bit sparc systems and the amd64 architecture.
on sparc systems there is very little difference between the two modes other than the pointer size (memory addressing), so the overhead of the larger pointers is noticable and a mixed-mode makes a lot of sense
also when sun designed the 64 bit sparc mode memory was _very_ expensive, and multi-user machines were the rule. so even if you had more than 4G of ram in a box, it would be very unusual for you to want a single process to use that much ram.
with the AMD64 architecture, one huge difference between 32 bit mode and 64 bit mode is that 64 bit mode has 16 registers instead of 8. this difference means that a lot more things can be done without spilling out to main memory (and as CPU's get faster the cost of spilling out to memory gets more significant)
if you want to see an example of this sort of optimization, look on the git mailing list for this month, there s a thread going on about optimizing the SHA1 code. the effect that eliminating thrashing out of the registers has is amazing, I think they are seeing a faxtor of ~6x between the different C implementations, and the 64 bit C code is within a percentage or so of the hand-tuned 32 bit assembler
also with home systems now selling with 8G of ram, and servers having 32G or more of ram, the odds that you want to have a process use more than 4G of address space go up significantly. I have perl scripts that I run doing log analysis that won't work on 32 bit systems due to memory limits.
Crypto is not a big part of life Posted Aug 14, 2009 10:02 UTC (Fri) by khim (guest, #9252) [Link] if you want to see an example of this sort of optimization, look on the git mailing list for this month, there s a thread going on about optimizing the SHA1 code. the effect that eliminating thrashing out of the registers has is amazing, I think they are seeing a faxtor of ~6x between the different C implementations, and the 64 bit C code is within a percentage or so of the hand-tuned 32 bit assembler Yes, it's well-known fact that crypto benefits from big number of registers, but is the SHA1 speed matter to you this much? More realistic tests show modest increase (more and bigger registers) or decrease (more memory pressure) in speed when you switch to 64bit! You can often win more with more sophisticated compiler (ICC, for example) - and no 2x memory requirement there! also with home systems now selling with 8G of ram, and servers having 32G or more of ram, the odds that you want to have a process use more than 4G of address space go up significantly. I have perl scripts that I run doing log analysis that won't work on 32 bit systems due to memory limits. Some few specialized processes will need this capability, yes, but most processes can live happily in 4GiB for long time yet. 16bit => 32bit switch happened when typical PC memory grew over 4MB - that's 64 times more then what native 16bit addressing can use! So I think 32bit switch should happen when typical PC memory will grow over 256GiB - not today.
Crypto is not a big part of life Posted Aug 15, 2009 3:07 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
two points.
it's not just hashes that benifit from more registers, most cpu-bound applications will benifit (not as drasticly, but notciably)
second 80286 16 bit systems had 24 bits of address space thanks to segmentation, so it could address up to 16M of ram, it was only after that that you _had_ to get a 32 bit processor (and even then you could fudge it with the hardware equivalent of PAE addressing)
so the move to 32 bit happened while system memory was still 1/4 what could be addressed by the processor
the problem with saying that only specialized processes need this much memory is defining ahead of time which processes those are.
should a distro compile perl for 32 bit or 64 bit? how are they going to know that I am going to run my log analysis scripts on this system and consider a 64 bit perl important?
it is _so_ much easier to just move everything over to 64 bit.
there are some things that don't work on amd64 systems, but those are closed-source plugins (stand-alone binaries have very few problems), and those same plugins won't work on arm, sparc, powerpc, etc.
Easier? Hardly. Posted Aug 16, 2009 6:57 UTC (Sun) by khim (guest, #9252) [Link] second 80286 16 bit systems had 24 bits of address space thanks to segmentation, so it could address up to 16M of ram, it was only after that that you _had_ to get a 32 bit processor (and even then you could fudge it with the hardware equivalent of PAE addressing) so the move to 32 bit happened while system memory was still 1/4 what could be addressed by the processor. You have a point - it means mass migration to 64bit is just around the corner: when 16GiB of RAM will be norm 64bit kernel will be norm. And just like then 32bit programs will be used for years after that point. should a distro compile perl for 32 bit or 64 bit? how are they going to know that I am going to run my log analysis scripts on this system and consider a 64 bit perl important? That's why it's important to have 64bit versions for different programs. For example Windows Vista does include 64bit version of MS IE and sizable list of other programs - even if hardly anyone uses them right now. it is _so_ much easier to just move everything over to 64 bit. What's the rush? there are some things that don't work on amd64 systems, but those are closed-source plugins (stand-alone binaries have very few problems), and those same plugins won't work on arm, sparc, powerpc, etc. Exactly: because "these same plugins" only work on IA32 "arm, sparc, powerpc, etc" are now extinct on desktop. Even much-hyped newcomer (I mean Itanic) went the same way. If you want to kill Linux too - feel free to force "pure 64bit" mode.
Crypto is not a big part of life Posted Aug 15, 2009 19:50 UTC (Sat) by njs (guest, #40338) [Link]
I think you're also underestimating the magnitude of the address space issues.
First, on 32-bit, processes only have 3G of address space (1G of addressing is reserved for the kernel so that syscalls won't require a memory context switch).
Second, that doesn't mean you can actually use 3G of memory in a 32-bit process, because of address space fragmentation. It's very easy, for example, to find yourself in a situation where you cannot allocate a large array (say, dozens of megabytes or larger) because there is no free gap in the address space that large where it can be placed. (There may also be TLB issues? I forget.) In general this gets complicated and its hard to know how fragmented any given program's address space will get, but as a rule of thumb one wants a fair amount of headroom. IIRC Linus has ranted somewhere about wanting a factor of 2-3x more address space than memory, and I bet your Firefox uses enough memory that by that standard it should be 64-bit :-).
Also, IIUC, The 16 -> 32 bit switch was delayed waiting for proprietary software vendors (Microsoft) to get their stuff together (they had to write a new OS and all that), with kluges like segmentation to carry things over in the mean time. We are a lot more competent these days.
Crypto is not a big part of life Posted Aug 15, 2009 23:10 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]
on my laptop top shows firefox is using 1862m Virt and 1.0g res
Crypto is not a big part of life Posted Aug 16, 2009 7:17 UTC (Sun) by khim (guest, #9252) [Link] First, on 32-bit, processes only have 3G of address space (1G of addressing is reserved for the kernel so that syscalls won't require a memory context switch). Have you forgotten what I wrote just above? I think it's time to use 64bit mode for kernel, but it's few years yet before we'll need 64bit in userspace. IIRC Linus has ranted somewhere about wanting a factor of 2-3x more address space than memory, and I bet your Firefox uses enough memory that by that standard it should be 64-bit :-). My Forefox uses 200MiB with it's two tabs - everything else is handled by Chrome. And each Chrome process is small enough to mollify even Linus: 290MiB at most. Not even 1/10 of address space available. Sadly Chrome for Linux is not yet compatible with a lot of plugins. Also, IIUC, The 16 -> 32 bit switch was delayed waiting for proprietary software vendors (Microsoft) to get their stuff together (they had to write a new OS and all that), with kluges like segmentation to carry things over in the mean time. We are a lot more competent these days. I'd say we are a lot more reckless these days. May be because we don't need to care about actual users and happy to leave them to certain vendor from Redmond...
Yes and no Posted Aug 14, 2009 7:25 UTC (Fri) by nix (subscriber, #2304) [Link]
Linux on SPARC did *not* skip that step.
|
|
||||||||||||