Is there anyone here that has tested the speed of the AWE memories? AWE is unpaged memory, that can't be shared between applications. So it cannot be used for graphics directly. But it can be used for other internal structures.

I have tested this a little, and unless I made a mistake, my findings is that it is extremely fast memory. I was hoping that someone could confirm or disconfirm this.

http://msdn.microsoft.com/en-us/l...esktop/aa366527%28v=vs.85%29.aspx

I also like to ask those of you that use Lunix, if it offers something equivalent.

AWE is not about performance. Its' purpose is to allow 32-bit programs access to memory above the 4GB maximum. It's a bit of a hack in order to allow 32-bit server software run with more memory... back in the day. If you're on a 64-bit machine, you shouldn't waste time with it.

These are not the droids you're looking for.

ChrisG0x20
AWE is not about performance.
.....
These are not the droids you're looking for.

Are you 100% sure about this? Have you tested it? Bcs my test indicates that we are talking about speeds that appear to be close to an order of magnitude faster, than using normal virtual memory. Working on many small items of a large dataset. If I didn't make some mistake. (It's pretty complex code). I was thinking it could come in handy for things like sorting a huge database of say triangles, or something.

My test was made using my own allocator, and the code to allocate the same items as one or the other was exactly the same, except for in one instance AWE was the "backbone" and in the other case normal Virtual alloc calls..

Now after your post, I suppose the drastic speedup of this parser, which creates a sorted database in memory from rawdata, may have come from the fact that the AWE memories never needs to be paged in. When initializing data, paging (and too many calls to virtualalloc) is accounting for most of the time spent for allocations. So after thinking about what you say, I would now say that in a situation where you need to initialize a huge database quickly, or often, then AWE should be at least considered. But that it likely wouldn't matter much for already cached memory.

But still, avoiding paging may also be useful for other things than initializations. Windows, at least Windows 7 x64 ultimate, pages very agressively, even when you have lots of memory. It reserves caches for files, not for code, it seem. And, it will page uncalled code and data from running applications, vry quicly even when it has 22 GIGA of unused memory. So it is not completely out of question, that it could in fact help avoid first touch operations of large datasets, if data is not reused, all the time. Using AWE, there will never be any memory paging, so all memory initializations will run at the speed of paged-in ram, which is often twice and sometimes even 3 or 4 times as fast as nonpaged ram. Now, after seing how Casey code, this maybe wouldn't be of much use. However, I'd much like to hear if anyone has any experience with it. Initializations are far more common in code then we often realize, is what I have discovered with my own code. And they are very costly. But well I am not used to code games...

I think it is at least worth considering, for spesial needs.

I'm pretty sure we don't want to disallow Windows to move our memory to pagefile. For users who don't have much memory it can make system very unresponsive or even unstable when they will be playing Handmade Hero.

I've not tried to benchmark this. I'd be very surprised to learn that AWE offers some performance benefit. One thing I am sure of, is that: you're correct about the NT kernel's aggressive paging. Like Darwin and Linux, NT is a server kernel first. Servers are constantly preparing themselves for the next big work load. That means: NT will keep as many physical pages free as possible to be used at a moment's notice.

If you're seeing a startup improvement I'm not totally surprised. I've seen game engine source code that periodically "touches" memory pages in order to try and keep pages hot. Mapping non-pageable memory in a driver or using AWE may avoid some issues. However, I agree with mmozeiko, if you prevent the kernel from operating normally you'll likely cause surprising consequences.

Have you published the results of your tests?

ChrisG0x20
I've not tried to benchmark this. I'd be very surprised to learn that AWE offers some performance benefit. One thing I am sure of, is that: you're correct about the NT kernel's aggressive paging. Like Darwin and Linux, NT is a server kernel first. Servers are constantly preparing themselves for the next big work load. That means: NT will keep as many physical pages free as possible to be used at a moment's notice.

Thank you for confirming this.

ChrisG0x20

If you're seeing a startup improvement I'm not totally surprised. I've seen game engine source code that periodically "touches" memory pages in order to try and keep pages hot.

:)

I think there is an API to help with this. SetProcessWorkingsetSize.

http://msdn.microsoft.com/en-us/l...esktop/ms686234%28v=vs.85%29.aspx

Not tested it properly, and I could not perceive any benefits with my code. But my code is a desktop application, not a game. I guess, it still incurs the first paging faults, and it will page when the app is not active. But for a game this may still be useful. idk.

ChrisG0x20

Mapping non-pageable memory in a driver or using AWE may avoid some issues. However, I agree with mmozeiko, if you prevent the kernel from operating normally you'll likely cause surprising consequences.

Yes. And the machine must also have considerable free ram. However those constraints are just like any other constraints, you work around them when you can or need to. IF it makes my program more responsive, then I would implement both, and test the machine, for when I could use the faster memories. And anyway, for a game in fullscreen, no other applications has less of a need to play ball with the rest of the OS? It could be an option.

ChrisG0x20

Have you published the results of your tests?

No. And its unlikely that I ever will, except for forum-exchanges like this.

I think if you tested it, you may come to cry :)
(Of what we lost by paging, in at least a certain set of circumstances).

What happend to me is that I was waiting for my server to boot up, as it prepares its records. And it took a long time. I perceive any waiting as long time. After changing to AWE it became instant. I mean, it was the feeling like Neo had just arrived. It took me by complete surprice. What before took like a maybe a minute. (I am unsure, because after I tested AWE for it, I never wanted to go back). However, I don't use it yet for any other tasks, as I have no other task that is big enough to make a difference.

A note of warning.

1. One cannot use these memories for Graphics, at least not directly.

2. You exhaust the memorymapped space this way. So while the memory is not paged, it is MAPPED. Such that 2 GIGA of unpaged ram, still eats into the range of available memory for other tasks.

3.
While the API says that remapping of memory blocks is fast, this is NOT so, for any sane definition of fast. If you switch blocks on a regular basis, like randomly, between two allocations, it will be dogslow. Only if the memory is organized so that you switch blocks rarely, will it be fast.

I tried both, and it was seeing this that turned me off from using AWE unless it's for very spesific operations. But it's still handy for those.

I don't use 64 bit yet. So the situation may be different there. For 32bit, you also need to be large pointer aware to make use of 4G of pure memory. But in a situation where all of these constrains may fit, it still worth considering.