Adobe CS4 64bit

[David Sutton]

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

[dwdallam]

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]

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]

[BruceHouston]

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
[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.

[dwdallam]

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.

[David Sutton]

And than you both for your explanations.