[opensuse] 64 bit vrs 32 bit advantages speed etc.

newer
[opensuse] 10.3 amd64 firefox/java

Robert Lewis

30 Oct 2007 30 Oct '07

15:11

I recently bought a 64 bit machine and have 10.3 loaded . It seems very fast. I am trying to appraise if the advantages of having some software not work because of driver issues is worth it. Has anyone run benchmarks on an identical system with 32 bit vrs 64 bit? Do we have a list of software that is known not to work on 64-bit? Any defined group tracking this and championing gettin the remainder fixed. I know this is a generalized question but I am just trying to appraise the gain vrs pain of deciding to stay with 64-bit ? Cheers, Bob -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Show replies by date

BandiPat

30 Oct 30 Oct

15:36

On Tuesday 30 October 2007, Robert Lewis wrote:

...

I recently bought a 64 bit machine and have 10.3 loaded . It seems very fast.

I am trying to appraise if the advantages of having some software not work because of driver issues is worth it.

Has anyone run benchmarks on an identical system with 32 bit vrs 64 bit?

Do we have a list of software that is known not to work on 64-bit? Any defined group tracking this and championing gettin the remainder fixed.

I know this is a generalized question but I am just trying to appraise the gain vrs pain of deciding to stay with 64-bit ?

Cheers, Bob

============ Bob, Maybe you could load a second 32bit install to test the differences you see on your system. What you are asking is a question many of us that haven't yet moved to 64bit systems are interested in. From the many emails here and elsewhere, I've come to the conclusion it's just better to use 32bit for the moment. It bothers me that so much software, drivers & plugins are still only 32 when 64 has been out so long. Why are these things taking so long to convert or why are they being so slow about building 64 bit apps? Moving to full 64bit should indeed be a better choice, you would think, yet many of apps & plugins are still 32bit only. It's a vexing question, but for now I'm staying with 32bit. regards, Lee -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Patrick Shanahan

15:58

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 * BandiPat [10-30-07 11:54]: [...]

...

Moving to full 64bit should indeed be a better choice, you would think, yet many of apps & plugins are still 32bit only.

I believe that this is fluff and not fact. There are a few apps which only have 32bit plug-ins for certain capabilities, ie: I still run 32bit firefox and plug-ins and 32bit java. But *everything* else on my 10.1 system *is* 64bit.

...

It's a vexing question, but for now I'm staying with 32bit.

Your choice! BUT it is not based on your experience, only perception. - -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn4472 (GNU/Linux) iD8DBQFHJ1S9ClSjbQz1U5oRAqxIAJ9e5nNCkarMOKNPgs6x6h7NG7FZvACgsEBW muMczUw3vgbLd51cNwCTCY8= =mDTU -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Robert Lewis

16:26

On 10/30/07, Patrick Shanahan wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

* BandiPat [10-30-07 11:54]: [...]

...
Moving to full 64bit should indeed be a better choice, you would think, yet many of apps & plugins are still 32bit only.

I believe that this is fluff and not fact. There are a few apps which only have 32bit plug-ins for certain capabilities, ie: I still run 32bit firefox and plug-ins and 32bit java. But *everything* else on my 10.1 system *is* 64bit.

...
It's a vexing question, but for now I'm staying with 32bit.

Your choice! BUT it is not based on your experience, only perception.

- -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn4472 (GNU/Linux)

What I would really like to see is a 64-bit user group that quantifies exactly what doesn't work and uses that list to communicate with developers to encourage them to produce a functioning 64-bit whatever. Right now, I don't have solid information to make an informed decision. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Randall R Schulz

16:26

On Tuesday 30 October 2007 08:58, Patrick Shanahan wrote:

...

* BandiPat [10-30-07 11:54]: [...]

...
Moving to full 64bit should indeed be a better choice, you would think, yet many of apps & plugins are still 32bit only.

I believe that this is fluff and not fact. There are a few apps which only have 32bit plug-ins for certain capabilities, ie: I still run 32bit firefox and plug-ins and 32bit java. But *everything* else on my 10.1 system *is* 64bit.

But why? Do you run applications that need a 64-bit address space? If not, it's only more execution overhead to move nearly twice as much data around to get any given task done. The fact that the main system busses are 64-bits wide does not negate this overhead. Almost everything a desktop computer does is RAM-limited (this is even true for most CPU-intensive applications), so using a lot less RAM really does help.

...

...

-- Patrick Shanahan

Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Russell Jones

16:42

Randall R Schulz wrote:

...

On Tuesday 30 October 2007 08:58, Patrick Shanahan wrote:

...
* BandiPat [10-30-07 11:54]: [...]

...
Moving to full 64bit should indeed be a better choice, you would think, yet many of apps & plugins are still 32bit only.

I believe that this is fluff and not fact. There are a few apps which only have 32bit plug-ins for certain capabilities, ie: I still run 32bit firefox and plug-ins and 32bit java. But *everything* else on my 10.1 system *is* 64bit.

But why? Do you run applications that need a 64-bit address space? If not, it's only more execution overhead to move nearly twice as much data around to get any given task done. The fact that the main system busses are 64-bits wide does not negate this overhead. Almost everything a desktop computer does is RAM-limited (this is even true for most CPU-intensive applications), so using a lot less RAM really does help.

64-bit machines don't use much more RAM. I asked Novell about this, and they suggested that the 64-bit version of SLES 10 only uses about 1% more RAM. There is a difference, but it's not that big. Do you run 64-bit, Randall? I do at home, and I don't really have any memory problems (except with a certain Java application, but I think that's a bug). Also, if you're planning to go over 2Gb, it's the way to go, AFAICS. Things start to get kludgey in the OS above that limit with 32-bit, and it can't help performance.

...

...
...

-- Patrick Shanahan

Randall Schulz

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Randall R Schulz

17:20

On Tuesday 30 October 2007 09:42, Russell Jones wrote:

...

Randall R Schulz wrote:

...
On Tuesday 30 October 2007 08:58, Patrick Shanahan wrote:

...
* BandiPat [10-30-07 11:54]: [...]

...
Moving to full 64bit should indeed be a better choice, you would think, yet many of apps & plugins are still 32bit only.

