On Mon, 05 Mar 2007 08:14:22 -0500, G. Vincent Castellano wrote: > I was helping someone get set up with 0.95 and noticed that the machine > was a > bit sluggish. Normally I attribute this to the usual "Windows rot" > associated > with registry garbagization but while poking around in properties I > noticed that > he processor was an Athlon 64. > > 1) Does the Quackle Windows package take full advantage of 64 bit > capabilities?
This is a question with a fairly complicated answer. You might be aware of some of the things I'll say here, but I'm saying them for the benefit of the wider audience reading. First, the question is moot if you don't have a 64-bit OS. If you're not running a 64-bit version of Windows xP or Vista, don't even bother further considering the question, as it's simply not possible for you to run an x86-64-native application of any kind. Second, the performance advantages of 64-bit are dubious. If you do a Google search on this, you'll find all kinds of comparisons which show that, for similar 32 and 64-bit applications running under a 64-bit OS, sometimes the 64-bit outperforms the 32-bit, but sometimes the 32-bit outperforms the 64-bit. 64-bit is not theoretically faster, and that's not its principle advantage. I've not done a large amount of research here, but I think the main differences can probably be chalked up to... 64-bit speed advantages + Larger registers + 64-bit OS doesn't have to do 32-bit address translation + Possible on-chip optimizations 32-bit speed advantage + Since pointers are 32-bits, apps use less memory, causing fewer cache misses + Better evolved 32-bit compiler optimizers because the technology has been around longer The real advantage of 64-bit isn't speed, it's memory. Since Quackle remains well within 2 gigabytes of usage, that aspect of the 64-bit advantage simply isn't an issue. In the end, we can't really know the performance advantages without trying it. If somebody else wants to try it, that's great. I've dropped out of Quackle development for about the last 6 months because of high work and personal demands, which I'm hoping will let up in the next couple of months. So, I don't really have time for such experimentation. > 2) What about the source build? I have access to an Athlon server--if I > just > build on that environment will I get more throughput than if I build on a > Pentium and moved that to the Athlon? (This is an academic question, in > the > Linux env there's no reason not to build on your target.) No. What matters is not the environment you build on, it's the code that's being generated. If you have a mingw which generates 32-bit code, it really doesn't matter where you run it. I'm not aware of a way to get mingw to generate 64-bit Windows code, but once again, I've not deeply researched the issue. You could, of course, build on another compiler which does support x86-64 code generation, but mingw is the only environment which the free version of Qt supports. In the spirit of trying to make sure that the community has full access to Quackle development, I've focused on making sure that the Quackle build with completely free tools works. > 3) Can Q take advantage of multiprocessor hosts? Any program which is multi-threaded can take advantage of multiple processors or multiple cores. Jason and John added some limited support for threads in 0.95, but I believe this is only for separating UI and computational work, which doesn't really work a second processor or core very much. But more threading work is planned. Jason or John could comment specifically. > --gvc Sincerely, John Fultz [EMAIL PROTECTED]
