News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

Data Transfer Speed

Started by Farabi, March 23, 2009, 04:50:34 AM

Previous topic - Next topic

Farabi

Is transfering data from a buffer to buffer depend on harddisk speed too?
Those who had universe knowledges can control the world by a micro processor.
http://www.wix.com/farabio/firstpage

"Etos siperi elegi"

Mark Jones

Well, this may depend... what do you mean by a "buffer?"
"To deny our impulses... foolish; to revel in them, chaos." MCJ 2003.08

donkey

Hi Farabi,

If you think about the question you will realize there is no answer possible. Since Windows can use the hard disk as virtual memory, there is never a solid guarantee that a memory buffer is not actually partially or wholly residing on the disk. Conversely since modern hard drives can have very large memory caches it is completely possible that a file on your hard drive is held in its cache and is not drive speed dependent. So in any scenario the answer is both Yes and No at the same time.
"Ahhh, what an awful dream. Ones and zeroes everywhere...[shudder] and I thought I saw a two." -- Bender
"It was just a dream, Bender. There's no such thing as two". -- Fry
-- Futurama

Donkey's Stable

MichaelW

I think more often than not, the answer would be no. I think anything in the drive's cache would typically also be in the (much larger and much faster) system disk cache. And if it were not, it would still need to be transferred over the drive's interface, and while the interface transfer rate is typically much higher than the drive's internal transfer rate, it's far below system-memory transfer rates.
eschew obfuscation

Farabi

Im sorry, I cannot express my mind.

I heard that windows used virtual memory, which mean if OS memory above the Physical memory it uses harddisk to store it as temporary files.
Those who had universe knowledges can control the world by a micro processor.
http://www.wix.com/farabio/firstpage

"Etos siperi elegi"

Tedd

It does, but only when those portions are not currently in use - when they are required, they will be put into memory again. So, a copy from one memory buffer to another will still be a memory -> memory copy. (Though there could be a short delay while they are pulled into memory the first time - if they haven't been used for a while.)
No snowflake in an avalanche feels responsible.

Farabi

Quote from: Tedd on March 24, 2009, 12:31:19 PM
It does, but only when those portions are not currently in use - when they are required, they will be put into memory again. So, a copy from one memory buffer to another will still be a memory -> memory copy. (Though there could be a short delay while they are pulled into memory the first time - if they haven't been used for a while.)


So that delay is happen on the memory not because it were being put from harddisk to memory?
Those who had universe knowledges can control the world by a micro processor.
http://www.wix.com/farabio/firstpage

"Etos siperi elegi"

Tedd

IF the section of memory was in the page-file, it would need to be put back into memory first -- that will cause a delay. But only on the first access (i.e. the first byte,) after that, all bytes will have been put into memory (unless it's a very large section.)
In general, don't worry about it - if your program is running, it will be in memory (unless the system is very low on spare memory.)
No snowflake in an avalanche feels responsible.

BlackVortex

Quote from: Tedd on March 24, 2009, 12:53:28 PM
In general, don't worry about it
+1
Trust the windows memory management !

dedndave

I am fairly certain that the drives' internal cache is governed by a very different
set of rules, as compared to the OS cache(s). It is primarily used to reconcile
the differences between the bus transfer rate and the physical drive transfer
rate. It is likely emptied as soon as the drive mechanics are able to handle any
pending transfer(s) that may be in the queue.