[Interest] memory fragmentation?

[Alex Malyushytskyy]

> That happens quite often. For example, Intel's compiler for 32-bit is a 32-bit
> application. When linking a moderately-sized library (like QtGui) with link-
> time optimisation, it requires more than 3 GB of working set. That means the
> process never finishes.

Yes, but it still work if you remove link time optimization.
This means that such functionality is not designed to work with
limited resources available and has to be redesigned.
Report a bug :)

In case of Intel compiler it might sufficient to they had at least to
stop the process when they found they hit limitation of the file size
for such conditions.
By the way " never finishes" might be result of memory management (
multiple re-loading of the same data into memory to do optimization )
and could actually finish at one point  and you just did not have
enough patience :). In this case they could control memory allocation,
but do optimization with all conditions is impractically long.

> In any case, if the application needs memory and can't get it, what do you
> suggest it do?

It depends on the exact problem you are facing.

If you say that you need all this memory at the same time nothing you can do
besides trying to find this as early as possible or search for the
ways to change your application so it does not need that much memory.

In practice you can always limit application to use less memory.  It
comes with cost, so normally you are trying to avoid this.

For example for application on the devices with limited resources you
may allow application to open only one dialog/widget at a time,
closing another if user executes another memory consuming feature,
which otherwise would not fit memory.
If you want to display 10 GB  data in table, you are not trying to
load it into memory and put into QTableWidget,
You load some ranges from the hardrive as required and display the
portion of the data only.

Another example: insufficient ram is completely normal situation for
finite element analysis.
FEM code can compute code which fits into the RAM, but it can also
compute something many times larger.
Intermediate results can be stored on the hard drive.
To make it work reasonably fast you need to write your own memory
management routines,
cause even in case if it would fit workspace and system could do it for you,
you knows much more about the order you might need the data, so you
can do it much more efficient.
In fact I remember doing this on MSDOS  when total size of the problem
was over 20 times memory available.

Now some codes are practical or considered to be practical only to run
into the memory, then
you should notify user that this problem with this version of the code
you can't run on this computer as early as possible.
Report bug Intel !
For example imagine finite element code running computation for 2
weeks, then stop, cause user opened dialog in the GUI , just to watch
some results.
You have to do everything possible to avoid this.

To avoid this -  you need to control memory handling yourself.
You can find how much system memory can provide,
control how memory is allocated,
provide and invoke your garbage collector to compress or free memory if needed.

It does not make sense to do for most applications,
but if it is a concern you do it.

Cheers,

Alex


On Mon, Aug 20, 2012 at 4:20 PM, Thiago Macieira
<thiago.macieira at intel.com> wrote:
> On segunda-feira, 20 de agosto de 2012 15.27.53, Alex Malyushytskyy wrote:
>> Crashing or even exiting due to insufficient memory in the middle of
>> long term task is not a choice.
>
> That happens quite often. For example, Intel's compiler for 32-bit is a 32-bit
> application. When linking a moderately-sized library (like QtGui) with link-
> time optimisation, it requires more than 3 GB of working set. That means the
> process never finishes.
>
> An application that requires 3 GB of working set simply cannot be 32-bit.
>
> In any case, if the application needs memory and can't get it, what do you
> suggest it do?
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>      Intel Sweden AB - Registration Number: 556189-6027
>      Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
>
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>