I believe that this is fluff and not fact. There are a few apps which only have 32bit plug-ins for certain capabilities, ie: I still run 32bit firefox and plug-ins and 32bit java. But *everything* else on my 10.1 system *is* 64bit.

But why? Do you run applications that need a 64-bit address space? If not, it's only more execution overhead to move nearly twice as much data around to get any given task done. The fact that the main system busses are 64-bits wide does not negate this overhead. Almost everything a desktop computer does is RAM-limited (this is even true for most CPU-intensive applications), so using a lot less RAM really does help.

64-bit machines don't use much more RAM.

This is not primarily about RAM required, but about the volume of data that must be moved between the CPU and main store to get any given computational task done. 64-bit code uses 64-bit pointers and 64-bit integers, and for any given hardware configuration, moving twice as much data takes twice as long. A program that uses data items of a specific size (8-bit, 32-bit, 64-bit, etc.) and accesses them randomly (i.e., with no benefit of locality owing to caches) will see no difference. Any program that accesses native sizes (pointers and integers, basically) and does so sequentially and with a relatively small amount of processing within the CPU per item transferred will exhibit nearly a twofold reduction in sustained processing when switching to a 64-bit ISA. This is because the performance advantage gained by caches when accessing sequential addresses is halved by using data items of twice the size. Keep in mind that the level-1 and level-2 caches are the primary reason we've seen such dramatic improvements in our systems' throughput. Otherwise, our spiffy fast processors would spend the vast majority of their time waiting to get or get rid of data (including executable instructions). Actual results depend on the exact mix of accesses and instructions, of course. But a 32-bit processor (any processor operating in 32-bit mode) installed in a system with 64-bit data paths will always have some advantage over the 64-bit processor in that system. Conversely (not that it really matters), a 64-bit processor in a system with 32-bit data paths would always operate at a disadvantage w.r.t. to the 32-bit processor. That's why there is no point in running in 64-bit mode unless you're running applications that need to or are significantly advantaged by operating in a 64-bit virtual address space. Which in turn is an advantage only if you have more then 4 GB of physical memory.

...

I asked Novell about this, and they suggested that the 64-bit version of SLES 10 only uses about 1% more RAM.

That sounds a little low to me.

...

