What's new
By:
Advanced search…

64 Bits

J

jemmej

Senior Member


Frankly, running a 64-bit app will NOT make your application run at some lightning speed. Period. Sorry to rain on your parade, but it just doesn't work that way. Here is a snippet from anandtech.com on 64-bit. This was written in their coverage article on the initial release of the Athlon 64 processor.

Where does 64-bit help?

Although the performance that will sell the Athlon 64 today has nothing to do with this, the 64-bit part of the equation will definitely play a role in the processor's future. With no final release of the 64-bit version of Windows XP, there is no popular OS support (we will touch on Linux support as well as Win64 support shortly) and no real application support at this time, but where will the 64-bitness of the Athlon 64 help?

There are three main categories that you can split up the performance benefits into: 32-bit applications running on a 32-bit OS, 32-bit applications on a 64-bit OS and 64-bit applications on a 64-bit OS; we will be analyzing each one of these scenarios individually.

Case 1: 32-bit apps under a 32-bit OS

At the launch of the Athlon 64, the predominant operating environment will be running 32-bit applications under a 32-bit OS. All performance benefits the K8 architecture will show here are courtesy of the on-die memory controller, improved branch predictor, higher clock speed and more robust TLBs - none of the performance improvements you'll see in this case will have anything to do with the 64-bit capabilities of the processor.

Case 2: 32-bit apps under a 64-bit OS

When Windows XP 64-bit Edition is officially released (a public beta is due out at the time of publication), many users will be running their 32-bit applications under the 64-bit OS.

Outside of the performance improvements that we just outlined in Case 1, there are a couple of additional benefits the Athlon 64 may offer users. Currently under Windows, although you have a physical memory limit of 4GB, any given process can only use up to 2GB of memory; the remaining 2GB is reserved for use by the OS. With the 32-bit applications under a 64-bit OS scenario, each 32-bit application could be given a full 4GB of memory to work with, instead of being limited to the 2GB Windows process size limitation. Unfortunately this benefit isn't really "plug 'n play" as the application would have to be aware that it can use the added memory, which in the vast majority of cases would require a new patch to be made available.

The second benefit the Athlon 64 could offer in this scenario comes from the availability of additional registers. Although the 32-bit application would still only be compiled to use the regular set of 8 general purpose registers and standard set of FP and SSE2 registers, the 64-bit OS would be able to reference and use all of the registers at its disposal. The performance benefits that you would see here exist in any sort of task handling that the OS would be doing (switching between applications) as well as just regular Windows performance. Granted that the performance improvements seen here should be negligible, considering the extra overhead that does exist when running 32-bit applications in a 64-bit environment (more on this in a bit).

Case 3: 64-bit applications under a 64-bit OS

The final scenario is the one that shows the most promise, yet has the least amount of application support today - running a 64-bit app under a 64-bit OS. Here, the benefits are numerous; not only do you get the performance improvements courtesy of the Athlon 64's architecture, but each application now has full access to the increased number of registers and each application can use much more than 4GB of memory.

Although the Athlon 64 can support 64-bit memory addressability, for demand reasons it only supports 40-bit of physically addressable memory - or ~137GB, not exactly a limiting factor at this point.

The performance improvements developers are expecting to see under this final scenario has been estimated to be in the 10 - 20% range in tasks that are not memory bound, meaning those areas where the application is using less than 2 - 4GB of memory in the first place will still see sizable performance gains courtesy of the availability of more registers. We will investigate a few of these scenarios to substantiate (or refute) these claims later on in the article.

Performance improvements where you are memory bound will be even more impressive; just think about how slow swapping to disk is and how much faster keeping everything in memory makes your computer.
Click to expand...
 
G

Gaspar

Alibre Super User


I'm sorry, but you cut your article right where it started to get good:

64bit aps running under a 64bit OS

I'm not a computer expert, but I still remember the leap from 16 to 32 bits and it was impresive.

In my type of work, its all about speed which the actual state of things does not provide. I love AD just the way it is now and speaking for myself, any improvement we have so much spoken about here is a very far second place compared to:

1) Speed
2) Intranet sharing in Repositories

I wish you could publish the whole article, it seemed interesting this far:

Case 3: 64-bit applications under a 64-bit OS

The final scenario is the one that shows the most promise, yet has the least amount of application support today - running a 64-bit app under a 64-bit OS. Here, the benefits are numerous; not only do you get the performance improvem
Click to expand...

