What kind of memory trouble can I get in?

[TBMan]

Will
 

Code: Pascal  [Select][+][-]

1. {$SetPEFlags $20}
2.  
3.  

Save my butt?
I'm writing card games using PTCGraph on a Windows 11 machine. My cards are arrays of bytes that are approximately 11,000 bytes each.  I have 14 decks and would like to expand to about 70. So I'd be looking at 70x11,000x52 = 40,000,000 bytes in memory just for the decks.

Because I plan things butt backwards, NOW I think it would be good idea to have the two through ten cards for each suit be in a common unit, with only the background color being changed as needed, depending on the face cards. Then I would have 9x4x11,000 bytes or 396,000 bytes + another 16 cards (ace, jack, queen, king times 4 (4 suits)) so that's 16x11,000 or 176,000 bytes. So then for 70 decks it would only be 70x176,000 +396,000 or only 12,716,000 for 70 decks. Almost a savings of about 60% of memory use.

My machine probably has about 4 gig of memory so..... what do you think?

[440bx]

as far as IMAGE_FILE_LARGE_ADDRESS_AWARE ($20) saving your butt, I don't think you need it but, it won't hurt having it either.   

As far as what you should do regarding the memory use, I don't think that in this particular case, memory use should be the determining factor in your decision.  IMO, your decision should be determined by the application's long term maintenance complexity.  Usually, having duplicate data is very undesirable because it means that if one change is needed in data that is duplicated, that change needs to be done in as many duplicates as there are.  THAT, IMO, is the real problem, not the memory usage.

As far as memory goes, the days of 640Kb are long gone.  Programmers have gotten used to saving space at the expense of additional code complexity,  IMO, saving space at the expense of code complexity is a bad idea because today's machines support as much as 256GB of memory and that number will increase as time goes by, not to mention that memory gets cheaper as time goes by.

OTH, code complexity means more programmer time, which is usually more expensive every day and, also means a higher probability of bugs in the code.

Conclusion: memory shouldn't be wasted but, the efforts programmers made in the past to save memory at the expense of code complexity are rarely justifiable these days.

The question you should ask yourself is: will having only 1 common set of cards make the app easier to maintain ?  if the answer is yes, then I suggest you take that route and, use as much memory as is necessary to keep the code simple and fast.

HTH.

[creaothceann]

My cards are arrays of bytes that are approximately 11,000 bytes each.  I have 14 decks and would like to expand to about 70. So I'd be looking at 70x11,000x52 = 40,000,000 bytes in memory just for the decks. [...]
My machine probably has about 4 gig of memory so..... what do you think?

11,000 bytes * 52 * 70 = 40,040,000 bytes = ~38.19 MiB. With 4 GiB you could run more than 100 instances of the program at the same time. I could run 800 instances even with the computer I had in 2016 (Intel 4790K with 32 GiB RAM). The CPU I have now (AMD 7800X3D) could fit almost 176 decks into its L3 CPU cache. And of course this doesn't include any VRAM that might be on a graphics card.

[Thaddy]

You don't need it. Also it is only relevant for 32 bit programs and nobody compiles for 32 bit unless hard-pressed.
For Windows 11 it counts that there are warnings that the 32 bit sub-system may disappear in the future.
That won't be soon, probably, but the signs given by MS are there.

[creaothceann]

the 32 bit sub-system may disappear in the future

That would break a lot of systems and/or use cases. And the promise of backwards compatibility is what keeps a lot of people from going to other OSes.

Yesterday I had to help a coworker with setting up a VM of 32-bit Windows 7 to run an old program, maybe that's what people will have to do in the future.

[Thaddy]

Yes. Remark I do not mean the near future: Microsoft only indicated deprecation of the 32 bit sub-system on 64 bit systems.
Same goes for Linux, btw. And it is restricted to intel/amd x86_64. User space code will certainly be supported for some time to come, but you will run into trouble with 32 bit drivers and Daemons. So there is an important difference.
A practical example is that I inherited a laptop with windows vista 32 bit for which it is nowadays pretty much impossible to find a browser that actually works with https served content: all major browsers for 32 bit windows lack the proper modern protocols (TLS 1.1, 1.2 or higher). The laptop itself is fine and a side install of Linux helped a bit. Although Debian dropped 32 bit Intel/amd support in trixie too.

[LeP]

the 32 bit sub-system may disappear in the future

That would break a lot of systems and/or use cases. And the promise of backwards compatibility is what keeps a lot of people from going to other OSes.

In the next future (form January 2027) in Europe all new systems should be maintained (speaking about consumer use) and should agree with safety and security (new techs too) within 25 years.
The developer will be legally and criminally responsible for any security issues with the device.
For example, if Android switches from 64 to 128 bits in the future (and abandons the 64 bit techs), older devices will be decommissioned, or anyone maintaining the software for older devices will be held liable for any damage (e.g., data loss).
This will apply not only to changes in hardware technology, but also if the manufacturer no longer provides support for a particular version. For example, will Windows 11 no longer be supported in the future? In that case, anyone developing on this system after support ends will be held responsible for all issues, without any justification.

This is a brutal snapshot of what could happen in the future ...

Sò in the future there will not be older techs except for hobbyist.

[Thaddy]

Sò in the future there will not be older techs except for hobbyist.

Well, I am a - recent - pensioner, but still get called for COBOL maintenance jobs.
That fact is always related to stupid management choices and planning.

That said: as a hobbyist I have several exotic systems working and I am glad that FPC supports most of them, including my working IBM series 2. I just conclude 32bit Intel/amd is not mainstream.

[LeP]

Well, I am a - recent - pensioner, but still get called for COBOL maintenance jobs.
That fact is always related to stupid management choices and planning.

Unfortunately, this will not be regulated by legislation in the future; businesses will still be able to decide what to do at their own discretion.
The problem with maintaining old COBOL systems is that these systems are tied to extremely high-risk businesses, such as insurance companies, banks, and government agencies. This prevents them from being updated without potentially negatively impacting their operations.
Even in the region where I live, there are several businesses dedicated to developing COBOL skills for potential placement in companies.

[Thaddy]

It is lucrative at 225 € an hour. plus expenses and no state pension contributions And indeed banks, or in this case inter-bank.
But OMG why are they still running Tandems? That is bad management. I know the constraints, but it is bad management that caused it.
(Some of these systems were already rewritten - in C++ - 20 odd years ago but never made it to production due to the chosen language. Too easy to make mistakes and every C++ only programmer thinks he is (a) god, which makes bug-fixing hard to manage - as in: manager, not programmer)

[TBMan]

Thanks everyone!