There is a difference, but it's not that big. Do you run 64-bit, Randall? I do at home, and I don't really have any memory problems (except with a certain Java application, but I think that's a bug). Also, if you're planning to go over 2Gb, it's the way to go, AFAICS. Things start to get kludgey in the OS above that limit with 32-bit, and it can't help performance.

I use 32-bit 10.3 on a Core 2 Duo system that (until I suffered a failure on one DIMM couple of weeks ago) had 4 GB of RAM installed. The BIOS has an option to map the I/O space out of the first four GB, so the full 4GB of RAM can be accessed, as long as the OS knows how to use PAE, which Linux certainly does. Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Jan Engelhardt

17:47

New subject: [opensuse] 64 bit vs 32 bit advantages speed etc.

On Oct 30 2007 10:20, Randall R Schulz wrote:

...

On Tuesday 30 October 2007 09:42, Russell Jones wrote:

...
Randall R Schulz wrote:

...
On Tuesday 30 October 2007 08:58, Patrick Shanahan wrote:

...
* BandiPat [10-30-07 11:54]: [...]

But why? Do you run applications that need a 64-bit address space?

Even if you use a "36-bit" PAE kernel, it can only give a process a 32-bit address space. You want at least a 64-bit kernel. Everyone does that on SUN processors even though 64 bitisms are more expensive there.

...

...
...
If not, it's only more execution overhead to move nearly twice as much data around to get any given task done. The fact that the main system busses are 64-bits wide does not negate this overhead. [...]

64-bit machines don't use much more RAM.

This is not primarily about RAM required, but about the volume of data that must be moved between the CPU and main store to get any given computational task done. 64-bit code uses 64-bit pointers and 64-bit integers, and for any given hardware configuration, moving twice as much data takes twice as long.

AMD64 is *NOT* the same as SPARC64. If it were, it would not sell. For yer commodity x64-bit processor: 64 bits are moved between registers as fast as 32, 16 or 8 bits are. For yer commodity x86/32-bit processor: 32 bits are moved between registers as fast as 16 or 8 bits are. While the volume does not really change in register transfers, neither does the speed. And programs that actually move data between the CPU and memory do not automatically have to transfer more data (that is, if you were not drunk while writing the program). Have a cookie: char big[1048576]; /* 1 MB */ memset(big, 0, sizeof(big)); What's faster - 256K 32-bit writes or 128K 64-bit writes? (Hint: the latter because you need to do half the number of loops.) Your "volume" argument is - except for the drunk case mentioned above - totally moot.

...

Any program that accesses native sizes (pointers and integers, basically) and does so sequentially and with a relatively small amount of processing within the CPU per item transferred will exhibit nearly a twofold reduction in sustained processing when switching to a 64-bit ISA. [...] That's why there is no point in running in 64-bit mode unless you're running applications that need to or are significantly advantaged by operating in a 64-bit virtual address space. Which in turn is an advantage only if you have more then 4 GB of physical memory.

Obviously you had never had a look at the AMD64 instruction set. It features new addressing modes such as RIP-relative, where pointers are usually 16 to 80 bits only. Another cookie: int p = 0; int *x = &p; int main(void) { *p = 1337; } yields (for both 64-bit and 64-bit PIC): 400510: 48 8b 05 11 0b 20 00 mov 2099985(%rip),%rax 7 bytes for what most people would think could have been a 10 byte insn. Even more interestingly, the same piece of code gets translated into 11 bytes in 32-bit, or even *13* bytes in 32-bit PIC mode (which is what most shared libraries and new programs use). 80483d1: a1 18 a0 04 08 mov 0x804a018,%eax 80483d6: c7 00 39 05 00 00 movl $0x539,(%eax) PIC: 8048401: 8b 83 fc ff ff ff mov 0xfffffffc(%ebx),%eax 8048407: 8b 00 mov (%eax),%eax 8048409: c7 00 39 05 00 00 movl $0x539,(%eax) Thanks for taking the time to think about it! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Igor Jagec

31 Oct 31 Oct

10:45

New subject: [opensuse] 64 bit vs 32 bit advantages speed etc.

On Tue, 2007-10-30 at 18:47 +0100, Jan Engelhardt wrote:

...

Even if you use a "36-bit" PAE kernel, it can only give a process a 32-bit address space. You want at least a 64-bit kernel. Everyone does that on SUN processors even though 64 bitisms are more expensive there.

You suggest that it would be a good idea to use 64-bit kernel and all other stuff on 32-bit? Thanks! -- Igor Jagec

Anders Johansson

11:14

New subject: [opensuse] 64 bit vs 32 bit advantages speed etc.

On Tuesday 30 October 2007 18:47:28 Jan Engelhardt wrote:

...

On Oct 30 2007 10:20, Randall R Schulz wrote:

...
On Tuesday 30 October 2007 09:42, Russell Jones wrote:

...
Randall R Schulz wrote:

...
On Tuesday 30 October 2007 08:58, Patrick Shanahan wrote:

...
* BandiPat [10-30-07 11:54]: [...]

But why? Do you run applications that need a 64-bit address space?

Even if you use a "36-bit" PAE kernel, it can only give a process a 32-bit address space. You want at least a 64-bit kernel. Everyone does that on SUN processors even though 64 bitisms are more expensive there.

...
...
...
If not, it's only more execution overhead to move nearly twice as much data around to get any given task done. The fact that the main system busses are 64-bits wide does not negate this overhead. [...]

64-bit machines don't use much more RAM.

This is not primarily about RAM required, but about the volume of data that must be moved between the CPU and main store to get any given computational task done. 64-bit code uses 64-bit pointers and 64-bit integers, and for any given hardware configuration, moving twice as much data takes twice as long.

AMD64 is *NOT* the same as SPARC64. If it were, it would not sell.

For yer commodity x64-bit processor: 64 bits are moved between registers as fast as 32, 16 or 8 bits are. For yer commodity x86/32-bit processor: 32 bits are moved between registers as fast as 16 or 8 bits are.

While the volume does not really change in register transfers, neither does the speed.

And programs that actually move data between the CPU and memory do not automatically have to transfer more data (that is, if you were not drunk while writing the program).

Have a cookie:

char big[1048576]; /* 1 MB */ memset(big, 0, sizeof(big));

What's faster - 256K 32-bit writes or 128K 64-bit writes? (Hint: the latter because you need to do half the number of loops.)

Your "volume" argument is - except for the drunk case mentioned above - totally moot.

...
Any program that accesses native sizes (pointers and integers, basically) and does so sequentially and with a relatively small amount of processing within the CPU per item transferred will exhibit nearly a twofold reduction in sustained processing when switching to a 64-bit ISA. [...] That's why there is no point in running in 64-bit mode unless you're running applications that need to or are significantly advantaged by operating in a 64-bit virtual address space. Which in turn is an advantage only if you have more then 4 GB of physical memory.

Obviously you had never had a look at the AMD64 instruction set. It features new addressing modes such as RIP-relative, where pointers are usually 16 to 80 bits only.

Another cookie:

int p = 0; int *x = &p;

int main(void) { *p = 1337;

Program was aborted with signal 11. 0 = 1337 is not good programming :) Did you mean *x = 1337; In either case, I wouldn't expect "1337" to be compiled into a memory lookup. That seems a bit inefficient. -- Madness takes its toll -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Anders Johansson

11:45

New subject: [opensuse] 64 bit vs 32 bit advantages speed etc.

On Tuesday 30 October 2007 18:47:28 Jan Engelhardt wrote:

...

Another cookie:

int p = 0; int *x = &p;

int main(void) { *p = 1337; }

yields (for both 64-bit and 64-bit PIC):

400510: 48 8b 05 11 0b 20 00 mov 2099985(%rip),%rax

I try to avoid Intel assembly as much as possible, so I had to think about this. But as I suspected, this is just "int *x = &p". Since in your other examples you include the assignment of 1337, you need to add movl $0x539,(rax) to this as well. As far as I can see, that makes it an additional 6 bytes, for a total of 13. Anders -- Madness takes its toll -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

BandiPat

30 Oct 30 Oct

19:52

On Tuesday 30 October 2007, Patrick Shanahan wrote:

...

* BandiPat [10-30-07 11:54]: [...]

...
Moving to full 64bit should indeed be a better choice, you would think, yet many of apps & plugins are still 32bit only.

I believe that this is fluff and not fact. There are a few apps which only have 32bit plug-ins for certain capabilities, ie: I still run 32bit firefox and plug-ins and 32bit java. But *everything* else on my 10.1 system *is* 64bit.

...
It's a vexing question, but for now I'm staying with 32bit.

Your choice! BUT it is not based on your experience, only perception.

-- Patrick Shanahan

True, Patrick, my thoughts are not due to actual experience with 64 bit hardware, but certainly it seems that most tests and articles to be found confirm no big improvement by using 64 bit presently. Certainly there are some things/apps that will benefit, but for those people that use them, they don't care about the rest. For those people that use the whole system for different things like most users, there is no added benefit. As both Randall & Buddy have pointed out, plus others here, the speed differences are negligible. Until the industry decides to move to 64 bit or Microsoft let's them, we're going to be stuck in a 32bit or less world. There's a fact for you! :-p regards, Lee -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Patrick Shanahan

21:24

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 * BandiPat [10-30-07 16:06]:

...

True, Patrick, my thoughts are not due to actual experience with 64 bit hardware, but certainly it seems that most tests and articles to be found confirm no big improvement by using 64 bit presently.

Then you won't be using openSUSE and more???? As there are articles deriding Novell's contract w/m$ and lots of fluff about 10.3 being a #.0 version rather than an update/upgrade from 10.2/10.1.... And on and on and on.....

...

Certainly there are some things/apps that will benefit, but for those people that use them, they don't care about the rest.

I care and I use x86_64, that is what my system is, not i586. It is i586 compatable.

...

For those people that use the whole system for different things like most users, there is no added benefit.

so no one who uses x86_64 uses the "whole" system for ?different? things?

...

As both Randall & Buddy have pointed out, plus others here, the speed differences are negligible.

again, perception, not fact as Jan has noted.

...

Until the industry decides to move to 64 bit or Microsoft let's them, we're going to be stuck in a 32bit or less world. There's a fact for you! :-p

better look again. ONLY low end hardware is now i586/i686, most is 64bit and dual/4 core. seems that being glued to 32bit apps on a 64bit system a bit like wanting to stay with a straight stick transmission because nobody will use an automatic, and there is no benefit. ps. this argument is agrument for the sake of argument and accomplishes nothing. You will stick with 32bit because you "have read" that "some people" have had problems with 64bit and others have opinioned that there is "no benefit". But no FACTs have been displayed. If you will recall, every new version from SuSE/openSUSE has met with the same small section of vocality denouncing the new version as not as good or a regression and they cannot make it work, the previous ten versions all worked better and were less trouble to install........ - -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn4472 (GNU/Linux) iD8DBQFHJ6EcClSjbQz1U5oRAv8qAJ9pZMMRCl7uVl51p+nH2Sz40llPvwCgofAB DB3sPu97VGh0Mb3ZaFApY18= =3j3N -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Randall R Schulz

21:49

On Tuesday 30 October 2007 14:24, Patrick Shanahan wrote:

...

...

again, perception, not fact as Jan has noted.

Jan's points have little to do with mine. Move twice as much data to perform a given task with the same bus and memory hardware will take twice as long. My points had nothing whatsoever to do with "perception." They are an accurate and valid analysis of 32-bit vs. 64-bit data (and pointer) architecture disparities.

...

...

-- Patrick Shanahan

Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Patrick Shanahan

22:02

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 * Randall R Schulz [10-30-07 17:51]:

...

Jan's points have little to do with mine. Move twice as much data to perform a given task with the same bus and memory hardware will take twice as long.

but it's not the same bus

...

My points had nothing whatsoever to do with "perception." They are an accurate and valid analysis of 32-bit vs. 64-bit data (and pointer) architecture disparities.

- -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn4472 (GNU/Linux) iD8DBQFHJ6oRClSjbQz1U5oRArDSAJwNNaTqKjJ7vASknx0NbBL1tSdzsQCgl/qp hs7z0KnrzS0WPwZ1ew1Y/H4= =SLO+ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Randall R Schulz

22:09

On Tuesday 30 October 2007 15:02, Patrick Shanahan wrote:

...

* Randall R Schulz [10-30-07 17:51]:

...
Jan's points have little to do with mine. Move twice as much data to perform a given task with the same bus and memory hardware will take twice as long.

but it's not the same bus

Eh? We're talking about whether to run a 32-bit or a 64-bit OS (and applications) on a given system. There's only one bus. Even when running in 32-bit mode, the same cache, FSB and RAM data paths are active and they're still all 64 bits wide.

...

...

-- Patrick Shanahan

Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Jan Engelhardt

22:29

On Oct 30 2007 15:09, Randall R Schulz wrote:

...

On Tuesday 30 October 2007 15:02, Patrick Shanahan wrote:

...
* Randall R Schulz [10-30-07 17:51]:

...
Jan's points have little to do with mine. Move twice as much data to perform a given task with the same bus and memory hardware will take twice as long.

but it's not the same bus

Eh? We're talking about whether to run a 32-bit or a 64-bit OS (and applications) on a given system. There's only one bus.

In your Intel perhaps. On AMD, you've got extra HyperTransport links. ( http://lwn.net/Articles/254445/ )

...

Even when running in 32-bit mode, the same cache, FSB and RAM data paths are active and they're still all 64 bits wide. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Aaron Kulkis

23:18

Randall R Schulz wrote:

...

On Tuesday 30 October 2007 14:24, Patrick Shanahan wrote:

...
...

again, perception, not fact as Jan has noted.

Jan's points have little to do with mine. Move twice as much data to perform a given task with the same bus and memory hardware will take twice as long.

My points had nothing whatsoever to do with "perception." They are an accurate and valid analysis of 32-bit vs. 64-bit data (and pointer) architecture disparities.

Especially since currently, memory modules are still only 32 bits wide...motherboard manufacturers are at liberty to make the external data bus either 32 bits or 64 bits wide. If your motherboard allows you to A) To install pairs of memory modules, of differing size, (say 512 MB and 1 GB) and to use ALL of the memory (1.5 GB instead of only 1 GB) or B) install odd numbers (1, 3, 5...) of memory modules, then your IA-64 or AMD-64motherboard's data bus is only 32 bits wide, killing most of the speed advantage of a 64-bit processor, and really only giving you the benefit of an address space beyond 32 bits. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

