[opensuse] 64 bit vs 32 bit RAM consumption
In googling the possibility of using a 64 bit kernel on an otherwise 32 bit openSUSE (consensus: don't try it), I found quite a bit of mention of 64 bit apps using twice as much RAM? Is this true? Or is it just misunderstanding arising from 64 bit using twice as many CPU registers to increase its own speed? Or something else? My main system running 32 bit 11.4 has 4GB RAM and is consistently using >50% of RAM for open apps, most of the rest for disk cache, and always around 360MB unused. Would running 64 bit on this system be consuming virtually all RAM for apps, leaving little free for disk cache? FWIW, not all RAM is "cheap". To bring this DDR2 system up to its 8GB max would cost ~$63USD. To replace its 2X2GB sticks with 2X4GB (to free them for RAM upgrade to another system) would cost triple that. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Tue, 23 Jul 2013 08:05:47 -0400 Felix Miata wrote:
In googling the possibility of using a 64 bit kernel on an otherwise 32 bit openSUSE (consensus: don't try it), I found quite a bit of mention of 64 bit apps using twice as much RAM? Is this true? Or is it just misunderstanding arising from 64 bit using twice as many CPU registers to increase its own speed? Or something else? My main system running 32 bit 11.4 has 4GB RAM and is consistently using >50% of RAM for open apps, most of the rest for disk cache, and always around 360MB unused. Would running 64 bit on this system be consuming virtually all RAM for apps, leaving little free for disk cache?
FWIW, not all RAM is "cheap". To bring this DDR2 system up to its 8GB max would cost ~$63USD. To replace its 2X2GB sticks with 2X4GB (to free them for RAM upgrade to another system) would cost triple that.
Hi Felix, FWIW, my principal system is a 64-bit Intel Core2Duo (T5800) based laptop with 4 GB RAM plus 512 MB dedicated VRAM on an nVidia GeForce 9300M GS graphics card. 64-bit 11.4 openSUSE + GNOME 2 ran beautifully on it. I keep literally a few dozen apps open at any given time, distributed across five desktops -- that's my work style, monitoring remote systems as well as building / debugging & updating websites, both locally and remotely -- and this configuration exhibited absolutely no memory constraints at all. I recently upgraded to openSUSE 12.3 on the same system, running KDE4 instead of GNOME 3, and I've had no memory problems, either. I think the real key to this problem is the underlying purpose for the machine, hence, the applications that are chosen to run on it. 3-D modeling, hosting VMs, video editing, high end gaming ... I suspect these are realms where 32-bit vs 64-bit vs available RAM becomes an issue. hth & regards, Carl -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carl Hartung said the following on 07/23/2013 08:41 AM:
I think the real key to this problem is the underlying purpose for the machine, hence, the applications that are chosen to run on it. 3-D modeling, hosting VMs, video editing, high end gaming ... I suspect these are realms where 32-bit vs 64-bit vs available RAM becomes an issue.
No disagreement. Even in the last century, 3-d modelling was a big industry. SUN and SGI and others built a business on machines that were capable in this are, even if we leave out 'Hollywood'. A lot of large manufacturing (e.g. the auto industry) subcontracted out parts and those subcontractors did a lot of 'modelling'. I new many small firms, individuals even, with SUNs and Indys who were making a good living in the 80s and 90s lower on this food chain. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
If you have 4G of RAM or less the real question is 'why bother?' The main advantage of 64-bit is the address space. For CAD, games and such and massively multi-user servers where there is more than 64G of memory, yes 64-bit addressing counts. -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 7/23/2013 11:40 AM, Anton Aylward wrote:
If you have 4G of RAM or less the real question is 'why bother?'
The main advantage of 64-bit is the address space. For CAD, games and such and massively multi-user servers where there is more than 64G of memory, yes 64-bit addressing counts.
Doesn't PAE play into this some how? http://en.wikipedia.org/wiki/Physical_Address_Extension My understanding is that PAE improvements allow 32bit code to handle up to 6gig of memory and still closely match 64bit performance, and under linux PAE support could handle up to 64gig of memory with a 32bit processor. At one time the PAE kernel was the OpenSuse default, maybe it still is for 32bit processors. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
John Andersen said the following on 07/23/2013 02:57 PM:
On 7/23/2013 11:40 AM, Anton Aylward wrote:
If you have 4G of RAM or less the real question is 'why bother?'
The main advantage of 64-bit is the address space. For CAD, games and such and massively multi-user servers where there is more than 64G of memory, yes 64-bit addressing counts.
Doesn't PAE play into this some how? http://en.wikipedia.org/wiki/Physical_Address_Extension
My understanding is that PAE improvements allow 32bit code to handle up to 6gig of memory and still closely match 64bit performance, and under linux PAE support could handle up to 64gig of memory with a 32bit processor.
At one time the PAE kernel was the OpenSuse default, maybe it still is for 32bit processors.
I tried running it once, its a performance hog, as compromises usually are. It's totally unsuitable for a serious server application, a large database server or the like. You could probably live with it for many desktop applications or if you simply had a desktop with more than 4G of memory and didn't have a 64-bit machine. Humans tolerate millisecond latency much better than high demand server applications. Addressing more than 4G of memory is the best reason I can think of for 64-but architecture. -- At least when humans go to casualty, they generally haven't gone into the Control Panel and messed with the settings... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
John Andersen wrote:
On 7/23/2013 11:40 AM, Anton Aylward wrote:
If you have 4G of RAM or less the real question is 'why bother?'
The main advantage of 64-bit is the address space. For CAD, games and such and massively multi-user servers where there is more than 64G of memory, yes 64-bit addressing counts.
Doesn't PAE play into this some how? http://en.wikipedia.org/wiki/Physical_Address_Extension
My understanding is that PAE improvements allow 32bit code to handle up to 6gig of memory and still closely match 64bit performance, and under linux PAE support could handle up to 64gig of memory with a 32bit processor.
Yep. I have an elderly 32bit box with 48Gb memory, it works very well. How much of a performance impact PAE really is, I don't know, but it has not been an issue. -- Per Jessen, Zürich (24.5°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Content-ID: <alpine.LNX.2.00.1307231444070.5519@minas-tirith.valinor> El 2013-07-23 a las 08:05 -0400, Felix Miata escribió:
In googling the possibility of using a 64 bit kernel on an otherwise 32 bit openSUSE (consensus: don't try it), I found quite a bit of mention of 64 bit apps using twice as much RAM? Is this true? Or is it just misunderstanding arising from 64 bit using twice as many CPU registers to increase its own speed?
It is true, in part. It depends on how the program defines values. If the programmer knows the maximum value of a variable (if he doesn't, he guesses and sets a limit), he may choose the smaller variable needed to hold it (the other criteria is the one that is faster to access for the architecture). Or he may simply choose a default value, like "integer". However, when the application was designed for 32 bit and then is re-compiled for 64, it may well happen that the size of the variable types chosen may shift from 32 to 64 bit - thus automatically the size of those variables increase to double. If that data space is large, the impact can be significant. Yes, it is a bug.
FWIW, not all RAM is "cheap".
Oh, absolutely. I upgraded my previous machine because I could not find RAM at a reasonable price. My advice is to upgrade machines RAM to the maximum when that RAM is still manufactured in large quantities. Later, availability decreases and price increases. - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlHuepwACgkQja8UbcUWM1wMDQEAn9GC5xzdyYChXz6mCz7379pj T/39cRbrbM+rgW4FVPIA+wSKlPk8Funxul+yh/Au6d8pwbMz9fDJt/7I/ZovAuFj =ZTWX -----END PGP SIGNATURE-----
Carlos E. R. wrote:
However, when the application was designed for 32 bit and then is re-compiled for 64, it may well happen that the size of the variable types chosen may shift from 32 to 64 bit - thus automatically the size of those variables increase to double.
Several years ago, I was taking a C programming course at a local college. In class, we were using Borland's Turbo C++ on Windows 3.11. At home I had Borland C++ for OS/2 (it's still sitting on my shelf). So, in class integers were 16 bits, but 32 bits at home. This caused problems on occasion, when code that worked perfectly at home would fail in class, due to the difference in integer size. ;-) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-07-23 a las 10:12 -0400, James Knott escribió:
Carlos E. R. wrote:
However, when the application was designed for 32 bit and then is re-compiled for 64, it may well happen that the size of the variable types chosen may shift from 32 to 64 bit - thus automatically the size of those variables increase to double.
Several years ago, I was taking a C programming course at a local college. In class, we were using Borland's Turbo C++ on Windows 3.11. At home I had Borland C++ for OS/2 (it's still sitting on my shelf). So, in class integers were 16 bits, but 32 bits at home. This caused problems on occasion, when code that worked perfectly at home would fail in class, due to the difference in integer size. ;-)
Oh, yes, but that is another issue. Typically, a variable would overflow earlier. - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlHukbEACgkQja8UbcUWM1zIIgD/XCyVma5V+syb6Avo3bzsPSeY EJ2EJGireJvPYJHaIqsA/iG9mWg8KWi4ZZ7XbBKbr78VL19BZ6l7Tb9BN+4tSmQl =nrfv -----END PGP SIGNATURE-----
On 7/23/2013 5:44 AM, Carlos E. R. wrote:
If the programmer knows the maximum value of a variable (if he doesn't, he guesses and sets a limit), he may choose the smaller variable needed to hold it (the other criteria is the one that is faster to access for the architecture). Or he may simply choose a default value, like "integer".
However, when the application was designed for 32 bit and then is re-compiled for 64, it may well happen that the size of the variable types chosen may shift from 32 to 64 bit - thus automatically the size of those variables increase to double.
If that data space is large, the impact can be significant.
Except that the impact isn't likely to be significant at all. The overwhelmingly vast majority of data in any system is not concerned with an integer here or a float there. The bulk of data, by a wide margin, is a string, or a block of text. In that world, a byte is still a byte. With bigger registers you can move data twice as fast, because the load time for 32 bits is the same for 64 bits. The programs instructions, your code pages, is the thing that might grow the most. Presumably most of that is optimized, but I really don't know for sure. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-07-23 a las 11:09 -0700, John Andersen escribió:
On 7/23/2013 5:44 AM, Carlos E. R. wrote:
If that data space is large, the impact can be significant.
Except that the impact isn't likely to be significant at all.
The overwhelmingly vast majority of data in any system is not concerned with an integer here or a float there. The bulk of data, by a wide margin, is a string, or a block of text. In that world, a byte is still a byte.
It can be gigabytes if the app does integer math on large data arrays. I did a proof of concept program somewhere that demonstrated the idea, and I did found time ago an application (commercial?) with this issue.
With bigger registers you can move data twice as fast, because the load time for 32 bits is the same for 64 bits.
Huh, not quite. If you have to add 2 and 3 it will take the same time on both archs. 64 bit is not faster, it is larger. Compare a road truck of 6 wheels to another of 12 wheels and double length.
The programs instructions, your code pages, is the thing that might grow the most. Presumably most of that is optimized, but I really don't know for sure.
- -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlHuzWIACgkQja8UbcUWM1xIyQD+IskPCTwTdNcw7uaRsqljWTzW 8L5RjUCE747Iik7E3RYBAIjgbSukgBKoHLtS+yoX32HSvYoRPorV+rvAxlVAlEuq =fyQR -----END PGP SIGNATURE-----
[23.07.2013 20:37] [Carlos E. R.]:
El 2013-07-23 a las 11:09 -0700, John Andersen escribió:
With bigger registers you can move data twice as fast, because the load time for 32 bits is the same for 64 bits.
Huh, not quite.
If you have to add 2 and 3 it will take the same time on both archs. 64 bit is not faster, it is larger. Compare a road truck of 6 wheels to another of 12 wheels and double length.
If you define 64bit integer variables and you store the values 2 and 3 inside those, the 64bit math will be a faster, since it requires only one register operation (per variable). On 32bit architecture, it may take two - unless you have a compiler that is smart enough to check for zeroes before adding ;-) Just my guess, Werner -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-07-23 a las 20:45 +0200, Werner Flamme escribió:
[23.07.2013 20:37] [Carlos E. R.]:
...
Just my guess,
And mine :-) - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlHu1yoACgkQja8UbcUWM1y84wD+KGsPAXkk/nH5CngJKi+xChsQ gr8PQXMX6R6AFnP2YYMA/3NtDBV7YLPrybRPunZvSxNtP/P1am7MkpW0rRh2DaM7 =nlIE -----END PGP SIGNATURE-----
Werner Flamme said the following on 07/23/2013 02:45 PM:
If you have to add 2 and 3 it will take the same time on both archs. 64 bit is not faster, it is larger. Compare a road truck of 6 wheels to another of 12 wheels and double length.
Huh? That doesn't make sense to me? Can you explain it it detail - and drop the analogy. Give op-code example. Doesn't have to be from a real machine, just hypothetical.
If you define 64bit integer variables and you store the values 2 and 3
... those are small integers ...
inside those, the 64bit math will be a faster, since it requires only one register operation (per variable). On 32bit architecture, it may take two - unless you have a compiler that is smart enough to check for zeroes before adding ;-)
Again, that doesn't make any sense. What zeros? Yes, 64-bit math will be faster, that is math involving integers greater than 2^32. How often do we do that? Apart, that is, from calculating addresses when we have an address space greater than can be addresses with 32-bits. But surely you're not doing that 'as arithmetic' but letting the compiler figure out the code for a pointer into an array. And I hope that you're not dealing with arrays of more than 2^32 elements ... What's that? Large text strings? You mean 'books'? -- The Soft overcomes the Hard The Slow overcomes the Fast Let your workings remain a mystery Just show people the Results -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
Yes, 64-bit math will be faster, that is math involving integers greater than 2^32. How often do we do that?
Well, IPv6 addresses are 128 bits. That's 2 words on a 64 bit CPU and 4 on a 32 bit. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott said the following on 07/23/2013 04:37 PM:
Anton Aylward wrote:
Yes, 64-bit math will be faster, that is math involving integers greater than 2^32. How often do we do that?
Well, IPv6 addresses are 128 bits. That's 2 words on a 64 bit CPU and 4 on a 32 bit.
Yes but both IPv4 and IPv6 have what amounts to segmented address spaces. Look at it this way (IPv4 example) If I have the 'Class C subnet' x.y.19.0..255 and Bob in the next township[1] has x.y.20.0..255 then when I'm auto-assigning addresses and get to x.y.19.225 and auto-increment do I end up with an address in a different subnet or no? Some things you don't do arithmetic on. [1] The joke is that James is - minus the city amalgamation that abolished all the village and townships - just a couple over from me. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
If I have the 'Class C subnet' x.y.19.0..255 and Bob in the next township[1] has x.y.20.0..255 then when I'm auto-assigning addresses and get to x.y.19.225 and auto-increment do I end up with an address in a different subnet or no?
The only time that's a factor is when deciding whether an address is on the local network or elsewhere. The application doesn't know, nor does TCP or UDP. It's only when you get to the IP layer that it becomes a factor. The IP layer then looks at the address & subnet mask and either handles the locally or sends it off to the router. Of course, when sent locally, you have to worry about the 48 bit MAC address, which will fit in a 64 bit register, but not 32. When using the subnet mask to determine if local or not, you have to do 32 bit (IPv4) or 128 bit (IPv6) logical operations to decide. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 El 2013-07-23 a las 15:44 -0400, Anton Aylward escribió:
Werner Flamme said the following on 07/23/2013 02:45 PM:
If you have to add 2 and 3 it will take the same time on both archs. 64 bit is not faster, it is larger. Compare a road truck of 6 wheels to another of 12 wheels and double length.
Huh? That doesn't make sense to me? Can you explain it it detail - and drop the analogy.
Give op-code example. Doesn't have to be from a real machine, just hypothetical.
No, I will not bother. If you don't understand it, I will not bother to explain. - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlHvC0UACgkQja8UbcUWM1yy3AD8CgsgpgvLn/oisnUtvc7wvydJ +Fq+kP7uf2v9mLwQKlgA/iij7myvwkrnTYaQOxxdYDQ1sQd50r1RP7tEfwo3Afcb =0Yyr -----END PGP SIGNATURE-----
Carlos E. R. said the following on 07/23/2013 07:01 PM:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
El 2013-07-23 a las 15:44 -0400, Anton Aylward escribió:
Werner Flamme said the following on 07/23/2013 02:45 PM:
If you have to add 2 and 3 it will take the same time on both archs. 64 bit is not faster, it is larger. Compare a road truck of 6 wheels to another of 12 wheels and double length.
Huh? That doesn't make sense to me? Can you explain it it detail - and drop the analogy.
Give op-code example. Doesn't have to be from a real machine, just hypothetical.
No, I will not bother. If you don't understand it, I will not bother to explain.
I think we're out of sequence here, Carlos. I'm in agreement with you, it was Werner's post I was questioning. It doesn't matter if the "2" and the "3" are in registers or memory, if its a register-to-register, register-to-memory or memory-to-memory operation. These are small integers. The issue is the op-code set. I couldn't figure what Werner's bit about 'zeros' had to do with it. The only reason I can' assert all this for an 8-bit machine is that it probably won't have op-codes for all those classes of operations. But yes, 64, 32 and 16 bit machines certainly. (I get to pick and choose, mind.) Actually, IIR the old Zilog Z-8000 architecture (which AMD produced to Avionic grade and to MIL-SPEC in small quantities) was a 16-bit machine where you could double up the registers and treat the top 8 16-bit registers as 4 32-bit registers and do 32-bit native operations on them. I suspect, but don't know for sure because I never used it, that the later 32-bit machine, the Z-80,000, could do a similar thing and run in 64-bit mode. Of course this is only arithmetic and logic, not address space. -- "Context is everything" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----Original Message----- From: Anton Aylward <opensuse@antonaylward.com> To: opensuse@opensuse.org Subject: Re: [opensuse] 64 bit vs 32 bit RAM consumption Date: Tue, 23 Jul 2013 19:35:51 -0400 Carlos E. R. said the following on 07/23/2013 07:01 PM:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
El 2013-07-23 a las 15:44 -0400, Anton Aylward escribió:
Werner Flamme said the following on 07/23/2013 02:45 PM:
If you have to add 2 and 3 it will take the same time on both archs. 64 bit is not faster, it is larger. Compare a road truck of 6 wheels to another of 12 wheels and double length.
Huh? That doesn't make sense to me? Can you explain it it detail - and drop the analogy.
Give op-code example. Doesn't have to be from a real machine, just hypothetical.
No, I will not bother. If you don't understand it, I will not bother to explain.
I think we're out of sequence here, Carlos. I'm in agreement with you, it was Werner's post I was questioning. It doesn't matter if the "2" and the "3" are in registers or memory, if its a register-to-register, register-to-memory or memory-to-memory operation. These are small integers. The issue is the op-code set. I couldn't figure what Werner's bit about 'zeros' had to do with it. The only reason I can' assert all this for an 8-bit machine is that it probably won't have op-codes for all those classes of operations. But yes, 64, 32 and 16 bit machines certainly. (I get to pick and choose, mind.) -----Original Message----- Let me chime in, Indeed the question if your dealing with mem or reg isn't that important. More relevant is the size on the variable you are working on. In one of my lab exercises we had to write a arithmetic-lib. When operating on uint128 with an 8-bit cpu, it takes quite more time and code, compared with a cpu with broader registers. The other way round, assuming a 64-bit datapath between cpu-and mem, fetching a 64-bit variable is as expensive as an 8-bit one. Between those obvious extremes, the is a large grey area. Secondly, the number of application (no number-crunching benchmarks) that uses var larger than 32-bit is very limited. It is more the OS that is using large numbers (mem, disk) _IF_ (!) programmers never used variables larger than they really needed, i would say that 32-bit would save time&mem. (i mean using 32-bit virtual machines inside a 64-bit KVM/XEN) As explained above using vars (data/pointers) larger than your internal architecture is costly. In those cases using 32-bit is contra-productive. Early on the thread, PAE was mentioned, i dare say it is an anachronism. Ten years ago, machines started to appear that could hold more than 4GB mem, but few applications were built for it. If you have 4GB or more installed, just go for a 64-bit OS. Personally, i use mostly use 32bit. Also because i have also to deal with much older hardware. hw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2013-07-24 09:57 (GMT+0200) Hans Witvliet composed:
If you have 4GB or more installed, just go for a 64-bit OS.
That's not what I get from this thread and http://en.wikipedia.org/wiki/64-bit_computing#32-bit_vs_64-bit shared by Anton. What I get is strongly prefer 64 bit if _more than_ 4GB. If 2GB or 3GB or 4GB, then use for video editing or other large file manipulation, or serving, or selected other activity indicates preference for 64 bit, else, 32 bit should in most cases be the better choice. If less than 2GB, probably best off with 32, as likely not using apps that would benefit from its additional power, while losing some available RAM due to greater need by 64 in certain situations.
Personally, i use mostly use 32bit. Also because i have also to deal with much older hardware.
Same here. I only installed 64 bit for the first time on any of my own less than a year ago when I upgraded 4 machines from P4s to Core2Duos from eBay. For working with HD video, the C2Ds made a big difference, but how much is from the better CPUs and how much from using 64 bit instead of 32 I've already forgotten, if I ever figured it out. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Felix Miata said the following on 07/24/2013 04:34 AM:
On 2013-07-24 09:57 (GMT+0200) Hans Witvliet composed:
If you have 4GB or more installed, just go for a 64-bit OS.
That's not what I get from this thread and http://en.wikipedia.org/wiki/64-bit_computing#32-bit_vs_64-bit shared by Anton.
Actually not me, but ...
What I get is strongly prefer 64 bit if _more than_ 4GB.
If you have more than 4G and are using a 32-bit machine then to use above 4G you are using PAE, which is sad and perhaps even sucks.
If 2GB or 3GB or 4GB, then use for video editing or other large file manipulation, or serving, or selected other activity indicates preference for 64 bit, else, 32 bit should in most cases be the better choice. If less than 2GB, probably best off with 32, as likely not using apps that would benefit from its additional power, while losing some available RAM due to greater need by 64 in certain situations.
There's nothing to stop you using a 64-bit CPU & 64-bit bus with less then 4G of RAM, if what you want is 64-bit computation, but its a bit like driving a Porch or Ferrari in the parts of the USA where you're limited to 55 MPH rather than in Germany where you can let the machine perform as it was designed. -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 7/24/2013 5:17 AM, Anton Aylward wrote:
If you have more than 4G and are using a 32-bit machine then to use above 4G you are using PAE, which is sad and perhaps even sucks.
Ah, NO. It doesn't suck. In fact for many years it was the default OpenSuse kernel. Its performance is more than acceptable on the hardware for which it was intended (32bit processors). Still today, for any 32bit machine it is the best route. If you think its sad or in some way a poor performer is only because you have never used it. For a long time is was by for the most popular route to more than 4gig of memory, because the 64bit kernels were way behind in that time. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
John Andersen said the following on 07/24/2013 01:42 PM:
On 7/24/2013 5:17 AM, Anton Aylward wrote:
If you have more than 4G and are using a 32-bit machine then to use above 4G you are using PAE, which is sad and perhaps even sucks.
Ah, NO. It doesn't suck.
In fact for many years it was the default OpenSuse kernel. Its performance is more than acceptable on the hardware for which it was intended (32bit processors). Still today, for any 32bit machine it is the best route.
If you think its sad or in some way a poor performer is only because you have never used it.
I think it sad and poor performer based on personal experience. For a while in the 11.4 days I *DID* run both the 'normal' and the PAE versions on my laptop. The difference was noticeable.
For a long time is was by for the most popular route to more than 4gig of memory, because the 64bit kernels were way behind in that time.
Yes, it was a solution to that problem, and as such it was a valid solution, if you needed to run an application that required the additional address space. What is sad is that, as you say, the 64-bit kernels were lagging. -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----Original Message----- From: Anton Aylward <opensuse@antonaylward.com> To: opensuse@opensuse.org Subject: Re: [opensuse] 64 bit vs 32 bit RAM consumption [summary] Date: Wed, 24 Jul 2013 16:37:26 -0400 I think it sad and poor performer based on personal experience. For a while in the 11.4 days I *DID* run both the 'normal' and the PAE versions on my laptop. The difference was noticeable.
For a long time is was by for the most popular route to more than 4gig of memory, because the 64bit kernels were way behind in that time.
Yes, it was a solution to that problem, and as such it was a valid solution, if you needed to run an application that required the additional address space. What is sad is that, as you say, the 64-bit kernels were lagging. -----Original Message----- Hm, afaicr it wasn't the kernel that was posing a problem in 64-bit land But specific HW-drivers and things like flash... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Wed, 24 Jul 2013 16:37:26 -0400 Anton Aylward <opensuse@antonaylward.com> пишет:
John Andersen said the following on 07/24/2013 01:42 PM:
On 7/24/2013 5:17 AM, Anton Aylward wrote:
If you have more than 4G and are using a 32-bit machine then to use above 4G you are using PAE, which is sad and perhaps even sucks.
Ah, NO. It doesn't suck.
In fact for many years it was the default OpenSuse kernel. Its performance is more than acceptable on the hardware for which it was intended (32bit processors). Still today, for any 32bit machine it is the best route.
If you think its sad or in some way a poor performer is only because you have never used it.
I think it sad and poor performer based on personal experience. For a while in the 11.4 days I *DID* run both the 'normal' and the PAE versions on my laptop. The difference was noticeable.
For a long time is was by for the most popular route to more than 4gig of memory, because the 64bit kernels were way behind in that time.
Yes, it was a solution to that problem, and as such it was a valid solution, if you needed to run an application that required the additional address space.
PAE does not increase application address space. It enables kernel to use more physical memory. Each application is still restricted to the same 4GB virtual memory.
What is sad is that, as you say, the 64-bit kernels were lagging.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday, 2013-07-25 at 06:44 +0400, Andrey Borzenkov wrote:
PAE does not increase application address space. It enables kernel to use more physical memory. Each application is still restricted to the same 4GB virtual memory.
Wasn't it 3? 3 GiB for the application, 1 GiB for the kernel, total 4 GiB. And each app was able to have a different 3 GiB block. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEUEARECAAYFAlH0GlcACgkQtTMYHG2NR9WUKQCgk51ov7s/HsYBdpw70X4/DMTQ PLAAlAqIwrQ34KmlyzqBhUSNITQ63Ek= =Pp+S -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, Jul 27, 2013 at 3:07 PM, Carlos E. R. <robin.listas@telefonica.net> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thursday, 2013-07-25 at 06:44 +0400, Andrey Borzenkov wrote:
PAE does not increase application address space. It enables kernel to use more physical memory. Each application is still restricted to the same 4GB virtual memory.
Wasn't it 3? 3 GiB for the application, 1 GiB for the kernel, total 4 GiB. And each app was able to have a different 3 GiB block.
1 GB for the kernel is a tunable default I believe. Tune it down to 0.75 GB and apps can have 3.25 GB. The total is 4GB. Greg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Wed, 24 Jul 2013 04:34:48 -0400 Felix Miata <mrmazda@earthlink.net> пишет:
On 2013-07-24 09:57 (GMT+0200) Hans Witvliet composed:
If you have 4GB or more installed, just go for a 64-bit OS.
That's not what I get from this thread and http://en.wikipedia.org/wiki/64-bit_computing#32-bit_vs_64-bit shared by Anton. What I get is strongly prefer 64 bit if _more than_ 4GB. If 2GB or 3GB or 4GB, then use for video editing or other large file manipulation, or serving, or selected other activity indicates preference for 64 bit, else, 32 bit should in most cases be the better choice.
There is memory range below 4G which is reserved for PCI address mapping. Size can be quite significant - if you are using 32 bit system you can lose as much as (or even over) 1G of your memory. So I'd say - as long as you have over 2G of physical RAM having 64 but kernel makes all sort of sense. Having 64 bit user programs is more or less independent question. Here x32 comes in play. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2013-07-24 12:43 (GMT-0400) Andrey Borzenkov composed:
There is memory range below 4G which is reserved for PCI address mapping. Size can be quite significant - if you are using 32 bit system you can lose as much as (or even over) 1G of your memory.
My experience is that reserved space is much closer to negligible: http://fm.no-ip.com/SS/ram-consumed-server01.png
So I'd say - as long as you have over 2G of physical RAM having 64 but kernel makes all sort of sense.
As does 32 up through 4GB, again, depending on primary usage. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
В Wed, 24 Jul 2013 13:09:32 -0400 Felix Miata <mrmazda@earthlink.net> пишет:
On 2013-07-24 12:43 (GMT-0400) Andrey Borzenkov composed:
There is memory range below 4G which is reserved for PCI address mapping. Size can be quite significant - if you are using 32 bit system you can lose as much as (or even over) 1G of your memory.
My experience is that reserved space is much closer to negligible: http://fm.no-ip.com/SS/ram-consumed-server01.png
Top knows nothing about this range. This memory is unavailable and invisible for operating system. My notebook has exactly 4GB of physical RAM bor@opensuse:~> cat /proc/mtrr reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back reg02: base=0x0c0000000 ( 3072MB), size= 512MB, count=1: write-back reg03: base=0x100000000 ( 4096MB), size= 512MB, count=1: write-back reg04: base=0x0dff00000 ( 3583MB), size= 1MB, count=1: uncachable 512MB immediately below 4GB can be made available only by remapping them above 4GB address space. So you need kernel with support for addressing of more than 4GB. Which means either 64 bit or PAE. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2013-07-25 06:43 (GMT+0400) Andrey Borzenkov composed:
512MB immediately below 4GB can be made available only by remapping them above 4GB address space. So you need kernel with support for addressing of more than 4GB. Which means either 64 bit or PAE.
PAE was installed in the form of kernel-desktop on all my openSUSE P4 systems. This with 4GB: cat /proc/mtrr reg00: base=0x100000000 ( 4096MB), size= 512MB, count=1: write-back reg01: base=0x120000000 ( 4608MB), size= 128MB, count=1: write-back reg02: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back reg03: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back reg04: base=0x0c0000000 ( 3072MB), size= 256MB, count=1: write-back reg05: base=0x0d0000000 ( 3328MB), size= 128MB, count=1: write-back reg06: base=0x0d7f00000 ( 3455MB), size= 1MB, count=1: uncachable reg07: base=0x0d8000000 ( 3456MB), size= 128MB, count=1: write-combining The division of 0x0c0000000 & up into multiple regions, 06 of which is only 1MB, seems to mirror my recollection of using QEMM to manage the first MB in DOS many moons ago. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Andrey Borzenkov said the following on 07/24/2013 12:43 PM:
if you are using 32 bit system you can lose as much as (or even over) 1G of your memory.
Gee WOW! I never realised! That means this office full of machines with only 1G of memory that I've almost finished upgrading to 12.3[1], and are all the old but not yet assigned to the Closet of Anxieties crappy old 800 Mhz machines - 32-but intel i686 that report CPU MHz: 801.808 BogoMIPS: 1603.61 and run basic office applications, T'bird, FF, open office under XFCE must all be doing something different. I've had a couple run in half a G of memory back in the 11.4 days, but if they ran more than just T'bird they thrashed. My belief was that the kernel 'sized' memory at start up and created mapping table proportionately. I have no doubt that there is some fixed amount of memory that the kernel needs to deal with the hardware, it cant be 1G. [1] And the reaction to upgrading to 12.3 is generally "Wow, its much faster now. What did you do?" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hans Witvliet said the following on 07/24/2013 03:57 AM:
Let me chime in,
I'm so glad you're clarifying this and taking it in parts rather than painting with a ridiculously wide brush.
Indeed the question if your dealing with mem or reg isn't that important. More relevant is the size on the variable you are working on.
Right. Programming - certainly application programming - where, for example, loop counters are small (less than 2^32) then ... see earlier. Reality is that there is a poison curve here: most such counters are small. I don't think we have disagreement here.
In one of my lab exercises we had to write a arithmetic-lib. When operating on uint128 with an 8-bit cpu, it takes quite more time and code, compared with a cpu with broader registers.
Ah, lab exercises. I've got no argument with this either, but how often are embedded 8-bit micro-controllers dealing with uint128 variables? I spent nearly a decade dealing with such small machines, as I say, 'embedded systems' and a few higher level UI level/presentation level stuff. Yes there was a lot of 16 bit arithmetic and most of that was address calculations. The bulk of the work was flipping bits on and off in individual bytes. To be honest, a 16-bit machine wouldn't have been faster for that part of the work.
The other way round, assuming a 64-bit datapath between cpu-and mem, fetching a 64-bit variable is as expensive as an 8-bit one.
We've met this many times. Many of the IBM /360 machines had a cheap option of a narrow memory path but a wide computation path. The original IBM PC used an 8088 which was a 16-nit engine with a 8-bit external data path. False economies in my opinion, but that's what happens when marketing gets an upper hand.
Between those obvious extremes, the is a large grey area.
And there you have it. You might notice a theme in what I've been presenting. I've tended to focus on the application side of things. So ...
Secondly, the number of application (no number-crunching benchmarks) that uses var larger than 32-bit is very limited. It is more the OS that is using large numbers (mem, disk)
Oh YES! very YES! and Very YES! YES! YES! in server type applications which use large amounts of disk and large amounts of memory. As opposed to a typical (well here at least) desktop that uses between 1G and 4G of memory.
_IF_ (!) programmers never used variables larger than they really needed, i would say that 32-bit would save time&mem. (i mean using 32-bit virtual machines inside a 64-bit KVM/XEN)
Or raw 32-bit machines without virtualization ... That's not a big "IF". I'm sure if we go thorough the apps in the distribution, even the 64-bit distribution, we'll find most use smaller variables. Loop counters, character arrays and indexes, all that kind of stuff. There's a class of applications that use ether the BIGNUM arbitrary precision library of the floating point library - by design. I very much doubt those kinds of applications will benefit from from 64-bits as such. Yes, a 64-bit machine might be able to handle floating point better, faster, but its still floating point, which isn't what we're discussing here. You could just as well do what IBM do and have a 128-bit bus on a 64-bit machine to reduce bus cycles. Perfectly valid. You could have a 128-bit bus doing prefech/pipeline for an 8-bit machine as well ...
As explained above using vars (data/pointers) larger than your internal architecture is costly. In those cases using 32-bit is contra-productive.
Lets put that back in context since it works both ways: If you have a 64-but architecture, something that needs 64-but calculations to address memory, your database, then doing the arithmetic on a 32-bit machine is costly. If you are doing an application controller that is manipulating bytes by byte and masking, then you should ask if a 32-bit machine or a 64-bit machine is giving any advantage since you're not doing any 32-bit or 64-bit calculations. It maybe that sometimes you can do a wide mask operation, but for the most part, I found, such operations were 'narrow'. Realistically I found that that many needed algorithms that simply wouldn't fit into the ROM of a 8035 so I welcomes the advent of the 16-bit machines for their code-space rather than any computation. I loved the z-8000 because I implemented a very fast FORTH interpreter; it was fast because having the 16 registers that like on the PDP-11 or the /360 they were 'equivalent' (unlike the z-80/8085/8086/68000) I could keep the top few elements of the FORTH evaluation stack in the upper part of the register bank and use the lower part as pointers to other stacks. If you're familiar with FORTH you'll see what I mean.
Early on the thread, PAE was mentioned, i dare say it is an anachronism.
+1
Ten years ago, machines started to appear that could hold more than 4GB mem, but few applications were built for it. If you have 4GB or more installed, just go for a 64-bit OS.
Using that memory is the best justification I can think of.
Personally, i use mostly use 32bit. Also because i have also to deal with much older hardware.
You're not alone. Most machines here are not only 32-bit but have 1G or less of memory and slower CPUS. But then they are only used for e-mail, browsing, a bit of word processing and such. No CAD or gaming (Well I'm sure people play solitaire and such on the sly), no large photo processing or AV apps. 'Modelling' is mostly with mind-mapping using some Java applications. I'm privileged to have a 64-bit AMD desktop ... but only 4G of memory :-( The thing is that few machines have large disks; most are 20G, a few 40G. All the real disk storage is on the servers and accessed via NFS. Recall what I said about servers and gobs of memory and gobs of disk and 64-bit machines..... OK, so this isn't an 'internal cloud' -- yet. But I do know someone who has converted his home server to some cloud stack from simply being a a file server. Yes, he has a big family, big house and works at home with a 3-screen setup. He can justify all that more than some small businesses - he is a small business! I keep saying Context is Everything and that's what you should consider. One size does not fit all. -- Well, they asked me in February, and I said it was coming out in November. When they asked in March, I said it was coming out in November. In April I pointed out that November, in fact, was going to be when the next book came out. In May, when asked on many occasions about when Maskerade was coming out, I said November. In November, it will be published. The same November all the way through, too. -- So Terry, when is 'Maskerade' coming out, then? (Terry Pratchett, alt.fan.pratchett) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
False economies in my opinion, but that's what happens when marketing gets an upper hand.
IIRC, one of the reasons for this was so the existing 8 but support chips could be used. These were originally designed for the 8080 & 8085 and could be used with the 8088. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott said the following on 07/24/2013 08:26 AM:
Anton Aylward wrote:
False economies in my opinion, but that's what happens when marketing gets an upper hand.
IIRC, one of the reasons for this was so the existing 8 but support chips could be used. These were originally designed for the 8080 & 8085 and could be used with the 8088.
There would be no problem with the support chips, the IO, DMA and so on. No, the issue was around the data bus. The 8086, and the 8080 couldn't drive the data bus, they needed the address latches and buffer drivers. The incremental cost of the extra set of components for the 16-bit bus was what made the decision. There is an irony to this. Semiconductor components have always had an aggressive pricing curve, both with quantity and time. By the time the IBM PC hit the showroom shelves the cost of those extra components meant that a fill 16-bit bus with an 8086 would have been cheaper than the 8-bit with 8088 at time the original costing was carried out. The joke comparing automobiles to computers comes to mind. At a recent computer exposition, Bill Gates reportedly compared the computer industry with the auto industry and stated: "If General Motors had kept up with the technology like the computer industry has, we would all be driving $25.00 cars that got 1,000 miles to the gallon." but don't forget http://thenextweb.com/shareables/2012/07/23/first-portable-computer-55-pound... -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward [24.07.2013 17:17]:
The joke comparing automobiles to computers comes to mind.
At a recent computer exposition, Bill Gates reportedly compared the computer industry with the auto industry and stated: "If General Motors had kept up with the technology like the computer industry has, we would all be driving $25.00 cars that got 1,000 miles to the gallon."
In response to Bill's comments, General Motors issued a press release (by Mr. Welch himself) stating: see <http://www.snopes.com/humor/jokes/autos.asp> :-) *bg*, Werner -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Content-ID: <alpine.LNX.2.00.1307241237530.6503@minas-tirith.valinor> El 2013-07-23 a las 19:35 -0400, Anton Aylward escribió:
Carlos E. R. said the following on 07/23/2013 07:01 PM:
No, I will not bother. If you don't understand it, I will not bother to explain.
I think we're out of sequence here, Carlos. I'm in agreement with you, it was Werner's post I was questioning.
I'll modify my simile, after reading recent posts here. If you have to add 2 and 3 it will take the same time on both archs. 64 bit is not faster, it is larger. Compare a road truck of 6 wheels to another of 12 wheels and double length. If you are adding numbers bigger than 32 bit, then the 64 bit cpu is faster. Ie, when trucking loads bigger than fit on the smaller truck. Which is a simile intended for people not deep versed in cpu details ;-) - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlHvr3cACgkQja8UbcUWM1zcCwD9Gc4uhMMT4abA5J1dEa2Ca02G SbIbMuv3vRxPiMcla4IA/1nMi85lBog04csFbjAi1qHMKTw2WiSaMIpNguM1fukj =xhi3 -----END PGP SIGNATURE-----
On 7/23/2013 11:37 AM, Carlos E. R. wrote:
With bigger registers you can move data twice as fast, because the load time for 32 bits is the same for 64 bits.
Huh, not quite.
If you have to add 2 and 3 it will take the same time on both archs. 64 bit is not faster, it is larger. Compare a road truck of 6 wheels to another of 12 wheels and double length.
Apples/Oranges.... Adding isn't just moving, and you are still taking about integer maths. Moving blocks of text or strings around is a far more common task for a computer than dealing with huge arrays. This email, that you are looking at this very instant is a perfect example. Moving the text body of the email from the the file to your screen was probably handed over to a string move operation. If the compiler writer did his work properly, the compiler will use 64bit registers to move that string, resulting in fewer actual load/store operations, and those operations (typically) operate in the same number of clocks. So fewer moves happening at the same speed = much shorter execution time. Like I mentioned, its taken years for the compiler writers to catch up, so results have changed over time. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
John Andersen said the following on 07/23/2013 02:47 PM:
[....]
Moving the text body of the email from the the file to your screen was probably handed over to a string move operation. If the compiler writer did his work properly, the compiler will use 64bit registers to move that string, resulting in fewer actual load/store operations, and those operations (typically) operate in the same number of clocks. So fewer moves happening at the same speed = much shorter execution time.
You're going to have to explain that in more detail because as it is it doesn't make sense to me. I can see three cases: First, the old, old way where the OS got the disk driver or network driver to read the 'mail file' body into buffer memory and then copy that buffer into 'user space'. I recall the old PDP-11 UNIX 7 code for this kind of thing. while (i--) { *p++ = *s++' } Or the assembler equivalent. Later there was the hand coded "block move instruction" involving three registers, counter, source pointer, destination pointer. But it amounted to the same thing, just done in microcode rather than macrocode. Second came virtual memory. Still read into the buffer, but now there was a fiddle with the mapping tables and now LO! that memory is now addressable in user space. No move needed. Third, is what I think you are talking about and I must say it makes no sense to me. A 64-bit register has 8 bytes, a 32-bit register has 4 bytes and a 16-bit register has 2 bytes. Back in the old days of 8-but machines a 'move' involved reading a byte from memory into a register from one location into a register and writing it out to another. Part of the reason for this was that (a) such systems didn't have virtual memory to do by remapping and (b) the limited instruction sets didn't support memory to memory operations. So if you are caught up in this programming paradigm when you graduate to 16-but you do the same thing two bytes at a time and with 32-but machines four bytes at a time and with 64-but machines, eight bytes at a time. But the reality is that while with UNIX we do a lot of character manipulation, its never as blunt as that. If we are operating on strings we can't assume that are a multiple of eight bytes long. And they are going to be null terminated, so we see a lot of while (*p != '\0') { .... We might also be looking for membership of sets of characters: numbers, alpha, punctuation ... But even when we do see that the string runs from there to there, why stuff it into a register or register bank? Even if we are thinking for some reason of manipulating a string 8 characters at time the cost of coming up with the necessary 'masks' and the dealing with the 'residual' part of the string is going to be computationally more expensive. And the algorithm ... oh my, I'd hate to have to debug that! I'm a believer in KISS. Perhaps, John, you were thinking of something different from what I've thought of. If so, please do explain.
Like I mentioned, its taken years for the compiler writers to catch up, so results have changed over time.
Yes, on many projects I've taken the architects to task about their instructions about programming style by showing that the output from the compiler makes a mockery of what they were envisioning. I recall one project where they waxed on about absolute addressing and efficiency of access. The only thing was that the C compiler for the VAX, and I found alter the FORTRAN compiler as well, had the concept of a 'global data segment pointer' and all the variable you thought were being addresses at absolute locations were actually indexed off this pointer. And the pointer was in the outermost calling frame of the stack, in the start-up code before "main()" was called, and was loaded, when needed, into a register, by indexing of the calling frame nesting pointer. The compiler was smart, though. It only loaded the global data segment pointer into a register when and if you needed to access a global variable, and was very good about leaving it there and not 'dumping' it unless the computational demands for a register exceeded what was otherwise unused. Some compilers are smarter than programmers. Call them "expert systems in code generation". -- The truth of a proposition has nothing to do with its credibility. And vice versa. Excerpt from the notebooks of Lazarus Long, from Robert Heinlein's "Time Enough for Love" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Felix Miata said the following on 07/23/2013 08:05 AM:
In googling the possibility of using a 64 bit kernel on an otherwise 32 bit openSUSE (consensus: don't try it), I found quite a bit of mention of 64 bit apps using twice as much RAM? Is this true? Or is it just misunderstanding arising from 64 bit using twice as many CPU registers to increase its own speed? Or something else? My main system running 32 bit 11.4 has 4GB RAM and is consistently using >50% of RAM for open apps, most of the rest for disk cache, and always around 360MB unused. Would running 64 bit on this system be consuming virtually all RAM for apps, leaving little free for disk cache?
We've - the larger community - have had this argument a couple of times before. There were a lot of simple (as in not complex or bloated) applications for the Z-80 and its peers, 8-bit systems, that worked very well, thank you, up to an including some basic word processing applications. Oh, and a LOT of embedded systems. When 16-bit processors came along were they really needed? For speed? No! For additional functionality? Well, that's how they were sold. We had this same pizzing match when Vaxen replaced PDP-11s as UNIX backbones. It was more justifiable then, but still, there was a lot of bloat. The argument revolved around two things. The first was 'constants' and counters. Many initialization values were small numbers, zero and one being, thank you Poisson and in particular Benford's law http://en.wikipedia.org/wiki/Benford%27s_law so having bytes for these rather than 16-bit or now 32-bit integers made more sense. The second was addressing. This went hand in hand with address space. An efficient compiler (and in the Z-80 days that might mean a human) could use relative branches, shorter code than absolute addresses. larger address spaces tended to drag in a lot of non-tight coding because addresses were often resolved at link-time, the programs being bigger for various reasons (think of it as a version of Parkinson's Law -- code expands to fill the available space) and you don't know at compile time how 'far away' the destination of a call or jump will be. Are these valid arguments? Well there are always counter arguments. Its very hard to justify what amounts to 'parsimony' when the forces of market economics has moved on. Yes, a 5MHz Z-80 may do the fob and chip yields of that will be fantastic and won't require the advanced technology (and cost) of what is being produced today. Not quite 'garage entrepreneur' but not far from it. Similarly low demands of memory, memory speed, circuit boards (think capacitors) and so on. After all, if we strip out the creeping featureism, many embedded systems really don't need complex controllers. I think of the amazing things I did in the 1970s with Z-80s and even those rom-in-a-cpu from Intel, https://en.wikipedia.org/wiki/Intel_MCS-48 and even http://www.cpu-world.com/CPUs/8035/ While, as https://en.wikipedia.org/wiki/Embedded_system points out, many embedded systems need to keep costs down (and that includes production costs and maintenance, so simple & reliable hardware counts) and so 'economy of scale' applies (and mature devices like the microelectronics from the 1970s figure), I've also done some larger, one-off applications, treating the core as a FORTH engine. =================================== Well, that's what was, and still is, I suppose, the reasoning behind the reluctance to move to 16-bit, 32-bit and now 64-bit. The arguments in favour amount to things like "more power", but lets face it, how often is the 'more power' actually eaten up by what amounts to 'eye candy'? I can see that server farms need 'more power', but that's as a much an argument for installing those neato-small IBM "mainframes' that run over 4,000 instances of SLES as it is for 64-but Intel slices. Desktop? What, games? maybe you need a better graphics engine instead of a 64-but main CPU. Because, lets face it, the legacy of the Intel x86 architecture and its archaic instruction set (aka 'backward comparability') costs in terms of silicon real-estate, complexity and hence production cost to Intel/AMD and power costs to you. No wonder the ARM chips in phones and tablets can do so well and make batteries last for days! ====================================== Agree or disagree - this is most likely a religious war. I keep saying "Context is Everything", and that's one reason I pointed to embedded systems and things that are too small/light to need an OS. If you want 'eye candy', if you're a gamer, that's fine. I have no argument, but do recognise that there are other people with other needs. -- The man who trades freedom for security does not deserve nor will he ever receive either -- Benjamin Franklin -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Felix Miata wrote:
In googling the possibility of using a 64 bit kernel on an otherwise 32 bit openSUSE (consensus: don't try it), I found quite a bit of mention of 64 bit apps using twice as much RAM? Is this true? Or is it just misunderstanding arising from 64 bit using twice as many CPU registers to increase its own speed? Or something else? My main system running 32 bit 11.4 has 4GB RAM and is consistently using >50% of RAM for open apps, most of the rest for disk cache, and always around 360MB unused. Would running 64 bit on this system be consuming virtually all RAM for apps, leaving little free for disk cache?
The same claims were made when we went from 8 to 16 and 16 to 32 bit CPUs and reflect a lack of knowledge about how things work. For example, a larger instruction set means you may be able to get by with fewer instructions. It shouldn't affect data at all, as the CPUs have instructions for working with smaller than register size data. Take a look at file sizes in 32 & 64 bit systems. You'll likely find the sizes are similar. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 7/23/2013 7:07 AM, James Knott wrote:
Felix Miata wrote:
In googling the possibility of using a 64 bit kernel on an otherwise 32 bit openSUSE (consensus: don't try it), I found quite a bit of mention of 64 bit apps using twice as much RAM? Is this true? Or is it just misunderstanding arising from 64 bit using twice as many CPU registers to increase its own speed? Or something else? My main system running 32 bit 11.4 has 4GB RAM and is consistently using >50% of RAM for open apps, most of the rest for disk cache, and always around 360MB unused. Would running 64 bit on this system be consuming virtually all RAM for apps, leaving little free for disk cache?
The same claims were made when we went from 8 to 16 and 16 to 32 bit CPUs and reflect a lack of knowledge about how things work. For example, a larger instruction set means you may be able to get by with fewer instructions. It shouldn't affect data at all, as the CPUs have instructions for working with smaller than register size data.
Take a look at file sizes in 32 & 64 bit systems. You'll likely find the sizes are similar.
Nice theory, if you code in assembler. But for the most of us, sitting behind a compiler, we are at the complete mercy of the compiler writers, and there was a lag of over a year before these were optimized for larger instructions and larger registers. Just shlepping large chunks of text around was still done in small 32bit chunks until the compilers caught up. Anyway, there is a discussion of this here: http://en.wikipedia.org/wiki/64-bit_computing#32-bit_vs_64-bit -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
John Andersen said the following on 07/23/2013 02:23 PM:
Take a look at file sizes in 32 & 64 bit systems. You'll likely find the sizes are similar.
Nice theory, if you code in assembler.
But for the most of us, sitting behind a compiler, we are at the complete mercy of the compiler writers, and there was a lag of over a year before these were optimized for larger instructions and larger registers. Just shlepping large chunks of text around was still done in small 32bit chunks until the compilers caught up.
Anyway, there is a discussion of this here: http://en.wikipedia.org/wiki/64-bit_computing#32-bit_vs_64-bit
As far as the integer vs pointer war goes, there's still the one about whether to use a pointer that auto-increments into an array or a computed index address into the array. -- "You may have to fight a battle more than once to win it." -- Margaret Thatcher -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
there's still the one about whether to use a pointer that auto-increments into an array or a computed index address into the array. Τhat reminds me of the auto increment and auto decrement memory locations in the Data General computers. If you made an indirect access
Anton Aylward wrote: through one of those, the contents would increment or decrement, ready for the next access to the next location. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
John Andersen wrote:
But for the most of us, sitting behind a compiler, we are at the complete mercy of the compiler writers, and there was a lag of over a year before these were optimized for larger instructions and larger registers. Just shlepping large chunks of text around was still done in small 32bit chunks until the compilers caught up.
But that's an issue with the compiler, not the instruction set. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
James Knott said the following on 07/23/2013 10:07 AM:
Take a look at file sizes in 32 & 64 bit systems. You'll likely find the sizes are similar.
Nice theory. I did that for UNIX on the PDP-11 and the Vax shortly after the firm I was working at acquired a 780. I saw a 10% to 30% "bloat". Yes, as John says, some of this is due to compilers, and a lot is dies to the idea that C has - or had - of integers being interchangeable with pointers and calculating addresses. Yes, now we have compilers that are smarter, and also programmers that are, sometimes, smart enough to specify 'short int' and 'long int'. But not everyone is that smart. Or anal. -- All governments are more or less combinations against the people. . .and as rulers have no more virtue than the ruled. . . the power of government can only be kept within its constituted bounds by the display of a power equal to itself, the collected sentiment of the people. -- Benjamin Franklin Bache, in a Phildelphia Aurora editorial 1794 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
El 23/07/13 08:05, Felix Miata escribió: I found quite a bit of mention
of 64 bit apps using twice as much RAM? Is this true?
It uses 64 bit pointers which require twice as much space, so yeah it is likely that some programs will use a lot more ram. There is something called "x32 abi" , which is an x86_64 implementation with 32 bit pointers, so far, no distribution has been released officially using this ABI model. AFAIK we have no plans to release such distribution port either, things might change in the future though. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Content-ID: <alpine.LNX.2.00.1307232026060.5519@minas-tirith.valinor> El 2013-07-23 a las 12:08 -0400, Cristian Rodríguez escribió:
It uses 64 bit pointers which require twice as much space, so yeah it is likely that some programs will use a lot more ram.
I forgot pointers. Doesn't code use short or relative pointers?
There is something called "x32 abi" , which is an x86_64 implementation with 32 bit pointers, so far, no distribution has been released officially using this ABI model.
I don't know in Linux, but in MsDos you could choose the model of your code, and there were several possibilities of code size, data size, etc. Pointers could be absolute or relative. The segment register could be fixed and play with normal registers only (in theory the system could move the running code somewhere else in memory, adjust the segment registers, and let the app continue running happily). So, this "x32 abi" has to be applied to the entire system? - -- Cheers Carlos E. R. (from 11.4, with Evergreen, x86_64 "Celadon" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iF4EAREIAAYFAlHuyswACgkQja8UbcUWM1xJPAEAisE18hgWf2w3XBfje7WB4Pd2 nKAYUmpugxlhS4AZg6kA/AxQzVVrhX1ggQMH6/DRQ8HS3Ke0znU7RadQsCmLDZma =XjZR -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Content-ID: <alpine.LNX.2.00.1307232026060.5519@minas-tirith.valinor>
El 2013-07-23 a las 12:08 -0400, Cristian Rodríguez escribió:
It uses 64 bit pointers which require twice as much space, so yeah it is likely that some programs will use a lot more ram.
I forgot pointers.
Doesn't code use short or relative pointers?
No, not compiler generated code.
There is something called "x32 abi" , which is an x86_64 implementation with 32 bit pointers, so far, no distribution has been released officially using this ABI model.
I don't know in Linux, but in MsDos you could choose the model of your code,
Linux uses the flat memory model: http://en.wikipedia.org/wiki/Flat_memory_model
and there were several possibilities of code size, data size, etc. Pointers could be absolute or relative. The segment register could be fixed and play with normal registers only (in theory the
DOS ran in real mode, Linux runs in protected mode. In protected mode, you have access to the full 32bit address space, and the segment registers are more or less disabled, except FS and GS. -- Per Jessen, Zürich (24.2°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2013-07-31 at 14:29 +0200, Per Jessen wrote:
Carlos E. R. wrote:
Doesn't code use short or relative pointers?
No, not compiler generated code.
Curious. But is possible to use them, in assembler? Then it would be just the choice of compiler design.
I don't know in Linux, but in MsDos you could choose the model of your code,
Linux uses the flat memory model:
Interesting. I have not done development in Linux, so I lost track of this. So it is not possible to choose the model per application.
and there were several possibilities of code size, data size, etc. Pointers could be absolute or relative. The segment register could be fixed and play with normal registers only (in theory the
DOS ran in real mode, Linux runs in protected mode. In protected mode, you have access to the full 32bit address space, and the segment registers are more or less disabled, except FS and GS.
32 bit, not 64 bit? :-? I learned assembler with the 68000, the segment registers of the 8086 was something that I only used briefly. - -- Cheers, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iEYEARECAAYFAlH6OUMACgkQtTMYHG2NR9VRPQCeMXbfvsTHmxg9pQ9F2bAkY4iG vnwAniEuTDZO6ejh/FjVLSOQn0iBWDYy =4n0N -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Wednesday, 2013-07-31 at 14:29 +0200, Per Jessen wrote:
Carlos E. R. wrote:
Doesn't code use short or relative pointers?
No, not compiler generated code.
Curious. But is possible to use them, in assembler? Then it would be just the choice of compiler design.
Well, you can't use segmented addressing, but you could certainly write code to use relative pointers.
I don't know in Linux, but in MsDos you could choose the model of your code,
Linux uses the flat memory model:
Interesting. I have not done development in Linux, so I lost track of this. So it is not possible to choose the model per application.
Not possible and not needed either.
and there were several possibilities of code size, data size, etc. Pointers could be absolute or relative. The segment register could be fixed and play with normal registers only (in theory the
DOS ran in real mode, Linux runs in protected mode. In protected mode, you have access to the full 32bit address space, and the segment registers are more or less disabled, except FS and GS.
32 bit, not 64 bit? :-?
Yeah, both of course. -- Per Jessen, Zürich (24.7°C) http://www.dns24.ch/ - free DNS hosting, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hello, On Tue, 23 Jul 2013, Felix Miata wrote:
In googling the possibility of using a 64 bit kernel on an otherwise 32 bit openSUSE (consensus: don't try it), I found quite a bit of mention of 64 bit apps using twice as much RAM? Is this true?
No. Pointers take twice as much. But see below.
Or is it just misunderstanding arising from 64 bit using twice as many CPU registers to increase its own speed?
On the contrary. Having more registers makes the program possibly running faster. Completely independent from memory usage.
Or something else? My main system running 32 bit 11.4 has 4GB RAM and is consistently using >50% of RAM for open apps, most of the rest for disk cache, and always around 360MB unused. Would running 64 bit on this system be consuming virtually all RAM for apps, leaving little free for disk cache?
Nope. I used to run my usual stuff with 32bit, for years now with 64bit, and memory usage increased by maybe 10-20%.
FWIW, not all RAM is "cheap". To bring this DDR2 system up to its 8GB max would cost ~$63USD. To replace its 2X2GB sticks with 2X4GB (to free them for RAM upgrade to another system) would cost triple that.
Actually, since a while it's _quite_ simple: if your CPU is 64bit, use 64bit Kernels! You can _still_ run 32bit stuff if you install the -32bit libraries that are needed. E.g. wine is actually just a package that requires wine-32bit which requires the -32bit glibc, the libs for X etc. You can also use i586 packages though they may conflict with x86_64 packages. A nice summary and a possible solution for you is described here: http://en.wikipedia.org/wiki/X32_ABI "the benefits of x86-64 (larger number of CPU registers, better floating-point performance, faster position-independent code shared libraries, function parameters passed via registers, faster Syscall instruction... )" Generally, x86_64 is as fast to significantly faster than i[356]86, with only a slight memory overhead. And you can cut that down with the x32-ABI. Though I do not know of any package in oS that uses that yet. -dnh -- Only wimps use tape backup: _real_ men just upload their important stuff on ftp, and let the rest of the world mirror it ;) -- Linus Torvalds -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David Haller said the following on 07/24/2013 11:05 PM:
Or is it just misunderstanding arising from 64 bit using twice as many CPU registers to increase its own speed? On the contrary. Having more registers makes the program possibly running faster. Completely independent from memory usage.
This is completely dependent on the compiler and huge if-but-maybe situation. It is also the basis of a conceptual architectural battle. The advent of cheap silicon-on-a-single-chip had led us more and more down the path of multi-register machines, caching, integrated FPU and even integrated GPU. But the FORTH model shows of effective and efficient a single-register (plus address pointer plus call/return stack pointer plus parameter stack pointer) can be. Even with multi-register machines compilers have to be damn smart to make use of them all after a point. Oh, they are great when you are evaluating complex expressions, but the moment you make a subroutine call you have to start with a clear context, which means dumping registers and then restoring them on return .... or the equivalent. And when you make a system call or process switch there is a lot more context to save. Its not as simple as it sounds at first. The old SBP9900 had a model of 'register frames' in memory. It was a 16-bit machine with 16 registers, but they were in memory (slow, yes I know) and a subroutine call just mean changing the frame pointer, which meant dumping and restoring the register ban was incredibly fast. There was a later 'RISC' machine whose designation I don't recall, which did the same thing but traded the complex instruction set for on-chip memory. But then the RISC vs CISC argument is another thing altogether. Yes another thing that matter is register equivalence. Back in the 1980s, the Z-8000 and the M68000 both had a 16 registers, but the former had them all equivalent, any could be used for either computation or as an address pointer. The latter had separate computation and address registers. The computation registers could not be used as address pointers, After calculation the value had to be transferred to the addresses register. This complicated the register dump/restore algorithm no end. By contrast, the National Semiconductor 320xx family was 'compiler friendly'. http://en.wikipedia.org/wiki/NS320xx Its not that the Zilog Z-8000 wasn't, but the NS320xx constrained the compiler writer with the frame pointer etc where the Z-8000, following the PDP-11 and /360 model deferred this issue. Very often hardware designer seem to be working in a different universe from software people and vice versa. At times, compiler writing is a black art. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 7/25/2013 4:41 AM, Anton Aylward wrote:
David Haller said the following on 07/24/2013 11:05 PM:
Or is it just misunderstanding arising from 64 bit using twice as many CPU registers to increase its own speed? On the contrary. Having more registers makes the program possibly running faster. Completely independent from memory usage.
This is completely dependent on the compiler and huge if-but-maybe situation.
Much as you seem to enjoy it, your trips down memory lane in response to every post are not at all helpful or on-point. Yes of course it depends on the compiler, but So What? Compilers are optimized for architectures. Have been since the late Pleistocene. First versions of the compiler for new architectures are sub-optimum, just enough to make it work, but because compilers are pretty much table driven these days, subsequent releases are able to wring out the best performance the particular chipset can deliver. -- _____________________________________ ---This space for rent--- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 7/25/2013 2:44 PM, John Andersen wrote:
On 7/25/2013 4:41 AM, Anton Aylward wrote:
David Haller said the following on 07/24/2013 11:05 PM:
Or is it just misunderstanding arising from 64 bit using twice as many CPU registers to increase its own speed? On the contrary. Having more registers makes the program possibly running faster. Completely independent from memory usage.
This is completely dependent on the compiler and huge if-but-maybe situation.
Much as you seem to enjoy it, your trips down memory lane in response to every post are not at all helpful or on-point.
Yes of course it depends on the compiler, but So What? Compilers are optimized for architectures. Have been since the late Pleistocene.
First versions of the compiler for new architectures are sub-optimum, just enough to make it work, but because compilers are pretty much table driven these days, subsequent releases are able to wring out the best performance the particular chipset can deliver.
I enjoy, and got more value out of, his posts more than this one. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (14)
-
Andrey Borzenkov -
Anton Aylward -
Brian K. White -
Carl Hartung -
Carlos E. R. -
Cristian Rodríguez -
David Haller -
Felix Miata -
Greg Freemyer -
Hans Witvliet -
James Knott -
John Andersen -
Per Jessen -
Werner Flamme