Index
> Windows > Is 0ffffffffh (4GB-1) mem max in Fasm32?Goto page 1, 2 Next |
| Author |
|
|
Fastestcodes 13 Jun 2022, 13:38
Is 0ffffffff the max mem in Fasm32?
|
|||
13 Jun 2022, 13:38 |
|
|
Fastestcodes 13 Jun 2022, 14:54
Thx! 1408MB works, 058000000h on this compu. Xp32 sp3. Unfortunatelly 32 8k picture 1GB, 1 sec video with 32fps.
|
|||
|
13 Jun 2022, 14:54 |
|
|
macomics 13 Jun 2022, 16:06
In the Windows boot parameters in the "BOOT.INI" file, copy the current system boot line and add the " /3GB" (without quotes) parameter to the first one.
After the reboot, the applications will have 1 GB more available addresses. And if something goes wrong, it will be possible to boot with the old parameters from the second point. You will also have to recompile fasm by specifying the "large" key in the format string: Code: format PE console large |
|||
|
13 Jun 2022, 16:06 |
|
|
revolution 13 Jun 2022, 21:18
Note that with the /3GB switch you are still limited to a maximum contiguous allocation of 2GB. The other 1GB is in another place above 0x80000000.
Windows won't move the system blocks at 0x7ffxxxx or the loaded libraries below that, you have to work around them. |
|||
|
13 Jun 2022, 21:18 |
|
|
bitRAKE 14 Jun 2022, 04:19
What is your memory bandwidth? Maybe DDR2-3200 on this WinXP machine?
_________________ ¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup |
|||
|
14 Jun 2022, 04:19 |
|
|
Fastestcodes 14 Jun 2022, 07:40
This compu is FuSi Amilo Li1705. 1,2GHz 440MB ram.
Over 58000000h address i get: problem, needs to close. |
|||
|
14 Jun 2022, 07:40 |
|
|
I 15 Jun 2022, 01:55
Well there's AWE for large amounts of memory under 32-bit but having such low mem installed it's a moot point. It's not recommended for graphics by MS?, maybe I'll give it a try and see what happens just for fun although my programming skills aren't so good :/
If you only have 440MB RAM (odd number?) then you'll probably be paging out often which can slow things down a lot. Edit: Tried CreateDIBSection and DrawDIBDraw but seems MS made it incompatible because of virtual mem MEM_PHYSICAL flag? Otherwise just swapping out paging might have worked well. |
|||
|
15 Jun 2022, 01:55 |
|
|
comrade 19 Jun 2022, 07:11
macomics wrote: There was also a 3G key in the Windows boot parameters, which in 32-bit versions increased the memory space of user programs to 0BFFFFFFFh = 3Gb - 1 Interesting fact is that, on 64-bit Windows, running with /3G and a 32-bit program that is LARGEADDRESSAWARE, actually allots the full 4 gigabytes to the program's address space. If you're dealing with this much memory, on a modern system, then why not write a 64-bit native app, instead of worrying how to handle so much memory in a 32-bit program?[/url] |
|||
|
19 Jun 2022, 07:11 |
|
|
macomics 19 Jun 2022, 11:39
comrade wrote:
Fastestcodes wrote: Thx! 1408MB works, 058000000h on this compu. Xp32 sp3. Unfortunatelly 32 8k picture 1GB, 1 sec video with 32fps. |
|||
|
19 Jun 2022, 11:39 |
|
|
I 19 Jun 2022, 14:58
Tried OGL with AWE just for fun and that works! Well when I say works, it produces a result but since I'm not sure what I'm doing probably could be improved a lot. The pics are generated with background set and a green bar that's in a different position on each so appears to move upwards as each 8K pic is displayed. Window can be resized smaller for less than 8K displays while still using 8K pic or left at 8K but running off screen. Seems very CPU dependent with little difference to scaling seen.
Before AWE needed admin rights as well as memory rights but W10 seems to have dropped the admin part. So Over 12GB of memory used with 32-bit app, no large address aware. I don't have a 32-bit OS to try at this time but sure easier with 64-bit. Example of 100 8k RGBA bitmaps all in memory using 32-bit app.
|
||||||||||
|
19 Jun 2022, 14:58 |
|
|||||||||
|
AsmGuru62 19 Jun 2022, 16:43
Interesting story here.
When I started working on x64 using FASM (I have Windows 10) -- I decided to test how much memory (blocks between 200 and 500 bytes) I can allocate with HeapAlloc() until Win64 libraries will return NULL. So, I am sitting and looking at Task Manager and waiting for my INT3 instruction to come up when NULL is returned. It was fast growth up until 6Gb was allocated (maybe 10 seconds), then it got much slower until 8Gb and then around 9Gb -- it stopped growing, and not showing my INT3. Upon some debugging -- it turned out that every next call to HeapAlloc() was taking around 40 seconds or so, but not returning NULL. I guess it depends on some properties for a swap file (or maybe some secret "server" option in Windows itself). Maybe not everyone can get the same results as I did, but x64 will not provide crazy (way beyond what 32bit can do) amounts of memory for the application. Or, maybe it can, but with very slow execution times. Weird, isn't it? I thought x64 will be like ENTERPRISE computer experience. |
|||
|
19 Jun 2022, 16:43 |
|
|
revolution 19 Jun 2022, 16:56
Disable the swap file and it will be much faster.
It is no secret that running from disk only serves to provide awful performance. BTW: For many cases, running 64-bit code can be slower than 32-bit code. Depends upon the app of course, but don't automatically assume 64-bits is going to be "better".  |
|||
|
19 Jun 2022, 16:56 |
|
|
comrade 20 Jun 2022, 04:52
AsmGuru62 wrote: Interesting story here. Take a look at the Limits series by Mark Russinovich on his blog, about a decade old at this point. He goes into the limits of system commit, virtual memory address space, heap-allocated memory, etc. |
|||
|
20 Jun 2022, 04:52 |
|
|
Furs 20 Jun 2022, 13:05
revolution wrote: Disable the swap file and it will be much faster. |
|||
|
20 Jun 2022, 13:05 |
|
|
revolution 20 Jun 2022, 13:22
Sounds similar to those old "double-space" programs people would use in DOS to "double" the HDD size. Which really only compressed each file and assumed it would be able to average 2x space savings.
Often those were really faster, because I/O to/from the HDD was generally slower than the compressor/expander code. But that metric isn't so clear nowadays. I think swap files are things that need to be deprecated. Just install more RAM, or let the rogue programs fail, or preferably both. Don't hobble your entire system just to support some crappy code that can't manage its memory properly. I've seen code that just keeps using memory until it can't get more and only then starts to release older allocations. So for that code, a swap file is a terrible idea. The code just uses all RAM+swap and everything suffers. Much better to fail the allocation early and never have to page to disk. |
|||
|
20 Jun 2022, 13:22 |
|
|
Overclick 20 Jun 2022, 15:12
Quote:
Very funny. It's all about how rich you are to install more RAM and how important tasks you run. I don't want system shuts off my render or unsaved game or whatever else. I don't see any problems for SWAP especially for SSD or M2. SWAP works perfect until Windows 8 where MS started to clone mobile solutions to desktop and totally broken the SWAP. They fixed it years later at Win10 era as people says. |
|||
|
20 Jun 2022, 15:12 |
|
|
AsmGuru62 20 Jun 2022, 15:19
comrade
Спасибо, I will take a look. |
|||
|
20 Jun 2022, 15:19 |
|
|
DimonSoft 20 Jun 2022, 20:11
revolution wrote: I think swap files are things that need to be deprecated. Just install more RAM, or let the rogue programs fail, or preferably both. It’s not the rogue program that will fail. Since physical RAM has to be shared among all the processes running it’s more likely that some perfectly valid and well-behaving program will just fail to run since some rogue program has been run before. So, the rogue behaviour is then not punished by any means but normal programs are likely to suffer. In fact, swapping is more fair since a new program has better chances to run. The rogue program that doesn’t touch every single page allocated for it every now and then will get swapped out soon. And even if the rogue program touches its pages all the time, it is easy to find by watching running which program causes everything to slow down. |
|||
|
20 Jun 2022, 20:11 |
|
|
revolution 20 Jun 2022, 20:27
At a high level view a swap file is just more RAM. Aside from speed of access it is the same as adding more RAM as far as apps are concerned.
So It won't make anything fairer, or unfair, it just makes it look like you have more RAM. RAM that is really really slow. If your system is swapping horribly with 8GB-RAM+8GB-swap then you can instead go to 16GB+0GB and everything will still run exactly as before, but it will now be 10x faster, maybe 100x. Maybe 1000x faster with spinning HDDs. And the sad part is if you go to 16GB-RAM+8GB-swap then everything slows down again because greedy apps will just keep using up all they can get and force everyone to go to swap. And sometimes if you go to 8GB+0GB (i.e. delete your swap) you might find everything speeds up again. Those greedy apps are forced to run within the bounds of RAM. |
|||
|
20 Jun 2022, 20:27 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|