James Knott

31 Oct 31 Oct

11:15

Aaron Kulkis wrote:

...

Especially since currently, memory modules are still only 32 bits wide...motherboard manufacturers are at liberty to make the external data bus either 32 bits or 64 bits wide.

??? I thought memory was 64 bits wide these days. http://en.wikipedia.org/wiki/DDR_SDRAM

...

If your motherboard allows you to

A) To install pairs of memory modules, of differing size, (say 512 MB and 1 GB) and to use ALL of the memory (1.5 GB instead of only 1 GB)

or

B) install odd numbers (1, 3, 5...) of memory modules,

then your IA-64 or AMD-64motherboard's data bus is only 32 bits wide, killing most of the speed advantage of a 64-bit processor, and really only giving you the benefit of an address space beyond 32 bits.

Ever hear of interleaving memory? It allows more efficient use of the memory bus by starting a transfer on one memory module, while the other is completing the previous. http://en.wikipedia.org/wiki/Interleaved_memory Incidentally, I was working with interleaved memory back in the late '70s, before the IBM PC was even created. Back in those days, I was a computer technician, maintaining several mini-computers. Those computers used interleaved core memory. -- Use OpenOffice.org http://www.openoffice.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

BandiPat

02:39

On Tuesday 30 October 2007, Patrick Shanahan wrote:

...

* BandiPat [10-30-07 16:06]:

...
True, Patrick, my thoughts are not due to actual experience with 64 bit hardware, but certainly it seems that most tests and articles to be found confirm no big improvement by using 64 bit presently.

Then you won't be using openSUSE and more???? As there are articles deriding Novell's contract w/m$ and lots of fluff about 10.3 being a #.0 version rather than an update/upgrade from 10.2/10.1.... And on and on and on..... /////////// Huh?

...

...
Certainly there are some things/apps that will benefit, but for those people that use them, they don't care about the rest.

I care and I use x86_64, that is what my system is, not i586. It is i586 compatable.

