Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
I am not sure if I can post a question without code in Stack Overflow. This is a question about how the computer works.
I know it's not slow when watching a movie because the data in storage is copied to memory and used. However, because the storage processing speed is slow, is it not slower than a direct processor accessing and reading the storage? Or does another device act as a copy? I want to know the principle in detail.
The processor access addressable data: units of memory each one identified by an address.
Main memory is addressable: this allows the processor to read from "here" and write "there" and "there", exploiting the full capacity of the main memory.
Without memory, the processor could only use its internal units of storage (registers) but they are of limited size (around 2KiB for x86, but for general purpose registers it goes down to 128 bytes).
Caches are equivalent to memory for this discussion.
Disks are not addressable the same way memory is: this is due to historical reasons (small address space) and performance (reading randomly is worse than planning ahead even for SSD, also there are more commands than Read and Write and some can be executed in parallel).
So disks are either made to write data to main memory (DMA) or there is a fixed location where to write to send commands and a fixed location to repeatedly read from to fetch all the data (PIO).
This read location is small enough to fit into a CPU internal storage unit but once the CPU has the data it must "save" it somewhere for later processing and so this data would end up in memory anyway (PIO is waaaay slower than DMA).
Note that Non Volative Devices are considered a new form of storage, something in between main memory and disks (while main memory won't be phased out by NV devices, because we need scratch memory, disks may be if the NV technology can address the longevity and density problems without affecting performance).
They are addressable like main memory and thus the CPU could read directly from them.
Symbian OS based mobile phones worked this way: the OS executable files were stored in the flash ROM (which is an NV device) and read directly by the CPU without loading them (they were already loaded).
Also note that FWIW, video is played for humans which have a very slow sampling rate. We only need about 24 frames per second to consider a movie smooth, that is easy to sustain even from the network (though it depends on the resolution and format).
So the disk has all the time to serve the reads needed for the playback.
On the contrary, video conversion can be affected by the speed of the disk.
Also, videos are compressed so the CPU must modify the data (meaning it needs to overwrite it or store the result somewhere in main memory) to play the video unless there is a hardware device that can play compressed stream directly and the file format is just right.
In this case, storing the video on an NV device would allow a faster reproduction, without the CPU involved or any copy in memory.
However the speedup is not dramatic, we are shaving off the time needed to read from memory not the time needed to read from the storage device (which is still the dominant factor affecting speed).
That's mostly irrelevant for the frame rates involved when playing for humans.
Related
I have been trying to learn about how games were made on the old Atari-2600 when the maximum it could address was 8KB and it only had around 127 bytes of memory. I heard that games on the Atari used a technique called Bank Switching, which allows the 6507 (The CPU of the Atari-2600), to access more memory than 8KB. I read the Wikipedia article about it, but I didn't understand how this was accomplished or what it really did.
From what I can understand you basically swap the memory the cpu is using to allow it to access more memory, but how would you keep track of what parts memory you are using?
I read the Wikipedia page about it. I also tried searching for answers here on Stack Overflow but I got no results.
I'm running algorithms that consume a lot of memory. For that reason I'm using memory mapped files. The problem is that the memory is allocated faster than the memory manager is able to write data to disk - and ultimately the system is stalling because data allocation and paging are interferring each other. So I need to throttle the data processing when the memory manager is currently doing extensive paging.
I have already found out how to get if the disk is currently writing/in use, but I haven't found a way to see if it is due to paging.
So the question is if there is a way to find out if the disk/memory manager is paging - or if there is even a better way to do it.
I am studying about operating systems(Silberscatz, Galvin et al). My programming experiences are limited to occasional coding of exercise problems given in a programing text or an algorithm text. In other words I do not have a proper application programming or system programming experience. I think my below question is a result of a lack of experience of the above and hence a lack of context.
I am specifically studying IPC mechanisms. While reading about shared memory(SM) I couldn't imagine a real life scenario where processes communicate using SM. An inspection of processes attached to the same SM segment on my linux(ubuntu) machine(using 'ipcs' in a small shell script) is uploaded here
Most of the sharing by applications seem to be with the X deamon. From what I know , X is the process responsible for giving me my GUI. I infered that these applications(mostly applets which stay on my taskbar) share data with X about what needs to change in their appearances and displayed values. Is this a reasonable inference??
If so,
my question is, what is the difference between my applications communicating with 'X' via shared memory segments versus my applications invoking certain API's provided by 'X' and communicate to 'X' about the need to refresh their appearances?? BY difference I mean, why isn't the later approach used?
Isn't that how user processes and the kernel communicate? Application invokes a system call when it wants to, say read a file, communicating the name of the file and other related info via arguments of the system call?
Also could you provide me with examples of routinely used applications which make use of shared memory and message-passing for communication?
EDIT
I have made the question more clearer. I have formatted the edited part to be bold
First, since the X server is just another user space process, it cannot use the operating system's system call mechanism. Even when the communication is done through an API, if it is between user space processes, there will be some inter-process-communication (IPC) mechanism behind that API. Which might be shared memory, sockets, or others.
Typically shared memory is used when a lot of data is involved. Maybe there is a lot of data that multiple processes need to access, and it would be a waste of memory for each process to have its own copy. Or a lot of data needs to be communicated between processes, which would be slower if it were to be streamed, a byte at a time, through another IPC mechanism.
For graphics, it is not uncommon for a program to keep a buffer containing a pixel map of an image, a window, or even the whole screen that then needs to be regularly copied to the screen. Sometimes at a very high rate...30 times a second or more. I suspect this is why X uses shared memory when possible.
The difference is that with an API you as a developer might not have access to what is happening inside these functions, so memory would not necessarily be shared.
Shared Memory is mostly a specific region of memory to which both apps can write and read from. This off course requires that access to that memory is synchronized so things don't get corrupted.
Using somebody's API does not mean you are sharing memory with them, that process will just do what you asked and perhaps return the result of that operation to you, however that doesn't necessarily go via shared memory. Although it could, it depends, as always.
The preference for one over another I'd say depends on the specifications of the particular application and what it is doing and what it needs to share. I can imagine that a big dataset of some kind or another would be shared by shared memory, but passing a file name to another app might only need an API call. However largely dependent on requirements I'd say.
I dropped out of the CS program at my university... So, can someone who has a full understanding of Computer Science please tell me: what is the meaning of Dirty and Resident, as relates to Virtual Memory? And, for bonus points, what the heck is Virtual Memory anyway? I am using the Allocations/VM Tracker tool in Instruments to analyze an iOS app.
*Hint - try to explain as if you were talking to an 8-year old kid or a complete imbecile.
Thanks guys.
"Dirty memory" is memory which has been changed somehow - that's memory which the garbage collector has to look at, and then decide what to do with it. Depending on how you build your data structures, you could cause the garbage collector to mark a lot of memory as dirty, having each garbage collection cycle take longer than required. Keeping this number low means your program will run faster, and will be less likely to experience noticeable garbage collection pauses. For most people, this is not really a concern.
"Resident memory" is memory which is currently loaded into RAM - memory which is actually being used. While your application may require that a lot of different items be tracked in memory, it may only require a small subset be accessible at any point in time. Keeping this number low means your application has lower loading times, plays well with others, and reduces the risk you'll run out of memory and crash as your application is running. This is probably the number you should be paying attention to, most of the time.
"Virtual memory" is the total amount of data that your application is keeping track of at any point in time. This number is different from what is in active use (what's being used is marked as "Resident memory") - the system will keep data that's tracked but not used by your application somewhere other than actual memory. It might, for example, save it to disk.
WWDC 2013 - 410 Fixing Memory Issues Explains this nicely. Well worth a watch since it also explains some of the practical implications of dirty, resident and virtual memory.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I was looking for a book, text, post or something talking about iPhone optimization but I couldn't find anything except for Apple documentation.
I think it would be great to talk about which are the common steps you do when optimizing your apps performance. I'm now trying to improve my app memory usage and I've figured out it is really difficult when your app is complex.
How do you handle view creation and destruction? Are you doing it by yourself or do you delegate on iPhone navigation controller?
Do you use any trick to free some memory in your app?
To optimize the memory usage, avoid using auto-released objects.
If you don't need an object anymore, release it explicitly, so the memory will be reclaimed immediately.
Otherwise, the object will stay in the pool for an unknown time.
Note that this will optimize your application's memory usage, but not the performances.
Releasing explicitly objects may slow down your application.
You'll sometimes have to decide if you want a faster application, or an application that uses less memory.
Also try to use C code whenever possible. For instance, if you just need to store objects in an array, don't use a NSMutableArray unless you rely on a particular method.
If not, use 'id *' variable, and use malloc() and free().
Hope this helps a bit... : )
If you have a loop which might be executed many times over, it might be worth it to manually manage the NSAutoreleasePool in that case. More often than not you end up with a lot of auto-released objects (remember Foundation etc. generate auto-released objects, too) and waiting for your thread to end or control to return to the run loop could cause memory problems and slow your application. There is no guaranteed recipe for success here, so you might have to probe a bit.
One of the huge memory eaters are images, and everything that has to do with them. If you have a UITableView with hundreds of rows and each cell containing an image, you might not want to keep them all around in memory. You could keep a cache of those images in the file system and load the images as needed. Disk I/O might be relatively expensive, but if you watch the memory notifications closely and read ahead wisely, you'll hardly notice a performance impact.
Key techniques to remember when trying to reduce your app's memory usage are using the static analyzer (Cmd+Shift+A) and Instruments, especially the object allocation instrument.
One thing I try to force myself to do is avoiding instance variables whenever possible. They make your code harder to maintain and consume memory because they're usually not deallocated until their owner. Try to avoid unnecessary instance variables, or try to release them early if they can be recreated (from disk, for example).