Again, I really wouldn't mind if I AD was the only application I could run on a 64 bit machine. Any old cranky thing can run my administrative stuff.

As an end note, probably the difference in our views comes from the way we use AD. Beleive me, if you NEED to do "big" asseblies and import "complex" geometry, system slow downs are a serious thing. Significantly more speed is no just a "nice to have" for us.

Regards
 
J

jemmej

Senior Member


I think the transition to 32 bit occured when most programs were butting up against the memory allocation limit of 16-bits. The difference between accessing memory and accessing the hard drive (especially THOSE older harddrives) was quite a lot.

Again, the real speed comes from a 32-bit application running in a 32-bit environment....AND one that has been coded from scratch to take advantage of 32-bit operation.

Here is the end of the quotation that got cut-off. The full article is here....
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=1884&p=1

Case 3: 64-bit applications under a 64-bit OS

The final scenario is the one that shows the most promise, yet has the least amount of application support today - running a 64-bit app under a 64-bit OS. Here, the benefits are numerous; not only do you get the performance improvements courtesy of the Athlon 64's architecture, but each application now has full access to the increased number of registers and each application can use much more than 4GB of memory.

Although the Athlon 64 can support 64-bit memory addressability, for demand reasons it only supports 40-bit of physically addressable memory - or ~137GB, not exactly a limiting factor at this point.

The performance improvements developers are expecting to see under this final scenario has been estimated to be in the 10 - 20% range in tasks that are not memory bound, meaning those areas where the application is using less than 2 - 4GB of memory in the first place will still see sizable performance gains courtesy of the availability of more registers. We will investigate a few of these scenarios to substantiate (or refute) these claims later on in the article.

Performance improvements where you are memory bound will be even more impressive; just think about how slow swapping to disk is and how much faster keeping everything in memory makes your computer.
Click to expand...

There is another article specifically on this subject from another site. When I find it, I will post a link.

Jim
 
G

Gaspar

Alibre Super User
Re:

jemmej said:
And I don't know what's up with the wierd 1/2 screen formatting?

Jim
Click to expand...