...
For those people that use the whole system for different things like most users, there is no added benefit.

so no one who uses x86_64 uses the "whole" system for ?different? things?

...
As both Randall & Buddy have pointed out, plus others here, the speed differences are negligible.

again, perception, not fact as Jan has noted.

...
Until the industry decides to move to 64 bit or Microsoft let's them, we're going to be stuck in a 32bit or less world. There's a fact for you! :-p

better look again. ONLY low end hardware is now i586/i686, most is 64bit and dual/4 core.

seems that being glued to 32bit apps on a 64bit system a bit like wanting to stay with a straight stick transmission because nobody will use an automatic, and there is no benefit.

ps. this argument is agrument for the sake of argument and accomplishes nothing. You will stick with 32bit because you "have read" that "some people" have had problems with 64bit and others have opinioned that there is "no benefit". But no FACTs have been displayed.

If you will recall, every new version from SuSE/openSUSE has met with the same small section of vocality denouncing the new version as not as good or a regression and they cannot make it work, the previous ten versions all worked better and were less trouble to install........

-- Patrick Shanahan

Hey Patrick, what's with the attitude? You act like somebody pissed on your rusty old Harley, when all it was intended to be was just a discussion! If you feel the need to gloat to others that you have a 64bit system with a 64bit OS, more power to you dude, but that still doesn't take away from all the problems still existing for 64bit. It's not perception when so many people complain or end up going back to a 32bit install due to all the hoops they have to jump through to get things working. So far, you haven't offered much in the way of facts either to support your arguments, just a lot of lip service trying to defend your reasons for using 64bit software on your 64bit hardware! By the way, your high end hardware was low end hardware two days after you put it together! Get a clue! Take a chill pill, calm down and just answer the OP's question, which is do you prefer one or the other. Obviously your vote goes to 64bit, no matter what problems you run into. Quite frankly, there are many reasons to use a stick shift to an automatic. But, I think that argument would be lost on you too, in your present state of mind. Anyway, Happy Halloween, Trick or Treat & watch for those flaming bags of crap on your door step tomorrow night! :-) regards, Lee -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Ness, Todd

30 Oct 30 Oct

15:40

On Tue, 2007-10-30 at 08:11 -0700, Robert Lewis wrote:

...

I recently bought a 64 bit machine and have 10.3 loaded . It seems very fast.

I am trying to appraise if the advantages of having some software not work because of driver issues is worth it.

Has anyone run benchmarks on an identical system with 32 bit vrs 64 bit?

Do we have a list of software that is known not to work on 64-bit? Any defined group tracking this and championing gettin the remainder fixed.

I know this is a generalized question but I am just trying to appraise the gain vrs pain of deciding to stay with 64-bit ?

Cheers, Bob The only big thing that did not work right for me in the 64 bit was the java plugin, there was an old 1.4.2 plugin that was compiled for 64 bit but webex meetings did not work. My vmware stuff seemed to be somewhat slower than it was under 10.2 32bit, I just changed to 32 bit today trying to see if evolution would behave better on 32bit, and so far I have not had restart evolution in 2.5 hours so, maybe this is better maybe not. It also seemed to me that 10.2 32 and 64 bit, was faster than 10.3 64 overall, 32 bit 10.3 seems to be behaving thus far.

-- Todd Ness I

Aaron Kulkis

16:36

Robert Lewis wrote:

...

I recently bought a 64 bit machine and have 10.3 loaded . It seems very fast.

I am trying to appraise if the advantages of having some software not work because of driver issues is worth it.

Has anyone run benchmarks on an identical system with 32 bit vrs 64 bit?

Do we have a list of software that is known not to work on 64-bit? Any defined group tracking this and championing gettin the remainder fixed.

I know this is a generalized question but I am just trying to appraise the gain vrs pain of deciding to stay with 64-bit ?

Most data isn't 64-bit. In fact, a large chunk of it is still 16-bit, and even 8 bit (ASCII text, for example). Most of the speed increase you are seeing is from: 1) the faster clock speed of your new CPU compared to the last one you had. 2) wider data buses into and out of the on-chip cache. 3) floating point operations (where applicable). You won't see a significant difference between 32-bit and 64-bit system performance until you are running some software which uses lots of 64-bit integers, or is very intensive in floating-point operations.

...

Cheers, Bob

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Greg Freemyer

17:46

On 10/30/07, Aaron Kulkis wrote:

...

Robert Lewis wrote:

...
I recently bought a 64 bit machine and have 10.3 loaded . It seems very fast.

I am trying to appraise if the advantages of having some software not work because of driver issues is worth it.

Has anyone run benchmarks on an identical system with 32 bit vrs 64 bit?

Do we have a list of software that is known not to work on 64-bit? Any defined group tracking this and championing gettin the remainder fixed.

I know this is a generalized question but I am just trying to appraise the gain vrs pain of deciding to stay with 64-bit ?

Most data isn't 64-bit. In fact, a large chunk of it is still 16-bit, and even 8 bit (ASCII text, for example).

Most of the speed increase you are seeing is from:

1) the faster clock speed of your new CPU compared to the last one you had.

2) wider data buses into and out of the on-chip cache.

3) floating point operations (where applicable).

You won't see a significant difference between 32-bit and 64-bit system performance until you are running some software which uses lots of 64-bit integers, or is very intensive in floating-point operations.

Surprisingly (to me at least) we are seeing a speed improvement with a specialized version of dd (dcfldd) going against raw disks. ie. dcfldd if=/dev/sdb of=/dev/sdc bs=4k and dcfldd if=/dev/sdc of=/dev/null bs=4k Were still putting together a performance matrix, but we're planning to test: 32-bit kernel - 32-bit app 64-bit kernel - 32-bit app 64-bit kernel - 64-bit app So far we've tested the last 2 and are seeing about a 25% improvement by just recompiling dcfldd as a 64-bit app. I was not expecting that at all. Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Jan Engelhardt

17:49

On Oct 30 2007 13:46, Greg Freemyer wrote:

...

Surprisingly (to me at least) we are seeing a speed improvement with a specialized version of dd (dcfldd) going against raw disks.

ie. dcfldd if=/dev/sdb of=/dev/sdc bs=4k and dcfldd if=/dev/sdc of=/dev/null bs=4k

