XP64 .NET Framework memory/address space story?

Discussion in 'Windows 64bit' started by Marcos Stefanakopolus, May 24, 2005.

  1. Ok, so what's the real story when it comes to writing .NET Framework-based
    (e.g. WinForms) apps on XP64 on machines with more than 4GB of RAM? In
    particular, say, large scientific simulation/visualization apps? I read
    different things here and there, but most of them sound like they were
    written by someone in marketing and don't tell me a lot that will really
    help me.

    This particular simulation (high-resolution plate tectonics) quickly gets
    into exponential-notation numbers of objects that need to be dealt with. As
    such, even on a machine with 16GB of physical RAM, doing the math tells me
    I'll have to be very, very careful with memory. This is an app where I can
    trade RAM for resolution in the simulation, but as I need as much resolution
    as I can get, every byte counts. So, I am expecting to write this app in
    "unsafe" mode, with my objects carefully laid out and packed as
    StructLayoutAttribute(Sequential) so I can avoid as much of the allocation
    and management overhead of the .NET framework as possible.

    With all that in mind, on XP64, I need answers to questions such as:

    * how much address space does a WinForms app get, really?
    * are there ways to have Windows give your app more space than that? In my
    example, for instance, let Windows use whatever it needs for its own
    purposes, but give the entire rest of the 16GB to my application?
    * will I be better off writing most of the simulation (gasp) unmanaged and
    just doing the UI in WinForms, even at the cost of added interop complexity,
    in order to maximize memory?

    I need reliable answers to these questions not only I can make appropriate
    choices when building the machine to run this thing on and designing the app
    itself, but also so I can determine before even starting whether I can get
    the resolution I need on today's high-end commodity hardware.

    Thanks very much to anyone who can help me out with these questions, or can
    point me to _trustworthy_ technical information that will help me figure it
    out for myself.

    --
    I may not always have the best answers, but at least I'm not posting
    questions in the wrong newsgroups...
     
    Marcos Stefanakopolus, May 24, 2005
    #1
    1. Advertising

  2. Marcos --
    .NET is, currently, a 32-bit application. Therefore, it runs under WOW64.
    Under WOW64, applications that are compiled with the /LARGEMEMORYAWARE switch
    of vc++ should be able to use a full 4GB of virtual memory address space per
    process without any additional flags.

    --
    Charlie.

    Marcos Stefanakopolus wrote:
    > Ok, so what's the real story when it comes to writing .NET
    > Framework-based (e.g. WinForms) apps on XP64 on machines with more
    > than 4GB of RAM? In particular, say, large scientific
    > simulation/visualization apps? I read different things here and
    > there, but most of them sound like they were written by someone in
    > marketing and don't tell me a lot that will really help me.
    >
    > This particular simulation (high-resolution plate tectonics) quickly
    > gets into exponential-notation numbers of objects that need to be
    > dealt with. As such, even on a machine with 16GB of physical RAM,
    > doing the math tells me I'll have to be very, very careful with
    > memory. This is an app where I can trade RAM for resolution in the
    > simulation, but as I need as much resolution as I can get, every byte
    > counts. So, I am expecting to write this app in "unsafe" mode, with
    > my objects carefully laid out and packed as
    > StructLayoutAttribute(Sequential) so I can avoid as much of the
    > allocation and management overhead of the .NET framework as possible.
    > With all that in mind, on XP64, I need answers to questions such as:
    >
    > * how much address space does a WinForms app get, really?
    > * are there ways to have Windows give your app more space than that? In my
    > example, for instance, let Windows use whatever it needs for
    > its own purposes, but give the entire rest of the 16GB to my
    > application? * will I be better off writing most of the simulation
    > (gasp) unmanaged and just doing the UI in WinForms, even at the cost
    > of added interop complexity, in order to maximize memory?
    >
    > I need reliable answers to these questions not only I can make
    > appropriate choices when building the machine to run this thing on
    > and designing the app itself, but also so I can determine before even
    > starting whether I can get the resolution I need on today's high-end
    > commodity hardware.
    > Thanks very much to anyone who can help me out with these questions,
    > or can point me to _trustworthy_ technical information that will help
    > me figure it out for myself.
     
    Charlie Russel - MVP, May 24, 2005
    #2
    1. Advertising

  3. Marcos Stefanakopolus

    James Park Guest

    I believe .NET apps can run natively as 32-bit or 64-bit, depending on the
    platform being run on and the compiler switch being used. /platform:anycpu
    (the default) will use one or the other (I think based on the OS), and
    /platform:x86 and /platform:x64 will force 32-bit (which can then be WOW'd)
    and 64-bit respectively. I put together a .NET Windows Forms app that used a
    32-bit WMP control and had to force /platform:x86 to get it to work (since
    you can't mix 64-bit and 32-bit that way).

    "Charlie Russel - MVP" <> wrote in message
    news:...
    > Marcos --
    > .NET is, currently, a 32-bit application. Therefore, it runs under
    > WOW64. Under WOW64, applications that are compiled with the
    > /LARGEMEMORYAWARE switch of vc++ should be able to use a full 4GB of
    > virtual memory address space per process without any additional flags.
    >
    > --
    > Charlie.
     
    James Park, May 24, 2005
    #3
  4. Marcos Stefanakopolus

    NoNoBadDog! Guest

    Isn't .NET Framework 2.0 Beta for x86-64 a 64 bit codebase? If not, then
    why is it available in two versions, one for 32 bit and one for 64 bit?

    Bobby

    "Charlie Russel - MVP" <> wrote in message
    news:...
    > Marcos --
    > .NET is, currently, a 32-bit application. Therefore, it runs under
    > WOW64. Under WOW64, applications that are compiled with the
    > /LARGEMEMORYAWARE switch of vc++ should be able to use a full 4GB of
    > virtual memory address space per process without any additional flags.
    >
    > --
    > Charlie.
    >
    > Marcos Stefanakopolus wrote:
    >> Ok, so what's the real story when it comes to writing .NET
    >> Framework-based (e.g. WinForms) apps on XP64 on machines with more
    >> than 4GB of RAM? In particular, say, large scientific
    >> simulation/visualization apps? I read different things here and
    >> there, but most of them sound like they were written by someone in
    >> marketing and don't tell me a lot that will really help me.
    >>
    >> This particular simulation (high-resolution plate tectonics) quickly
    >> gets into exponential-notation numbers of objects that need to be
    >> dealt with. As such, even on a machine with 16GB of physical RAM,
    >> doing the math tells me I'll have to be very, very careful with
    >> memory. This is an app where I can trade RAM for resolution in the
    >> simulation, but as I need as much resolution as I can get, every byte
    >> counts. So, I am expecting to write this app in "unsafe" mode, with
    >> my objects carefully laid out and packed as
    >> StructLayoutAttribute(Sequential) so I can avoid as much of the
    >> allocation and management overhead of the .NET framework as possible.
    >> With all that in mind, on XP64, I need answers to questions such as:
    >>
    >> * how much address space does a WinForms app get, really?
    >> * are there ways to have Windows give your app more space than that? In
    >> my example, for instance, let Windows use whatever it needs for
    >> its own purposes, but give the entire rest of the 16GB to my
    >> application? * will I be better off writing most of the simulation
    >> (gasp) unmanaged and just doing the UI in WinForms, even at the cost
    >> of added interop complexity, in order to maximize memory?
    >>
    >> I need reliable answers to these questions not only I can make
    >> appropriate choices when building the machine to run this thing on
    >> and designing the app itself, but also so I can determine before even
    >> starting whether I can get the resolution I need on today's high-end
    >> commodity hardware.
    >> Thanks very much to anyone who can help me out with these questions,
    >> or can point me to _trustworthy_ technical information that will help
    >> me figure it out for myself.

    >
    >
     
    NoNoBadDog!, May 24, 2005
    #4
  5. yes, .NET Framework has a 64 bit version. .NET 1.1, which is most of what is
    out there right now, is 32-bit.

    --
    Charlie.

    NoNoBadDog! wrote:
    > Isn't .NET Framework 2.0 Beta for x86-64 a 64 bit codebase? If not,
    > then why is it available in two versions, one for 32 bit and one for
    > 64 bit?
    > Bobby
    >
    > "Charlie Russel - MVP" <> wrote in
    > message news:...
    >> Marcos --
    >> .NET is, currently, a 32-bit application. Therefore, it runs under
    >> WOW64. Under WOW64, applications that are compiled with the
    >> /LARGEMEMORYAWARE switch of vc++ should be able to use a full 4GB of
    >> virtual memory address space per process without any additional
    >> flags. --
    >> Charlie.
    >>
    >> Marcos Stefanakopolus wrote:
    >>> Ok, so what's the real story when it comes to writing .NET
    >>> Framework-based (e.g. WinForms) apps on XP64 on machines with more
    >>> than 4GB of RAM? In particular, say, large scientific
    >>> simulation/visualization apps? I read different things here and
    >>> there, but most of them sound like they were written by someone in
    >>> marketing and don't tell me a lot that will really help me.
    >>>
    >>> This particular simulation (high-resolution plate tectonics) quickly
    >>> gets into exponential-notation numbers of objects that need to be
    >>> dealt with. As such, even on a machine with 16GB of physical RAM,
    >>> doing the math tells me I'll have to be very, very careful with
    >>> memory. This is an app where I can trade RAM for resolution in the
    >>> simulation, but as I need as much resolution as I can get, every
    >>> byte counts. So, I am expecting to write this app in "unsafe"
    >>> mode, with my objects carefully laid out and packed as
    >>> StructLayoutAttribute(Sequential) so I can avoid as much of the
    >>> allocation and management overhead of the .NET framework as
    >>> possible. With all that in mind, on XP64, I need answers to
    >>> questions such as: * how much address space does a WinForms app get,
    >>> really?
    >>> * are there ways to have Windows give your app more space than
    >>> that? In my example, for instance, let Windows use whatever it
    >>> needs for its own purposes, but give the entire rest of the 16GB to my
    >>> application? * will I be better off writing most of the simulation
    >>> (gasp) unmanaged and just doing the UI in WinForms, even at the cost
    >>> of added interop complexity, in order to maximize memory?
    >>>
    >>> I need reliable answers to these questions not only I can make
    >>> appropriate choices when building the machine to run this thing on
    >>> and designing the app itself, but also so I can determine before
    >>> even starting whether I can get the resolution I need on today's
    >>> high-end commodity hardware.
    >>> Thanks very much to anyone who can help me out with these questions,
    >>> or can point me to _trustworthy_ technical information that will
    >>> help me figure it out for myself.
     
    Charlie Russel - MVP, May 25, 2005
    #5
  6. I don't believe there is an x64 version of 1.1, but I could be wrong. I know
    when I was writing the Deployment Scenarios whitepaper for Microsoft before
    x64 shipped that one of the apps I discussed was an international .NET app
    that was recycling every 5 minutes at the worst times. Moving it to run under
    WOW64 gave them essentially zero recycles. But it was still 32-bit and still
    limited by that 4GB of virtual memory address space. However, the magic
    number for them was somewhere just over 3GB to give the app enough headroom
    to work correctly.

    --
    Charlie.

    James Park wrote:
    > I believe .NET apps can run natively as 32-bit or 64-bit, depending
    > on the platform being run on and the compiler switch being used.
    > /platform:anycpu (the default) will use one or the other (I think
    > based on the OS), and /platform:x86 and /platform:x64 will force
    > 32-bit (which can then be WOW'd) and 64-bit respectively. I put
    > together a .NET Windows Forms app that used a 32-bit WMP control and
    > had to force /platform:x86 to get it to work (since you can't mix
    > 64-bit and 32-bit that way).
    > "Charlie Russel - MVP" <> wrote in
    > message news:...
    >> Marcos --
    >> .NET is, currently, a 32-bit application. Therefore, it runs under
    >> WOW64. Under WOW64, applications that are compiled with the
    >> /LARGEMEMORYAWARE switch of vc++ should be able to use a full 4GB of
    >> virtual memory address space per process without any additional
    >> flags. --
    >> Charlie.
     
    Charlie Russel - MVP, May 25, 2005
    #6
  7. Marcos Stefanakopolus

    James Park Guest

    Hehe, I'm living in my own little .NET 2.0 world and assumed there'd be an
    x64 version of 1.1 since vs2003 can build x64 apps.

    "Charlie Russel - MVP" <> wrote in message
    news:...
    >I don't believe there is an x64 version of 1.1, but I could be wrong. I
    >know when I was writing the Deployment Scenarios whitepaper for Microsoft
    >before x64 shipped that one of the apps I discussed was an international
    >.NET app that was recycling every 5 minutes at the worst times. Moving it
    >to run under WOW64 gave them essentially zero recycles. But it was still
    >32-bit and still limited by that 4GB of virtual memory address space.
    >However, the magic number for them was somewhere just over 3GB to give the
    >app enough headroom to work correctly.
    >
    > --
    > Charlie.
     
    James Park, May 25, 2005
    #7
  8. Marcos Stefanakopolus

    Jon Grieve Guest

    Can I check my understanding is correct here... when VS2005 is out, and
    apps are created for the .NET 2.0 framework, will we need to create
    specific 32- and 64-bit version of our apps, or will the apps just run
    on whatever framework is available (i.e. they run as 64-bit on x64 Windows)?

    I've been a developer for many, many years and I realise that's quite a
    dumb question. ;) I've not looked *too* closely at VS2005 yet, so I'm
    sure this would probably be quite obvious to me if I had.

    Jon




    Charlie Russel - MVP wrote:
    > Marcos --
    > .NET is, currently, a 32-bit application. Therefore, it runs under WOW64.
    > Under WOW64, applications that are compiled with the /LARGEMEMORYAWARE switch
    > of vc++ should be able to use a full 4GB of virtual memory address space per
    > process without any additional flags.
    >
     
    Jon Grieve, May 25, 2005
    #8
  9. In Visual Studio 2005 / .NET 2.0, there will be four platform options: x86,
    x64, IA64, and anycpu. You can target a specific architecture, or use
    anycpu which should run on all architectures.

    - x86 builds will run on 32-Bit Windows, or Windows x64 (as a 32-bit
    application) even if a 64-bit .NET 2.0 Framework is installed (when you
    install the 64-bit .NET Framework 2.0 in Windows x64, the 32-bit version
    also installs).

    - x64 builds will only run on Windows x64 Operating Systems

    - IA64 builds will only run on the Windows IA64 Platform (Itanium)

    - anycpu will run on any cpu ;).

    I wrote an article titled, "Windows x64 and the Microsoft .NET Framework:
    32-bit or 64-bit?" on Extended64.com, available here:
    http://www.extended64.com/Article7.x64

    --
    Ryan Hoffman
    Extended64.com - http://www.extended64.com

    Windows x64 Support Forums: http://www.extended64.com/Forums/
    Extended64.com's Windows x64 Blogs: http://www.extended64.com/Blogs/
    "Jon Grieve" <jgrieve@southdown-co-uk> wrote in message
    news:...
    >
    > Can I check my understanding is correct here... when VS2005 is out, and
    > apps are created for the .NET 2.0 framework, will we need to create
    > specific 32- and 64-bit version of our apps, or will the apps just run on
    > whatever framework is available (i.e. they run as 64-bit on x64 Windows)?
    >
    > I've been a developer for many, many years and I realise that's quite a
    > dumb question. ;) I've not looked *too* closely at VS2005 yet, so I'm
    > sure this would probably be quite obvious to me if I had.
    >
    > Jon
    >
    >
    >
    >
    > Charlie Russel - MVP wrote:
    >> Marcos --
    >> .NET is, currently, a 32-bit application. Therefore, it runs under
    >> WOW64. Under WOW64, applications that are compiled with the
    >> /LARGEMEMORYAWARE switch of vc++ should be able to use a full 4GB of
    >> virtual memory address space per process without any additional flags.
    >>
     
    Ryan Hoffman [Extended64.com], May 25, 2005
    #9
  10. Marcos Stefanakopolus

    Jon Grieve Guest

    Ryan,

    Wow -- great article! Thanks!

    Jon






    Ryan Hoffman [Extended64.com] wrote:
    > In Visual Studio 2005 / .NET 2.0, there will be four platform options: x86,
    > x64, IA64, and anycpu. You can target a specific architecture, or use
    > anycpu which should run on all architectures.
    >
    > - x86 builds will run on 32-Bit Windows, or Windows x64 (as a 32-bit
    > application) even if a 64-bit .NET 2.0 Framework is installed (when you
    > install the 64-bit .NET Framework 2.0 in Windows x64, the 32-bit version
    > also installs).
    >
    > - x64 builds will only run on Windows x64 Operating Systems
    >
    > - IA64 builds will only run on the Windows IA64 Platform (Itanium)
    >
    > - anycpu will run on any cpu ;).
    >
    > I wrote an article titled, "Windows x64 and the Microsoft .NET Framework:
    > 32-bit or 64-bit?" on Extended64.com, available here:
    > http://www.extended64.com/Article7.x64
    >
     
    Jon Grieve, May 27, 2005
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mark Test

    Newsweek Story just that a Story

    Mark Test, May 14, 2005, in forum: Digital Photography
    Replies:
    21
    Views:
    708
    Jack Linthicum
    May 22, 2005
  2. Alex Vinokur
    Replies:
    1
    Views:
    1,133
  3. John Yung
    Replies:
    6
    Views:
    1,565
    John Yung
    Dec 30, 2005
  4. kena
    Replies:
    0
    Views:
    518
  5. Ozark

    Installing Paint.net / .NET Framework 3.5

    Ozark, Dec 6, 2009, in forum: Computer Support
    Replies:
    2
    Views:
    1,384
    Ozark
    Dec 9, 2009
Loading...

Share This Page