Luminous Landscape Forum
Equipment & Techniques => Digital Cameras & Shooting Techniques => Topic started by: dwdallam on September 07, 2008, 03:46:03 am
-
At this link:
http://wwwimages.adobe.com/www.adobe.com/p...support_FAQ.pdf (http://wwwimages.adobe.com/www.adobe.com/products/photoshop/photoshop/pdfs/ps_cs3_64-bitsupport_FAQ.pdf)
I was under the very wrong impression that 64bit apps would greatly increase my CPU processing efficiency, since I have the first generation AMD 4800 64 bit Dual Core CPU in teh machine I now use. Boy, was I wrong.
According to Adobe, the gains will not come from 64bit vs. 32bit, since they say tests with PS 64 vs. PS 32 net only an 8-12% increase in speed. The speed increase will come from large files not swapping to the hard drive--duh. 32 bit apps can only use 4GB of RAM compared to 64bit apps using infinite amounts of RAM.
So if you work on 3GB files, and you have PS in 32bit version with 4GB of RAM, you'll run out of RAM and begin swapping the file to the hard drive, which as you know really slows things down. If you have the same file using PS 64bit and 32GB of RAM--or however much you need to manipulate a 3GB file in RAM--then you can use that RAM, and speed things up by keeping the entire 3GB file in RAM.
But if you aren't swapping now, you're only gonna get an 8-12% increase in processing an image with PS 64.
-
So if you work on 3GB files, and you have PS in 32bit version with 4GB of RAM, you'll run out of RAM and begin swapping the file to the hard drive, which as you know really slows things down. If you have the same file using PS 64bit and 32GB of RAM--or however much you need to manipulate a 3GB file in RAM--then you can use that RAM, and speed things up by keeping the entire 3GB file in RAM.
[a href=\"index.php?act=findpost&pid=219920\"][{POST_SNAPBACK}][/a]
Something else to be aware of is that a given process will need more RAM in 64 bits to address a given task, since the words are twice longer. Not quite twice as much memory, but not far from there.
The net result is that you'll basically need more than twice the physical memory to see actual benefits which means that a machine with 8GB is the bare minimum.
Cheers,
Bernard
-
Regardless of which OS you use, this short video (http://www.youtube.com/watch?v=id5vpy2CapY) gives a great comparison of a 32-bit vs. 64-bit photographic application using a 4GB file.
-
Something else to be aware of is that a given process will need more RAM in 64 bits to address a given task, since the words are twice longer. Not quite twice as much memory, but not far from there.
The net result is that you'll basically need more than twice the physical memory to see actual benefits which means that a machine with 8GB is the bare minimum.
Cheers,
Bernard
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=219924\")
Saying that twice the memory is required for 64 bit apps overstates the situation. The program code in an application consists of instructions for the processor (opcodes) and pointers. In a 64 bit application the pointers are twice as large as in a 32 bit application but a full 64 bit word is not necessary to specify the processor operations (see page 64 of the [a href=\"http://www.intel.com/design/processor/manuals/253666.pdf]Intel Processor Manual[/url]). Therefore, a 64 bit program does not require twice the memory as a 32 bit program. Perhaps someone can compare the .exe size of the 32 and 64 bit versions of Lightroom v 2.
Moreover, when one loads a large image into Photoshop, the majority of the memory usage is for the image data, not the program. The same amount of memory is needed for image storage in both 32 and 64 bit programs.
The Adobe knowledge base article Optimizing PSCS3 with XP and Vista (http://kb.adobe.com/selfservice/viewContent.do?externalId=kb401088&sliceId=2) discusses memory usage with CS3 in 32 bit and 64 bit windows operating systems.
-
My experience with 64 bit programs vs. 32 bit (enterprise level java applications, not pc-based) shows 20-30% more memory use with 64 bit. The advantage of course is access to tons more memory.
Here in late 2008, 64-bit may not mean much. But I'd bet in a couple of years, we'll see reasonably priced PCs with 64GB of ram.
-
Regardless of which OS you use, this short video (http://www.youtube.com/watch?v=id5vpy2CapY) gives a great comparison of a 32-bit vs. 64-bit photographic application using a 4GB file.
[a href=\"index.php?act=findpost&pid=219950\"][{POST_SNAPBACK}][/a]
That's right. At 4GBs because you will get swapping of the file if it is that large because you're out of RAM on a 32bit system.
A more accurate comparison of 32 and 64 bit speed increases is where each system is working with files that can fit completely in memory. Otherwise, what were comparing is how fast RAM is to Hard Disks, which is silly.
So we get an 8-12% boost in at least Photoshop rendering.
I wonder if this is true for other apps too, such as video editing and gaming, although I've heard that a 64bit gaming application can drive graphics realism much further using 64bit (such as rounded edges and facial features, to name but two)?
I also wonder if for most of us the 64bit bus system will not generate that much saved time when rendering, since even when manipulating a 100MB file, a 4GB RAM system should have enough RAM for the entire image.
I wonder though because I was running out of RAM after I bought the 1DS3--from 13MB files to 25MB files. I went to 4GB and that took care of the problem. I'll create a 50MB file tongiht and see what I get, then report back.
-----
I just did a 65MB tiff file. I tried radial blur, some high power plugins and several other rendering filters in CS3 and never used more than 2.62GBs of RAM. I even duplicated three layers and ran the tests. I then increased the file size to 598MB disk size and rant he same filters and plugins. According to System Monitor in Vista 64, I never used more than 71% of physical memory. This tells me that the 64bit Photoshop isn't a big deal, at least for me, since I'll only see an 8-12% increase in rendering speeds. What's more important, it tells me I need to upgrade my CPU if I want to get faster speeds. However, when everything is loaded into RAM, it's not really an issue.
-
That's right. At 4GBs because you will get swapping of the file if it is that large because you're out of RAM on a 32bit system.
A more accurate comparison of 32 and 64 bit speed increases is where each system is working with files that can fit completely in memory. Otherwise, what were comparing is how fast RAM is to Hard Disks, which is silly.
So we get an 8-12% boost in at least Photoshop rendering.
I wonder if this is true for other apps too, such as video editing and gaming, although I've heard that a 64bit gaming application can drive graphics realism much further using 64bit (such as rounded edges and facial features, to name but two)?
I also wonder if for most of us the 64bit bus system will not generate that much saved time when rendering, since even when manipulating a 100MB file, a 4GB RAM system should have enough RAM for the entire image.
I wonder though because I was running out of RAM after I bought the 1DS3--from 13MB files to 25MB files. I went to 4GB and that took care of the problem. I'll create a 50MB file tongiht and see what I get, then report back.
[a href=\"index.php?act=findpost&pid=220076\"][{POST_SNAPBACK}][/a]
Thoughts:
(1) It does not take many layers in CS3 for a 25mb file to balloon to 500mb.
(2) Only about 3.5GB is available to all applications under 32-bit XP. Other programs and TSRs use memory too; so that amount available to CS3 may be considerably more limited.
(3) CS3 creates temporary files that get swapped out. Does anyone know if Adobe has designed CS4 64-bit such that NOTHING gets swapped out if enough memory is present? I.e., it would be a serious oversight if a machine with 32GB of RAM running 64-bit CS4 is doing any swapping at all.
-
Thoughts:
(1) It does not take many layers in CS3 for a 25mb file to balloon to 500mb.
(2) Only about 3.5GB is available to all applications under 32-bit XP. Other programs and TSRs use memory too; so that amount available to CS3 may be considerably more limited.
(3) CS3 creates temporary files that get swapped out. Does anyone know if Adobe has designed CS4 64-bit such that NOTHING gets swapped out if enough memory is present? I.e., it would be a serious oversight if a machine with 32GB of RAM running 64-bit CS4 is doing any swapping at all.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=220082\")
See my tests above, but I didn't notice anything swapping when I did them. Also, the 598MB file was a three layered (full duplicates of the original) tiff file with no compression. I think it would take quite a bit of layers to reach 600MB if you start with a 25MB file. But your point is taken. For graphics users, not necessarily photographic use, things add up quickly. I was only talking about a 25-50MB file, as a starting point, since rumors have Canon coming out with the 1DS4 at 32MPs probably in 2009. I think that's kinda crappy, since I just bought mine 4 months ago. So we'll get a new 1DS at 32MP, while I just forked over 8K US less than 8 months before the new 1DS comes out. Also, not a rumor, but Canon already has the technical acuity to do a FF 100MB camera. At this rate of turn over, they'll put MF out of business--lol. But that means new glass all around too, and I'm "not down with that."
Here's a look at the new 1DS MKIV
[a href=\"http://www.dcresource.com/forums/showthread.php?t=40674]http://www.dcresource.com/forums/showthread.php?t=40674[/url]
-
Moreover, when one loads a large image into Photoshop, the majority of the memory usage is for the image data, not the program. The same amount of memory is needed for image storage in both 32 and 64 bit programs.
[a href=\"index.php?act=findpost&pid=219971\"][{POST_SNAPBACK}][/a]
That was not my understanding, but I could be wrong.
My understanding was that when a file is opened in memory, it fills up various data type like arrays, and each of these is a variable that ends up having to be coded on 64 bits instead of 32 bits. Since the physical memory is 32 bits still, you need double the memory to store the same amount of data.
I'd be glad to be explained why I am wrong, I haven't be involved with these things since collegue.
Cheers,
Bernard
-
That was not my understanding, but I could be wrong.
My understanding was that when a file is opened in memory, it fills up various data type like arrays, and each of these is a variable that ends up having to be coded on 64 bits instead of 32 bits. Since the physical memory is 32 bits still, you need double the memory to store the same amount of data.
I'd be glad to be explained why I am wrong, I haven't be involved with these things since collegue.
Cheers,
Bernard
[a href=\"index.php?act=findpost&pid=220121\"][{POST_SNAPBACK}][/a]
I'm not a programming expert either, but the following is my understanding and I would also welcome clarification by Eric Chan or other experts.
The basic data types used for Photoshop are 8 bit integers, 16 bit integers, and 32 bit floating point (used in HDR images). A 30 MB image will require 30 MB of memory regardless of whether you have a 32 or 64 bit system. A 64 bit microprocessor can load a 16 bit integer and does not need to load an entire 64 bit word. Since we are working mostly with 8 and 16 bit data in Photoshop, it is not surprising that a 64 bit processor leads to little performance improvement as long as memory requirements are not exceeded.
The 64 bit pointers used for memory addressing are twice the size of 32 bit pointers, and do require twice the storage space with 64 bit.
Bill
-
There is also extra memory used by PS for caching parts of the image, as well as history states, etc. So having extra memory available is a good thing.
That doesn't automatically translate into speed increases, however. As Bill noted, unless you are grossly exceeding the amount of physical memory available on a regular basis, you're probably going to see little to no speedup with 64-bit.
-
Even if PS can't directly access more than 3.5GB or so of memory, it can swap to memory. If you have, say, 8 gigs of memory, you can assign 4 gigs of that to a virtual drive and point the primary PS swap drive to that letter. Definitely faster than swapping to HDD.
-
How do you assign a virtual drive in windows 64bit?
Example 8GB total ram and I want to create a 4GB virtual
drive?
Paul C
-
I also wonder if for most of us the 64bit bus system will not generate that much saved time when rendering, since even when manipulating a 100MB file, a 4GB RAM system should have enough RAM for the entire image.
I wonder though because I was running out of RAM after I bought the 1DS3--from 13MB files to 25MB files. I went to 4GB and that took care of the problem. I'll create a 50MB file tongiht and see what I get, then report back.
-----
I just did a 65MB tiff file. I tried radial blur, some high power plugins and several other rendering filters in CS3 and never used more than 2.62GBs of RAM. I even duplicated three layers and ran the tests. I then increased the file size to 598MB disk size and rant he same filters and plugins. According to System Monitor in Vista 64, I never used more than 71% of physical memory. This tells me that the 64bit Photoshop isn't a big deal, at least for me, since I'll only see an 8-12% increase in rendering speeds. What's more important, it tells me I need to upgrade my CPU if I want to get faster speeds. However, when everything is loaded into RAM, it's not really an issue.
[a href=\"index.php?act=findpost&pid=220076\"][{POST_SNAPBACK}][/a]
Slap some layer masks on those duplicate layers and start brushing them, then start playing around with opacities, blend modes, etc. While you're at it increase the number of history state PS makes so that when you're doing brushwork you can still go back a ways if you change your mind. You might be surprised at how much memory PS want to use.
I have an 8GB Vista x64 box, and Photoshop is regularly using the full 3.2 GB I can allocate to it when I'm working with stitched panos (and I'm not talking really huge stuff, using in the 30-60 megapixel range). I'm looking forward to a 64-bit version of PS very much and expect to get a very real benefit from it even with "only" 8GB of RAM.
-
That was not my understanding, but I could be wrong.
My understanding was that when a file is opened in memory, it fills up various data type like arrays, and each of these is a variable that ends up having to be coded on 64 bits instead of 32 bits. Since the physical memory is 32 bits still, you need double the memory to store the same amount of data.
I'd be glad to be explained why I am wrong, I haven't be involved with these things since collegue.
Cheers,
Bernard
[a href=\"index.php?act=findpost&pid=220121\"][{POST_SNAPBACK}][/a]
Pointers double in size. So the pointer and other data structures used by PS will increase in size. But the actual image data doesn't double in size.
-
That was not my understanding, but I could be wrong.
My understanding was that when a file is opened in memory, it fills up various data type like arrays, and each of these is a variable that ends up having to be coded on 64 bits instead of 32 bits. Since the physical memory is 32 bits still, you need double the memory to store the same amount of data.
I'd be glad to be explained why I am wrong, I haven't be involved with these things since collegue.
Cheers,
Bernard
[a href=\"index.php?act=findpost&pid=220121\"][{POST_SNAPBACK}][/a]
Adobe Q&A addresses this myth. I forgot what I read, but it is nowhere near double because the way a 64bit system amnages it's memory blocks makes up for it in many instances.
-
Even if PS can't directly access more than 3.5GB or so of memory, it can swap to memory. If you have, say, 8 gigs of memory, you can assign 4 gigs of that to a virtual drive and point the primary PS swap drive to that letter. Definitely faster than swapping to HDD.
[a href=\"index.php?act=findpost&pid=220154\"][{POST_SNAPBACK}][/a]
I am not completely sure, but off the top of my head I think that this does not work. (I have only 4 GB of physical memory on my laptop, so I cannot try it.)
The 3.5 GB limitation is not a PS limitation but a 32-bit Windows limitation. I believe that the virtual drive redirection software runs under 32-bit Windows and is therefor subject to the 3.5 GB limitation.
Someone please correct me if I am wrong.
Best,
Bruce
-
Thank you for the thread Doug. It's of particular interest to me as I'm just getting my first desktop built and I intend installing Xp pro 32 bit in the belief that I can have it up and running in a day and not spend any more time than I do now making it work. (I don't want to spend time on another learning curve).
Anyway, can anyone tell me if I'm correct in the belief that if solid state hard drives become cheap enough for the general user, then they will be nearly as fast as ram. In other words, making 64 bit systems and/or a lot of ram unnecessary? Cheers, David
Ps. It's amazing what a little laptop can do when connected up to a reasonable monitor, but when it's stitching a panorama bigger than it's installed memory I have time to do, um, a lot of other things.
-
Anyway, can anyone tell me if I'm correct in the belief that if solid state hard drives become cheap enough for the general user, then they will be nearly as fast as ram. In other words, making 64 bit systems and/or a lot of ram unnecessary? Cheers, David
No for a couple of reasons:
1. the memory isn't the same type as RAM (a disk needs to hold what's stored in it when it's powered down, after all!)
2. disk interfaces aren't in the same speed range as memory bus bandwidth
Giles
-
According to Adobe, the gains will not come from 64bit vs. 32bit, since they say tests with PS 64 vs. PS 32 net only an 8-12% increase in speed.
I'd take any speedup as a bonus; on other (non x86) architectures I'm familiar with, 64 bit applications pay a small (few percent only) penalty over their 32 bit cousins running on the same operating system and hardware.
Giles
-
No for a couple of reasons:
1. the memory isn't the same type as RAM (a disk needs to hold what's stored in it when it's powered down, after all!)
2. disk interfaces aren't in the same speed range as memory bus bandwidth
Giles
[a href=\"index.php?act=findpost&pid=220322\"][{POST_SNAPBACK}][/a]
Both good reasons. Wishful thinking getting the better of me I fear
-
Thank you for the thread Doug. It's of particular interest to me as I'm just getting my first desktop built and I intend installing Xp pro 32 bit in the belief that I can have it up and running in a day and not spend any more time than I do now making it work. (I don't want to spend time on another learning curve).
Anyway, can anyone tell me if I'm correct in the belief that if solid state hard drives become cheap enough for the general user, then they will be nearly as fast as ram. In other words, making 64 bit systems and/or a lot of ram unnecessary? Cheers, David
Ps. It's amazing what a little laptop can do when connected up to a reasonable monitor, but when it's stitching a panorama bigger than it's installed memory I have time to do, um, a lot of other things.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=220278\")
Giles is right, but let me expand on that a little. I've done a fair amount of research of SSDs lately.
To answer your question, no. As Giles said, the bus limitations of today's motherboards is about 50mbs tops, no matter what your hard drive or any other drive can do. But your question is more than just about speed. Can SSD's even simply replace RAM or the need for RAM? Who knows. At some point most likely the information stored on SSD's will probably match the speed of RAM in some way, perhaps with the use of onbard RAM directly on the SSD's board, but that is years and years away.
Today's hard drives can sustain a transfer of up to 300mbs with SATA300. Still, you're limited by the bus systems. That's the bottle neck.
Giles is also correct when he says that RAM is different than SSD drives, but for other reasons than volatility, such as RAM does not use the bus system. The information in RAM is directly available to the CPU and software. SSD's still require the information they hold to travel through the bus system. So they require RAM too.
The reason SSD's are "faster" than hard drives is because of their access time, which is pretty much instantaneous. So if you are opening a program, for instance, you are really opening many, many smaller files, such as the programs DDLs and other parts of teh program that are fairly small, like less than 50MB. So the SSD's can open those files almost instantly, and when you add up hundreds of small files needing to be loaded in order to run, say Photoshop, you get a huge increase in program opening and closing. The problem lately is that SSDs are very slow in sustained writing, until just recently (see below).
But here's the rub: You won't see any gain in "sustained" writing, say moving a 1GB because the sustained write speed is limited to the bus architecture, which at present tops out at about 50MBs. The reason people see a big increase in speed when using RAID is because they have greatly reduced the access time, just like using a SSD. So SSD's do kick ass when you are accessing lots of small files at one time, such as transferring hundreds of 1-10MB files. (Again, even transferring those small files was the bottle neck in the SSDs, slower thana good hard rive by quite a lot, until recently because SSDs were horrible at sustained transfer speeds).
One other thing to overcome, and SSD manufacturers are already on it, is that VISTA is not well adapted to SSDs. It's really horrible actually. This was one reason SSDs were having trouble with sustained write speeds. So SSD manufacturers have to develop on board controllers that allow the SSDs to reach their full potential--up to 50MBs sustained transfers on today's bus systems. They are starting to come out right now and are impressive.
I'll be the first to invest in an SSD when they get their upgraded controllers working, and they just have, and when the size gets to around 200GB for a reasonable price. Although even an 80SSD used only for your program files and Windows itself will greatly speed up your work flow simply because that is where all the program loading takes place. And if you are using a 64 bit program on a 64bit OS, your increase in overall speed will be dramatic--(1) Access time is virtually instantaneous, (2) the information, once opened, will be in RAM, even huge GBs of files, if you have the RAM space. However, opening a file larger than 50MB will be, again, the bottle neck because of the bus system limitations. So the speed increase will be perceived as "faster" because of the time it takes to open programs pretty much. That's how SSDs are being marketed right now, by showing how much faster they load Windows--and they are much faster. I think they are showing speeds loading Windows Vista in under 15 seconds from power on.
One other thing. SSDs don't have to reach a sustained (called sequential) read and write speed of SATA hard rives at 300MBs. All they need to do is reach around 50MBs and they will match any hard rive out there because of the bus limitations. I think some of the SSDs are reaching that 50+ MBs threshold now.
Actually, one other thing: SSDs will be great for external USB backup options.
Last, I would load Vista 64. The learning curve is very low. Simply put the VISTA 64 system into classic mode, like I have mine, and your pretty much done. 32bit OS's are a dying breed. You might as well get on board now rather than later.
So there you go in a nutshell.
Here is an article:
[a href=\"http://techreport.com/articles.x/15433]http://techreport.com/articles.x/15433[/url]
-
Giles is right, but let me expand on that a little. I've done a fair amount of research of SSDs lately.
To answer your question, no. As Giles said, the bus limitations of today's motherboards is about 50mbs tops, no matter what your hard drive or any other drive can do. But your question is more than just about speed. Can SSD's even simply replace RAM or the need for RAM? Who knows. At some point most likely the information stored on SSD's will probably match the speed of RAM in some way, perhaps with the use of onbard RAM directly on the SSD's board, but that is years and years away.
Today's hard drives can sustain a transfer of up to 300mbs with SATA300. Still, you're limited by the bus systems. That's the bottle neck.
Giles is also correct when he says that RAM is different than SSD drives, but for other reasons than volatility, such as RAM does not use the bus system. The information in RAM is directly available to the CPU and software. SSD's still require the information they hold to travel through the bus system. So they require RAM too.
The reason SSD's are "faster" than hard drives is because of their access time, which is pretty much instantaneous. So if you are opening a program, for instance, you are really opening many, many smaller files, such as the programs DDLs and other parts of teh program that are fairly small, like less than 50MB. So the SSD's can open those files almost instantly, and when you add up hundreds of small files needing to be loaded in order to run, say Photoshop, you get a huge increase in program opening and closing. The problem lately is that SSDs are very slow in sustained writing, until just recently (see below).
But here's the rub: You won't see any gain in "sustained" writing, say moving a 1GB because the sustained write speed is limited to the bus architecture, which at present tops out at about 50MBs. The reason people see a big increase in speed when using RAID is because they have greatly reduced the access time, just like using a SSD. So SSD's do kick ass when you are accessing lots of small files at one time, such as transferring hundreds of 1-10MB files. (Again, even transferring those small files was the bottle neck in the SSDs, slower thana good hard rive by quite a lot, until recently because SSDs were horrible at sustained transfer speeds).
One other thing to overcome, and SSD manufacturers are already on it, is that VISTA is not well adapted to SSDs. It's really horrible actually. This was one reason SSDs were having trouble with sustained write speeds. So SSD manufacturers have to develop on board controllers that allow the SSDs to reach their full potential--up to 50MBs sustained transfers on today's bus systems. They are starting to come out right now and are impressive.
I'll be the first to invest in an SSD when they get their upgraded controllers working, and they just have, and when the size gets to around 200GB for a reasonable price. Although even an 80SSD used only for your program files and Windows itself will greatly speed up your work flow simply because that is where all the program loading takes place. And if you are using a 64 bit program on a 64bit OS, your increase in overall speed will be dramatic--(1) Access time is virtually instantaneous, (2) the information, once opened, will be in RAM, even huge GBs of files, if you have the RAM space. However, opening a file larger than 50MB will be, again, the bottle neck because of the bus system limitations. So the speed increase will be perceived as "faster" because of the time it takes to open programs pretty much. That's how SSDs are being marketed right now, by showing how much faster they load Windows--and they are much faster. I think they are showing speeds loading Windows Vista in under 15 seconds from power on.
One other thing. SSDs don't have to reach a sustained (called sequential) read and write speed of SATA hard rives at 300MBs. All they need to do is reach around 50MBs and they will match any hard rive out there because of the bus limitations. I think some of the SSDs are reaching that 50+ MBs threshold now.
Actually, one other thing: SSDs will be great for external USB backup options.
Last, I would load Vista 64. The learning curve is very low. Simply put the VISTA 64 system into classic mode, like I have mine, and your pretty much done. 32bit OS's are a dying breed. You might as well get on board now rather than later.
So there you go in a nutshell.
Here is an article:
http://techreport.com/articles.x/15433 (http://techreport.com/articles.x/15433)
[a href=\"index.php?act=findpost&pid=220470\"][{POST_SNAPBACK}][/a]
Just a few tweaks to Dougs "pretty darn good" explanation:
(1) RAM memory DOES travel across a mortherboard bus to/from the cpu, although it is faster than the bus(es) used to transfer data to/from a hard disk drive. The RAM bus is called the "northbridge" and the peripherals bus is called the "southbridge." There are many buses associated with a modern desktop or laptop computer; one must specify which bus is being discussed to avoid confusion.
(2) SSD is simply an acronym for "solid-state disk." An SSD is a storage subsystem including an array of solid-state (e.g., "semiconductor") memory with a disk drive interface that causes the memory array to emulate or look like a disk drive to the operating system. Although most commercially-available SSDs use flash memory, a handful are available that use common DRAM. The latter type is volatile on power-off and must therefor have a battery back-up system or be limited in use to fast caching/scratch disk operations.
(3) Anyway, I agree completely with Doug's bottom line. Once the executable files of a well-behaved 64-bit application running under a 64-bit OS are loaded into a large memory, execution is no longer disk drive speed limited. That is, neither executable files nor data files in a large application need to be swapped out to disk for lack of memory. Execution should be much faster than the 64-bit application's "32-bit twin" as a consequence.
The dirty little secret here is the "well-behaved" stipulation. Mega applications that have evolved over many generations of application code re-writes and patching may have many thousands of "hooks" and "handles" to manage disk swapping activities; and these may be distributed all over millions of lines of code. Because of the monumental nature of a conversion of such large applications from 32-bit to 64-bit, there may be a tendency in some quarters of the software industry to release 64-bit application versions that continue to do some disk swapping even in the presence of sufficient RAM to avoid such performance-sucking nonsense. For example, if I have 32 GB of RAM and Mega-application A can load all of its executable modules into 4 GB of RAM, I want Mega-application A to load a basic subset of modules sufficient to begin working. Then, in the background, I want "A" to load all the remaining modules so that I am not forced to wait, watching the disk drive light blink, after clicking on a tool that causes ten new modules to load. And I certainly do not want to see the disk drive light blink as a consequence of my shiny new 64-bit Mega-app A writing a temporary file to disk. Basically, if I have invested in all that expensive RAM, expensive 64-bit OS, and expensive 64-bit Mega-app A, I do not want to see the disk drive light blink AT ALL until I decide to save a file.
Altough I have not yet converted to 64-bit, I have seen enough of this industry over the course of 30 years that I will be very pleasantly surprised if, after conversion, I see quiescence of the disk drive light.
-
Just a few tweaks to Dougs "pretty darn good" explanation:
(1) RAM memory DOES travel across a mortherboard bus to/from the cpu, although it is faster than the bus(es) used to transfer data to/from a hard disk drive. The RAM bus is called the "northbridge" and the peripherals bus is called the "southbridge." There are many buses associated with a modern desktop or laptop computer; one must specify which bus is being discussed to avoid confusion.
(2) SSD is simply an acronym for "solid-state disk." An SSD is a storage subsystem including an array of solid-state (e.g., "semiconductor") memory with a disk drive interface that causes the memory array to emulate or look like a disk drive to the operating system. Although most commercially-available SSDs use flash memory, a handful are available that use common DRAM. The latter type is volatile on power-off and must therefor have a battery back-up system or be limited in use to fast caching/scratch disk operations.
(3) Anyway, I agree completely with Doug's bottom line. Once the executable files of a well-behaved 64-bit application running under a 64-bit OS are loaded into a large memory, execution is no longer disk drive speed limited. That is, neither executable files nor data files in a large application need to be swapped out to disk for lack of memory. Execution should be much faster than the 64-bit application's "32-bit twin" as a consequence.
The dirty little secret here is the "well-behaved" stipulation. Mega applications that have evolved over many generations of application code re-writes and patching may have many thousands of "hooks" and "handles" to manage disk swapping activities; and these may be distributed all over millions of lines of code. Because of the monumental nature of a conversion of such large applications from 32-bit to 64-bit, there may be a tendency in some quarters of the software industry to release 64-bit application versions that continue to do some disk swapping even in the presence of sufficient RAM to avoid such performance-sucking nonsense. For example, if I have 32 GB of RAM and Mega-application A can load all of its executable modules into 4 GB of RAM, I want Mega-application A to load a basic subset of modules sufficient to begin working. Then, in the background, I want "A" to load all the remaining modules so that I am not forced to wait, watching the disk drive light blink, after clicking on a tool that causes ten new modules to load. And I certainly do not want to see the disk drive light blink as a consequence of my shiny new 64-bit Mega-app A writing a temporary file to disk. Basically, if I have invested in all that expensive RAM, expensive 64-bit OS, and expensive 64-bit Mega-app A, I do not want to see the disk drive light blink AT ALL until I decide to save a file.
Although I have not yet converted to 64-bit, I have seen enough of this industry over the course of 30 years that I will be very pleasantly surprised if, after conversion, I see quiescence of the disk drive light.
[a href=\"index.php?act=findpost&pid=220495\"][{POST_SNAPBACK}][/a]
(1) Yes that is true, unless you are using an AMD CPU. They have no north and south bridge. But I don't know exactly how they get around it.
(3) Or open another file. But yeah that's how I see it too. If they did "some" swapping of a very small dll or module, that would be unnoticeable pretty much though, especially if you had the app on an SSD drive.
Thanks for that clarification.
-
And than you both for your explanations.