SCOUG-Programming Mailing List Archives
Return to [ 14 |
February |
2004 ]
<< Previous Message <<
Content Type: text/plain
Lurkers: Be sure to read "Virtual Storage" below. The rest is mostly
just woofin'.
_____
Lynn H. Maxson wrote:
>
> I use an 'allocate' statement, if for no other
> reason than that's what I want to do. I
> would think an engineer would think like this.
Luckily for humanity, engineers do _not_ think like this.
Luckily for all of us, engineers consider the entire system and are
aware of things like feedback, throughput, system maintenance
projections . . .
> In Peter's example he can't process
> more than one matrix at a time.
I can't? My, my, and to think I've convinced myself that I've been
doing so all these years!
> He certainly can't have them all present concurrently
> unless they appear within the same begin-block.
Sure enough, I don't mess up my memory with stuff I won't need until
later! Egad, I'd hate to see all the leftovers in your refrigerator.
Virtual Storage
===============
> Why in a virtual storage system Peter has
> this great concern about the amount of
> (virtual) storage consumed is beyond me.
Fair enough, it's easy to miss the rationale here unless you've actually
done it. [Lynn is asking why not just allocate all the arrays at the
same time, which uses up more linear address space. I previously gave
an example where each BEGIN block automatically deallocated a processed
array before allocating the next one, thus minimizing the use of linear
address space.]
1) First of all, virtual memory does not mean unlimited memory. In OS/2
there is an absolute maximum, and when you use arrays with several
dimensions you can fill up your memory mighty quick. I've max'd out
plenty of memory spaces with multidimensional arrays. Just as a
pertinent example, suppose you want to analyze the past 10 years of the
New York Stock Exchange closing prices (255 business days per year) to
the same values on the American Stock Exchange, the NASDAQ, and the
exchange rate for the Japanese Yen (a major trade partner with
fluctuating economic conditions). This is a very real, very
fundamental, and very necessary calculation. Let's see, 2550 business
days to the 4th power is, umm, a little bit more than OS/2 can handle.
So you partition the array. But if you already wasted a lot of your
memory space you have a lot more partitioning and that's "very bad" if
you want an answer before the market opens tomorrow (try it).
2) Second, the swap file slows you down a *lot*. I ran into this
problem many years ago and I can tell you first-hand, you don't _ever_
want to use the swap file when you're crunching numbers. You end up
swapping the entire array into and out of memory for every loop. Try
it. Create a 500 MB vector and loop through it a thousand times. The
entire 500 MB vector will be swapped in and out of memory 1,000 times.
Bottom line: You don't waste bytes, no matter how much memory you think
you've got.
On this one, Lynn, you had a good question and I'm happy to pass along
my experiences.
===============
> For most of us non-programmers who think in terms
> of what we want to have happen when we no longer
> need a dynamically allocated variable, we can 'free'
> it. We can do it without any of the limitations
> imposed by a begin-block, i.e. within a specific,
> non-shared code segment.
Isn't that what "spaghetti code" looks like? A free-for-all of "a
little bit here" and "a little bit there"?
> If you don't understand why in this instance the 'begin'
> functions as an 'allocate' and the 'end' a 'free', then
> you must think that there is some magic in the box.
There's no magic, Lynn. I know what it's doing.
> Otherwise you know and control when
> it is allocated and when it is freed.
That I do. With a BEGIN and an END.
> To say that an engineer somehow prefers one
> form to the other does not hide the fact that
> in either case he is programming its allocation
> and deallocation in the same manner that any
> programmer would.
You were arguing about my using BEGIN. Now you're changing the argument
'cause you're in a box.
> That Peter found a third use [for BEGIN] to
> avoid an 'allocate' and 'free' while basically
> restricting his processing options does not
> change the PL/I authors initial intent.
Amusingly, Lynn, you never asked me where I learned about using BEGIN to
allocate an array. It was part of the original IBM training for PL/I
programmers back in the '60s -- training developed in part by some of
the same team members who created the language.
> Once more I invite Peter to use his method
> in the solution of the Peg Solitaire problem.
Nah. I use BEGIN and know it works. I give it to you as a homework
assignment so you can familiarize yourself with its elegance.
> An 'allocate' and 'free' tells the reader
> more explicitly what is occurring than
> hiding it under the covers of a begin-block.
Well then, perhaps you can explain how we can also eliminate all the
PROC statements and explicitly code the setup and takedown for each
entrance and exit . . .
- Peter
=====================================================
To unsubscribe from this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-programming".
For problems, contact the list owner at
"rollin@scoug.com".
=====================================================
<< Previous Message <<
Return to [ 14 |
February |
2004 ]
The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA
Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS
RESERVED.
SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group.
OS/2, Workplace Shell, and IBM are registered trademarks of International
Business Machines Corporation.
All other trademarks remain the property of their respective owners.
| 