Bottleneck: Disk. You cannot really use something like dd or variants to benchmark your CPU. What you can do is comparing the encoding time of oggenc or so (but be sure to use the SSE2 mode in the 32-bit compilation mode before testing, because x64 uses SSE2 by default). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Greg Freemyer

20:36

On 10/30/07, Jan Engelhardt wrote:

...

On Oct 30 2007 13:46, Greg Freemyer wrote:

...
Surprisingly (to me at least) we are seeing a speed improvement with a specialized version of dd (dcfldd) going against raw disks.

ie. dcfldd if=/dev/sdb of=/dev/sdc bs=4k and dcfldd if=/dev/sdc of=/dev/null bs=4k

Bottleneck: Disk. You cannot really use something like dd or variants to benchmark your CPU. What you can do is comparing the encoding time of oggenc or so (but be sure to use the SSE2 mode in the 32-bit compilation mode before testing, because x64 uses SSE2 by default).

I fully expected the disk to be the only bottleneck. My surprise was that 32/64 bit compile issues had any impact at all. Let alone 25% faster with full 64-bit. FYI: I'm using dcfldd as my benchmark tool because it _is_ my workload!! Indeed we have 4 computers dedicated to running it with a few simple scripts automating the process. We are in the process of replacing the PCs and upgrading to 10.3 as our OS. (We call the process "Forensic Imaging".) Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Aaron Kulkis

18:19

Greg Freemyer wrote:

...

On 10/30/07, Aaron Kulkis wrote:

...
Robert Lewis wrote:

...
I recently bought a 64 bit machine and have 10.3 loaded . It seems very fast.

I am trying to appraise if the advantages of having some software not work because of driver issues is worth it.

Has anyone run benchmarks on an identical system with 32 bit vrs 64 bit?

Do we have a list of software that is known not to work on 64-bit? Any defined group tracking this and championing gettin the remainder fixed.

I know this is a generalized question but I am just trying to appraise the gain vrs pain of deciding to stay with 64-bit ? Most data isn't 64-bit. In fact, a large chunk of it is still 16-bit, and even 8 bit (ASCII text, for example).

Most of the speed increase you are seeing is from:

1) the faster clock speed of your new CPU compared to the last one you had.

2) wider data buses into and out of the on-chip cache.

3) floating point operations (where applicable).

You won't see a significant difference between 32-bit and 64-bit system performance until you are running some software which uses lots of 64-bit integers, or is very intensive in floating-point operations.

Surprisingly (to me at least) we are seeing a speed improvement with a specialized version of dd (dcfldd) going against raw disks.

Why is it surprising that dd (which just moves large chunks of data) would be improved by a movement from 4-byte natural word size to 8-byte natural word size? That's like being surprised that thicker pipes can move more gallons of water per hour.

...

ie. dcfldd if=/dev/sdb of=/dev/sdc bs=4k and dcfldd if=/dev/sdc of=/dev/null bs=4k

Were still putting together a performance matrix, but we're planning to test:

32-bit kernel - 32-bit app 64-bit kernel - 32-bit app 64-bit kernel - 64-bit app

So far we've tested the last 2 and are seeing about a 25% improvement by just recompiling dcfldd as a 64-bit app. I was not expecting that at all.

Greg

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Greg Freemyer

20:30

On 10/30/07, Aaron Kulkis wrote:

...

Greg Freemyer wrote:

...
On 10/30/07, Aaron Kulkis wrote:

...
Robert Lewis wrote:

...
I recently bought a 64 bit machine and have 10.3 loaded . It seems very fast.

I am trying to appraise if the advantages of having some software not work because of driver issues is worth it.

Has anyone run benchmarks on an identical system with 32 bit vrs 64 bit?

Do we have a list of software that is known not to work on 64-bit? Any defined group tracking this and championing gettin the remainder fixed.

I know this is a generalized question but I am just trying to appraise the gain vrs pain of deciding to stay with 64-bit ? Most data isn't 64-bit. In fact, a large chunk of it is still 16-bit, and even 8 bit (ASCII text, for example).

Most of the speed increase you are seeing is from:

1) the faster clock speed of your new CPU compared to the last one you had.

2) wider data buses into and out of the on-chip cache.

3) floating point operations (where applicable).

You won't see a significant difference between 32-bit and 64-bit system performance until you are running some software which uses lots of 64-bit integers, or is very intensive in floating-point operations.

Surprisingly (to me at least) we are seeing a speed improvement with a specialized version of dd (dcfldd) going against raw disks.

Why is it surprising that dd (which just moves large chunks of data) would be improved by a movement from 4-byte natural word size to 8-byte natural word size?

That's like being surprised that thicker pipes can move more gallons of water per hour.

Because everyone knows that the disk drive/SATA-bus/controller/PCI-bus/DMA are the limiting factors in raw dd speed, so who cares how the kernel/app are compiled. And my tests were with a PCI-bus controller. With a PCI-Express controller the 32-bit/64-bit issue for kernel/userland is likely even more important. Greg -- Greg Freemyer Litigation Triage Solutions Specialist http://www.linkedin.com/in/gregfreemyer The Norcross Group The Intersection of Evidence & Technology http://www.norcrossgroup.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Aaron Kulkis

20:46

Greg Freemyer wrote:

...

On 10/30/07, Aaron Kulkis wrote:

...
Greg Freemyer wrote:

...
On 10/30/07, Aaron Kulkis wrote:

...
Robert Lewis wrote:

...
I recently bought a 64 bit machine and have 10.3 loaded . It seems very fast.

I am trying to appraise if the advantages of having some software not work because of driver issues is worth it.

Has anyone run benchmarks on an identical system with 32 bit vrs 64 bit?

Do we have a list of software that is known not to work on 64-bit? Any defined group tracking this and championing gettin the remainder fixed.

I know this is a generalized question but I am just trying to appraise the gain vrs pain of deciding to stay with 64-bit ? Most data isn't 64-bit. In fact, a large chunk of it is still 16-bit, and even 8 bit (ASCII text, for example).

Most of the speed increase you are seeing is from:

1) the faster clock speed of your new CPU compared to the last one you had.

2) wider data buses into and out of the on-chip cache.

3) floating point operations (where applicable).

You won't see a significant difference between 32-bit and 64-bit system performance until you are running some software which uses lots of 64-bit integers, or is very intensive in floating-point operations.