This would probably also get fixed if the forum ran on 64 bits :D (sorry, couldn't help it).

Thanks a lot for the info Jim.

I know I'm only speaking for myself here ( I can do that because the AD developers will focus on group interest, not only mine) but your article gives more hope on AD 64 :mrgreen: although it also tells me it could be a far goal because it would mean recoding the whole thing :?

I'll read the other article. Thanks again.
 
P

peterepeat

Member
maybe there is hope

Just a thought on Alibre and its Java heritage....
I recall reading that Alibre was ported into the MS J++/.NET architechture. If this is so, then the code is already moderately abstracted from the hardware, as the code running in the java/.net interpreter is almost hardware neutral.
In an ideal world, this would mean that the memory handling, graphics, threading etc was handled by the JVM/CLR (or whatever the .NET equivalent of the java JVM is!).
I imagine much tweaking and optimisation will have been done for the x64 .NET framework, (as it has already for the java 1.5 ), so in an ideal world, the changes for the application to run on a new container could be minimal, and will natively enjoy the benefits upon the release of the new .NET framework for x64.
Regards,
Peter
 
J

jemmej

Senior Member


Assuming that the program has elements that can take advantage of the new 64-bit .NET structure. It does make the transition a little easier being in Java/.NET. I'm sure there are a few lonely souls at work at Alibre on 64-bit right now. I'm sure it will tool-up once XP 64 seems to have a firm release date.

Jim
 
G

Gaspar

Alibre Super User


It seems like performance with big assemblies is split in two areas (simplisticly):

:arrow: Gragphic processing, which was greatly enhaced recently
:arrow: All the math involved in calculating geometries and positions. This is the area still to be improved and it seems like AD 64 :mrgreen: is the way to go

Thanks for the info John :D
 
R

rbrian

Senior Member
Workstation technology in 2005

More Fuel for Gaspars Fire:

Workstation technology in 2005 - PCI Express, 64 Bit Cpu's, Dual Core, Graphics Cards, Memory, SATA II & SCSI Hard Drives, & Media are all covered here!

Also see: Selecting a CAD/CAM system, and see Elysium CAD doctor 5.2 if you handle a lot of varying file types!

And a note for the techie's - .NET Framework Version 2.0 Redistributable Package Beta 1 (x64) and see - x86 and ia64 and x64, oh my! !

I have just glanced at these articles - so this is not an endorsement of any kind, just pointing them out!

hardware-forum_Info-post.jpg


Robert (pushing a pic copy of this preview - to see if I can re-align the formatting!)
 
G

Gaspar

Alibre Super User


64 bits will be all around us any time. Let's push so AD is the first CAD program to take advantage of it!!!
 
M

macinc

Member


When I run AD lately, my Athlon64 keeps beeping and flashing this message on my display:

"What, no 64 bit yet?! If I don't get 64 bit soon, I'm gonna start giving you a 32 bit blue screen :twisted:......better keep the mouse near the save button."

I think it's getting impatient.
 
G

Gaspar

Alibre Super User


I agree Dave.

You just posted about using AD with 500 Mb RAM. I use this every day (plus open office, etc) and I don't see speed being much of a RAM issue. When Alibre lags, it doesn't have to read the HD as you would expect by lack of RAM (well, it does some times, but it's not the regular). When AD lags, it cranks the CPU up to 100% for a lot more time and a lot more often than any one would like.

So I beleive that the big performance leap we all hope for will come from taking all the advantage you can from CPU speed (and usage).

NOTE: I'm far from being an expert.
 
F

flyboydave

Member


While I've also seen it do that a few times a day (usually just before it completely disappears from the screen), that 100% CPU usage you're seeing may be just because all the physical ram is used, and alibre.exe has begun page swapping. You may already know this, but open the task manager, either by CTRL-SHIFT-ESC, or right-click the task bar at the bottom and pick "Task Manager". Go to the Performance tab and look in the Physical Memory (K) box at the "Available" number. Right now, Alibre was just opened, a few iexplore windows, and outlook. Out of my 1gb of ram, I have 157mb available, alibre.exe on the processes tab is using 130mb of memory and 190mb of virtual memory. As I use it, alibre.exe will climb to over 500mb of ram all by itself, which is why I'm going to 2gb. If I only had 512 total, at that point the cpu usage would shoot up and it would run sloooooowwww.

Check yours - at 512mb memory, the minimum you can get in the "available" box is about 20mb or so, windows always reserves at least that much. So if your 512 mb machine has 20mb or less physical memory available, it's using it all up, and you will see a big performance increase by adding more. Or at least, it will take longer to slow down. And just using all the memory can cause applications to spike the cpu and stay there.

Edit: Ok, I just used it for about 15 minutes. The alibre.exe mem usage is now over 215mb, my available dropped to 90mb. That is an increased use of 60 mb in only 15 minutes. Another 45 minutes and it will be all used up. This causes me to have to shutdown alibre and restart it once an hour, and if I forget it frequently crashes.
 
G

Gaspar

Alibre Super User


Thanks for the comment. What I mean by Alibre cranking the CPU up to 100% but not reading the HD is exactly what you say.

When physical RAM is used up, windows mimics RAM with a portion of the HD called the swap file (whose use is also shown in the Task Manager).

When performance (speed) issues are RAM related, the sympthom is a lot of HD reading as the applications load and unload libraries, temp files and parts of your work file to the swap file. This is not what, in my experience, usually happens.

When performance issues are CPU related, you get a lot of CPU usage without the HD being read. When this happens, it means the application is making a huge amount of calculations. RAM is no help here, just pure CPU speed. This, in my opinion, seems to be the case.
 
F

flyboydave

Member


The massive HD usage you're talking about is when all vitrual memory gets used up, and it has to resize the swap file. Once that happens, you might as well just reboot.

I know I do run a lot of TSR stuff, probably more than most, but 512mb is way too small for a cad machine. Even if you're not dragging it way down into page swap area, you've still got to be using up all the ram. And not just because of Alibre's possible memory leak, every cad app uses hundreds of mb of ram all by themselves. Solid Edge, Solid Works, Pro/E, UGNX, and Inventor all use ~100mb just by themselves before any models are even opened. Just opening a small assembly of about 100 parts and Solid Edge shoots to ~200mb. Alibre's initial memory usage is similar, if not a little higher, but it does seem to climb more quickly and never drops back down.

With Alibre and an assembly open, Outlook, and Internet Explorer running, how much available memory do you have, according to the "available" box in the Task Manager?
 
You must log in or register to reply here.
Top