How can I increase the mesh size of Comsol without increasing the memory of my system?
My system memory is 32 GB but I cannot simulate my problem because it needs a lot of memory.
How can I solve this problem?
Increase the mesh size. Increasing the mesh size cause decreasing the amount of memory that is needed for simulation. With increasing the mesh size you can solve huge problems with less memory. There is no other way for decreasing the amount of memory that you need for simulation; because you don't write any program and all things done automatically in COMSOL.
Related
I was reading a textbook which says that:
I'm totally lost, let's says:
n = 10 and p (required payload) = 800 bytes,
Does it mean that on the n = 9 which is 9th allocate request, P9 needs to be 792 bytes( suppose a single minimum allocate is 8 bytes)? Is my understanding correct?
As far as I understand the text, that allocator objective is to maximize Pi (sum of allocated memory at instant i). The peak utilization up to k is the ratio of the max of what could be allocated divided by the heap size at k.
Since there is a number of alloc and free at i, if the allocator is too basic and does not handle well the requests, it might be unable to answer another allocation request (for instance due to heap fragmentation, see exemple below).
A smart allocator might allow a maximal payload, at the expense of a slower response.
On the opposite you might have a fast allocator that might not be able to maximize the aggregate payload Pk after a number of requests.
To give a (simple) exemple, having that chain of requests
R1: alloc(1000)
R2: alloc(2000)
R3: alloc(1500)
R4: free(R1)
R5: free(R2)
R6: alloc(3000) => use space from R1+R2?
At R6 a basic allocator might not be able to understand it could reuse the space freed from R1 and R2, giving a low peak ratio, and the heap size is unnecessary higher than it should.
A smarter one might do, but at the likely expense of more CPU /resources.
The assumption behind this is that memory is a precious commodity, and we should try to avoid wasting it. If peak utilization is low, it means there's lots of memory reserved for the heap that isn't being used.
Peak utilization doesn't refer to any specific allocation. Pi is the total payloads from i successive requests. So it doesn't make sense to refer to a single p = 800 bytes in this analysis. maxi≤kPi is the peak of a graph of Pi from request 0 to k. Each allocation adds to the heap utilization, although frees will reduce it.
You need enough heap memory to satisfy the maximum amount of memory you'll ever allocate at simultaneously, but if you have much more then the rest is being wasted. Maximizing peak utilization means to try to find this sweet spot.
I am just curious about the array size of any programming language prefereably which can allow high size. after reading this link
What is the Maximum Size that an Array can hold?
is it that the Maximum array size is equivalent to RAM theoretically?, as RAM has to work on other application etc also. Or can we increase the virtual memory to accommodate any size of array.
Depend on ram size, and ram is constantly consumed and released back.so u can not figure how much for sure u can utilize. If theratically speak. If only array and ram then yes keeping every thing e.g os and programs out of question.
I'm reading a 2 MB word list with about 200 000 words into memory. To be able to index them I use a char * array. Since the words won't grow or shrink, is it better to read the whole file into one memory block and let the pointers point into that, rather than doing a malloc() for every word?
Contrary to some of the comments posted so far, if you are tight on memory, you should allocate a single large block. This is because each malloc() you do has some overhead which is more or less fixed. This overhead will be a few bytes per allocation, so many small allocations could have you losing half your memory to overhead.
If you care a lot about performance (speed), you should also use a single allocation. It will improve locality and cache utilization, and reduce the number of system calls during startup and also teardown.
We have a somewhat unusual c app in that it is a database of about 120 gigabytes, all of which is loaded into memory for maximum performance. The machine it runs on has about a quarter terabyte of memory, so there is no issue with memory availability. The database is read-only.
Currently we are doing all the memory allocation dynamically, which is quite slow, but it is only done once so it is not an issue in terms of time.
We were thinking about whether it would be faster, either in startup or in runtime performance, if we were to use global data structures instead of dynamic allocation. But it appears that Visual Studio limits global data structures to a meager 4gb, even if you set the linker heap commit and reserve size much larger.
Anyone know of a way around this?
One way to do this would be to have your database as a persistent memory mapped file and then use the query part of your database to access that instead of dynamically allocated structures. It could be worth a try, I don't think performance would suffer that much (but of course will be slower).
How many regions of memory are you allocating? (1 x 120GB) or (120 Billion x 1 byte) etc.
I believe the work done when dynamically allocating memory is proportional to the number of allocated regions rather than their size.
Depending on your data and usage (elaborate and we can be more specific), you can allocate a large block of heap memory (e.g. 120 GB) once then manage that yourself.
Startup performance: If you're thinking of switching from dynamic to static global allocation, then I'd assume that you know how much you're allocating at compile time and there is a fixed number of allocations performed at runtime. I'd consider reducing the number of allocations performed, the actual call to new is the real bottleneck, not the actual allocation itself.
Runtime performance: No, it wouldn't improve runtime performance. Data structures of that size are going to end up on the heap, and subsequently in cache as they are read. To improve performance at runtime you should be aiming to improve locality of data so that data required subsequent to some you've just used, will end up on the same cache line, and paced in cache with the data you just used.
Both of these techniques I've used to great effect, efficiently ordering voxel data in 'batches', reducing the locality of data in a tree structure and reducing the number of calls to new, greatly increased the performance of a realtime renderer I worked on in a previous position. We're talking ~40GB voxel structures, possibly streaming of disk. Worked for us :).
Have you conducted an actual benchmark of your "in memory" solution versus having a well indexed read only table set on the solid state drives? Depending upon the overall solution it's entirely possible that your extra effort yields only small improvements to the end user. I happen to be aware of at least one solution approaching a half a petabyte of storage where the access pattern is completely random with an end user response time of less than 10 seconds with all data on disk.
I have an array of point data (for particles) which constantly changes size. To adapt for the changing size, I use code like the following to create correctly sized buffers at about 60 hz.
free(points);
points = malloc(sizeof(point3D) * pointCount);
Is this acceptable or is there another way I could be doing this? Could this cause my app to slow down or cause memory thrashing? When I run it under instruments in the simulator it doesn't look particular bad, but I know simulator is different from device.
EDIT: At the time of writing, one could not test on device without a developer license. I did not have a license and could not profile on device.
Allocating memory is fast relative to some things and slow relative to others. The average Objective-C program does a lot more than 60 allocations per second. For allocations of a few million bytes, malloc+free should take less than a thousand of a second. Compared to arithmetic operations, that's slow. But compared to other things, it's fast.
Whether it's fast enough in your case is a question for testing. It's certainly possible to do 60 Hz memory allocations on the iPhone — the processor runs at 600 MHz.
This certainly does seem like a good candidate for reusing the memory, though. Keep track of the size of the pool and allocate more if you need more. Not allocating memory is always faster than allocating it.
Try starting with an estimated particle count and malloc-ing an array of that size. Then, if your particle count needs to increase, use realloc to re-size the existing buffer. That way, you minimize the amount of allocate/free operations that you are doing.
If you want to make sure that you don't waste memory, you can also keep a record of the last 100 (or so) particle counts. If the max particle count out of that set is less than (let's say) 75% of your current buffer size, then resize the buffer down to fit that smaller particle count.
I'll add another answer that's more direct to the point of the original question. Most of the answers prior to this one (including my own) are very likely premature optimizations.
I have iPhone apps that do many 1000's of mallocs and frees per second, and they don't even show up in a profile of the app.
So the answer to the original question is no.
You don't need to remalloc unless the number of particles increases (or you handled a memory warning in the interim). Just keep the last malloc'd size around for comparison.
As hotpaw2 mentioned, if you need to optimise you could perhaps do so by only allocating if you need more space i.e.:
particleCount = [particles count];
if (particleCount > allocatedParticleCount) {
if (vertices) {
free(vertices);
}
if (textures) {
free(textures);
}
vertices = malloc(sizeof(point3D) * 4 * particleCount);
textures = malloc(sizeof(point2D) * 4 * particleCount);
allocatedParticleCount = particleCount;
}
...having initialised allocatedParticleCount to 0 on instantiation of your object.
P.S. Don't forget to free your objects when your object is destroyed. Consider using an .mm file and use C++/Boost's shared_array for both vertices and textures. You would then not require the above free statements either.
In that case, you'd probably want to keep that memory around and just reassign it.