Surprisingly (to me at least) we are seeing a speed improvement with a specialized version of dd (dcfldd) going against raw disks.

Why is it surprising that dd (which just moves large chunks of data) would be improved by a movement from 4-byte natural word size to 8-byte natural word size?

That's like being surprised that thicker pipes can move more gallons of water per hour.

Because everyone knows that the disk drive/SATA-bus/controller/PCI-bus/DMA are the limiting factors in raw dd speed, so who cares how the kernel/app are compiled.

That's true for unsophisticated disk I/O sub-systems like in Microsoft's products. But dd doesn't write to disk... it writes to buffers held in RAM, and then forgets about it, letting the system flush the buffers out to disk when needed.

...

And my tests were with a PCI-bus controller. With a PCI-Express controller the 32-bit/64-bit issue for kernel/userland is likely even more important.

Greg

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Jan Engelhardt

31 Oct 31 Oct

09:03

On Oct 30 2007 16:46, Aaron Kulkis wrote:

...

...
Because everyone knows that the disk drive/SATA-bus/controller/PCI-bus/DMA are the limiting factors in raw dd speed, so who cares how the kernel/app are compiled.

But dd doesn't write to disk... it writes to buffers held in RAM, and then forgets about it, letting the system flush the buffers out to disk when needed.

Yes, and that is the problem. As soon as your data set is bigger than the immediately available cache, write-out will happen and a speed drop will be visible. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

primm

30 Oct 30 Oct

18:35

...

...
...
Has anyone run benchmarks on an identical system with 32 bit vrs 64 bit?

I only notice the difference when loading and editing big photos using gimp over nfs. Use 64 bit for nfs. Otherwise you can't tell. L x Hey, I replied to a message! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Buddy Coffey

18:42

...

...
...
Has anyone run benchmarks on an identical system with 32 bit vrs 64 bit?

Here is a benchmark of 32 bit vs 64 bit openSuSE 10.3 on a Core 2 Duo system.

