Call it sarcasm, or a joke, or perhaps just taking things too literally.
I'm still not sure whether Tom's reply was being sarcastic in return or
if he was really thanking me without realising that the code was useless
to him.
I "Truly" *was* and still am thanking you. In my opinion sarcasm is an
inefficient way of teaching people. Certainly among experts sarcasm at
the level suggested could catch you just right and be gut busting
funny; however, expert I will never be. I think you were being helpful
and provided a perfect solution for the environment which you use.
Certainly illustrates a powerful feature within Linux.
In my ignorance I did not initially define which operating system or C
compiler I was using. Your reply appears to me as magical because I
had never seen the "system" commands used before. I have never used
Linux. Without the additional comments stating how non-portable your
solution was ... I would have been trying to get it to work on my Win
2000 set-up. To think that my knowledge is so limited that I would
have actually attempted this ... really is funny!
Other bits that further illuminate my ignorance are >>
The usage of:
long long space = create_ramdisk();
I am guessing you are "naming" or creating a "space" of some sort
within the program. I have read in the past about "named" spaces but
that topic really went over my head at that time and remains there
today. Until now ... I have been able to work around not understanding
named spaces but I should revisit that subject soon. Perhaps now it
will sink in.
Another bit that caught my eye was the "%lld" usage. I have used "%ld"
many times but have never even seen double precision specified in such
manner.
At this time I need to pursue whatever it takes to make this Ram disk
feature work in Win 2000. One Win 2000 specific article I have found
is the following:
http://support.microsoft.com/kb/q257405/
This task might become hairball nasty difficult. I really don't know.
Any suggestions on good books that bridge between C code and beginner
level system programming?
Comparing the solution for a Win 2000 system to that of a Linux
solution will be most interesting and educational for me. Using a Ram
disk for security reasons (Kiosk) or harsh environments (high
vibration) is very interesting. Even if it is not the best solution
for my specific task I am learning a little outside the box.
Some have suggested profiling to determine the exact bottlenecks. I
have no profiling experience but understand a slow I/O task made fast
using a Ram disk or other technique may not speed up the program any
what-so-ever if it was not previously the rate limiting step ... and
if the I/O task is truly performed parallel to the other tasks.
However, if the I/O has any sequential behavior ... even if it is not
the longest duration event ... saving time on that specific
sequentially acting task speeds the program. It seems to me that a Ram
disk would make read time as fast as possible and thus making read
time no longer a consideration for speed improvements. However, would
not cache management still be handling the I/O from the Ram disk? So
another method of some sort might be a better solution? A method that
simply retrieves values designated as in memory and entirely avoids
any internal cache management logic? After all, why should cache
memory be used to hold something already residing in memory? Even if
the time penalty is insignificant ... it is still double handling the
data.
My original attempts at specifying a very large array for this task
failed. Anytime I exceeded approximately 600,000 for the array size
.... the program would not compile.
Quoting from MSDN Library >>
----------------------------
Largest Array Size
ANSI 3.3.3.4, 4.1.1 The type of integer required to hold the maximum
size of an array—that is, the size of size_t
The size_t typedef is an unsigned int with the range 0x00000000 to
0x7CFFFFFF.
----------------------------
The above range yeilds a maximum indexing value of 2,097,151,999. Am I
misreading the doco somehow?
Some have suggested some type of memory mapping technique. I have done
some searching in that area and have not yet found a technical reason
for memory mapping to be of benefit. Its name certainly sounds
promissing ... so I will continue searching in that area too.
Boost provides some library routines too. I have not used any Boost
routines as of yet; however, the boost.filesystem provides some
interesting functionality ... but still does not manage the memory
space as I am hoping to do.
I'm confused how any code that is "entirely" portable can be
considered to be useless?