I have both 32 bit and 64 bit versions installed in separate partitions on the same system with all updates applied. I ran my computationally intensive code GEMACS (http://www.gemacs.com) compiled natively for both 32 and 64 bits with the Intel 9.1 compilers. The code performs little I/O and zero graphics. The code is multi-threaded and fairly well balanced, hence, the total CPU numbers are about 2X the elapsed time numbers. 64 bit: Elapsed time: 59.316 sec Total CPU time: 112.43 sec 32 bit: Elapsed time: 59.749 sec Total CPU time: 105.67 sec I would be glad to run other comparisons if anyone would like them. Buddy Coffey Applied Research Associates Computational and Applied Electromagnetics -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Jan Engelhardt

20:10

On Oct 30 2007 14:42, Buddy Coffey wrote:

...

...
...
...
Has anyone run benchmarks on an identical system with 32 bit vrs 64 bit?

I have both 32 bit and 64 bit versions installed in separate partitions on the same system with all updates applied.

I ran my computationally intensive code GEMACS (http://www.gemacs.com) compiled natively for both 32 and 64 bits with the Intel 9.1 compilers.

One can cheat too much. You can compile your 32-bit binary with -mfpmath=sse -msse (and -msse2 and -msse3, if you have it) and bring the running time on par with a 64-bit binary. What does that prove? Just that the CPU executes both ISAs at roughtly the same speed, and that it is hence marketable. What is really interesting for the casual user (IMHO) is how a *stock* 32-bit SUSE compares to a *stock* 64-bit SUSE. So here is the result of encoding a 1h:57m WAV file using the stock i586 libvorbis+oggenc vs. stock x86_64 libvorbis+oggenc using lbuild to provide a clean, chrooted install. -q3 in 32-bit: 8m24.3s 8m24.6s 8m22.8s -q3 in 64-bit: 5m36.9s 5m34.5s 5m33.0s -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Frank Fiene

21:00

On Dienstag 30 Oktober 2007, Robert Lewis wrote:

...

I recently bought a 64 bit machine and have 10.3 loaded . It seems very fast.

I am trying to appraise if the advantages of having some software not work because of driver issues is worth it.

I think also that 64bit software runs better on a 64bit CPU then 32bit Software. But i want to say what is not working (or what i didn't get working): Moneyplex for example is still a 32bit application so drivers for CardReaders hav to be compiled 32bit also. Problem is now that 32bit CardReader drivers (especially Kobil Kaan Advanced USB) doesn't work with 64bit backends like pcsc-lite and pcsc-ccid and i haven't found a solution yet. Funny thing: the driver connects to the backend via a socket, so this is bad designed Software which depends on the architecture, like 32bit mysql-client cannot connect to a 64bit mysql-server! :-( Maybe i am wrong and someone has some information how to solve this problem maybe with libchipcard, but there is no documentation how to do! Regards Frank -- Frank Fiene / IT-Services Fon: +49 2526 29-6200 Fax: +49 2526 29-16-6200 mailto: ffiene@veka.com www.veka.com VEKA AG Dieselstr. 8 48324 Sendenhorst Deutschland/Germany Vorstand: Andreas Hartleif (Vorsitzender), Dr. Andreas W. Hillebrand Bonifatius Eichwald, Elke Hartleif, Dr. Werner Schuler Vorsitzender des Aufsichtsrates: Heinrich Laumann HRB 8282 AG Münster -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Jan Engelhardt

21:09

On Oct 30 2007 22:00, Frank Fiene wrote:

...

On Dienstag 30 Oktober 2007, Robert Lewis wrote:

...
I recently bought a 64 bit machine and have 10.3 loaded . It seems very fast.

I am trying to appraise if the advantages of having some software not work because of driver issues is worth it.

I think also that 64bit software runs better on a 64bit CPU then 32bit Software.

But i want to say what is not working (or what i didn't get working): Moneyplex for example is still a 32bit application so drivers for CardReaders hav to be compiled 32bit also.

Problem is now that 32bit CardReader drivers (especially Kobil Kaan Advanced USB) doesn't work with 64bit backends like pcsc-lite and pcsc-ccid and i haven't found a solution yet.

Well obviously, if card reader drivers link directly into pcsc libraries, you need 32 bit pcsc libs. If the card reader drivers call a pcsc program as a separate process, they may be of different "bitness". It does not require to install a full openSUSE 32-bit.

...

Funny thing: the driver connects to the backend via a socket, so this is bad designed Software which depends on the architecture, like 32bit mysql-client cannot connect to a 64bit mysql-server! :-(

File a bug, then. :) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Frank Fiene

21:30

On Dienstag 30 Oktober 2007, Jan Engelhardt wrote:

...

On Oct 30 2007 22:00, Frank Fiene wrote:

...
On Dienstag 30 Oktober 2007, Robert Lewis wrote:

...
I recently bought a 64 bit machine and have 10.3 loaded . It seems very fast.

I am trying to appraise if the advantages of having some software not work because of driver issues is worth it.

I think also that 64bit software runs better on a 64bit CPU then 32bit Software.

But i want to say what is not working (or what i didn't get working): Moneyplex for example is still a 32bit application so drivers for CardReaders hav to be compiled 32bit also.

Problem is now that 32bit CardReader drivers (especially Kobil Kaan Advanced USB) doesn't work with 64bit backends like pcsc-lite and pcsc-ccid and i haven't found a solution yet.

Well obviously, if card reader drivers link directly into pcsc libraries, you need 32 bit pcsc libs. If the card reader drivers call a pcsc program as a separate process, they may be of different "bitness".

It does not require to install a full openSUSE 32-bit.

...
Funny thing: the driver connects to the backend via a socket, so this is bad designed Software which depends on the architecture, like 32bit mysql-client cannot connect to a 64bit mysql-server! :-(

File a bug, then. :)

Oh, i've spoken to Ludovic Rousseau (he is the main devloper of pcsc-lite, isn't he?) and he talked about some 32bit-63bit issues. I will give it a new try. Regards -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Jan Engelhardt

21:48

On Oct 30 2007 22:30, Frank Fiene wrote:

...

...
...
Funny thing: the driver connects to the backend via a socket, so this is bad designed Software which depends on the architecture, like 32bit mysql-client cannot connect to a 64bit mysql-server! :-(

File a bug, then. :)

Oh, i've spoken to Ludovic Rousseau (he is the main devloper of pcsc-lite, isn't he?) and he talked about some 32bit-63bit issues.

I will give it a new try.

If I send a uint64_t from an ELF64 program, I expect it to be properly tagged, headered, framed or whatever so that an ELF32 pcsc does not interpret it as two uint32_t. Basics of networking. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Frank Fiene

31 Oct 31 Oct

06:22

On Dienstag 30 Oktober 2007, Jan Engelhardt wrote:

...

On Oct 30 2007 22:30, Frank Fiene wrote:

...
...
...
Funny thing: the driver connects to the backend via a socket, so this is bad designed Software which depends on the architecture, like 32bit mysql-client cannot connect to a 64bit mysql-server! :-(

File a bug, then. :)

Oh, i've spoken to Ludovic Rousseau (he is the main devloper of pcsc-lite, isn't he?) and he talked about some 32bit-63bit issues.

I will give it a new try.

If I send a uint64_t from an ELF64 program, I expect it to be properly tagged, headered, framed or whatever so that an ELF32 pcsc does not interpret it as two uint32_t. Basics of networking.

Yes, but its the other way round! The application is ELF32 and pcsc is ELF64. But anyway, you're right and this doesn't help me! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Ian Smith

30 Oct 30 Oct

23:52

On Tuesday 30 October 2007 08:11:08 Robert Lewis wrote:

...

Has anyone run benchmarks on an identical system with 32 bit vrs 64 bit?

Yes (a little). See: http://www.hermit.org/Linux/Benchmarking/ Ian -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Robert Lewis

31 Oct 31 Oct

00:55

On 10/30/07, Ian Smith wrote:

...

On Tuesday 30 October 2007 08:11:08 Robert Lewis wrote:

...
Has anyone run benchmarks on an identical system with 32 bit vrs 64 bit?

Yes (a little). See:

http://www.hermit.org/Linux/Benchmarking/

This has been a most interesting and informative discussion. However, what most users need to make an informed decision is a list somewhere that shows what won't run currently on 64-bit and what the author of said software might be doing about it. Most people don't want to have to reload there O/S and applications because they get caught with something they need not able to run. Cheers, Bob -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Frank Fiene

06:46

On Mittwoch 31 Oktober 2007, Ian Smith wrote:

...

On Tuesday 30 October 2007 08:11:08 Robert Lewis wrote:

...
Has anyone run benchmarks on an identical system with 32 bit vrs 64 bit?

Yes (a little). See:

http://www.hermit.org/Linux/Benchmarking/

Hey, great benchmarks. As expected but SOMEONE in this discussion will say that these benchmarks are wrong, doesn't matter or whatever and 32bit is faster then 64bit on 64bit machines anyway! But please then show us benchmarks! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Igor Jagec

10:54

On Tue, 2007-10-30 at 16:52 -0700, Ian Smith wrote:

...

On Tuesday 30 October 2007 08:11:08 Robert Lewis wrote:

...
Has anyone run benchmarks on an identical system with 32 bit vrs 64 bit? Yes (a little). See: http://www.hermit.org/Linux/Benchmarking/

I've just found another interesting benchmark: http://www.linux.com/articles/114024 -- Igor Jagec

Peter Cannon

12:10

Robert Lewis wrote:

...

I recently bought a 64 bit machine and have 10.3 loaded . It seems very fast.

I am trying to appraise if the advantages of having some software not work because of driver issues is worth it.

I've just done a 64bit Boot test while it doesn't really answer your question it might be of interest. The result times can be found here http://www.cannon-linux.co.uk *openSUSE 10.3 64 Bit Review #2* -- Regards Peter cannon http://www.cannon-linux.co.uk "There is every excuse for not knowing There is no excuse for not asking" -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

6028

Age (days ago)

6029

Last active (days ago)

List overview

Download

41 comments

17 participants

participants (17)

Aaron Kulkis
Anders Johansson
BandiPat
Buddy Coffey
Frank Fiene
Greg Freemyer
Ian Smith
Igor Jagec
James Knott
Jan Engelhardt
Ness, Todd
Patrick Shanahan
Peter Cannon
primm
Randall R Schulz
Robert Lewis
Russell Jones