For my understanding there are always two types of memory:
the working storage
the "disk space"
So when you have a 16 GB iPhone, does it have 16 GB of working storage? or 16 GB of "disk space"? Which "Memory" is Apple talking about in his Docs, when it comes to performance and memory management? It looks like the working storage, but I am not sure. Actually I thought the iPhone is a huge brick of working storage, since all that stuff is just a solid block of chip memory (no hard drive).
The iPhone has 16GB (or 8 or 4, depending on the model) of non-volatile flash memory that persists even when the power is turned off. It also has 128MB of volatile DRAM that gets lost when the power is turned off. The relative differences are:
Flash memory is cheap, DRAM is expensive
Flash memory is slow, DRAM is fast
Flash memory is non-volatile, DRAM is volatile
The flash memory is essentially like a hard drive, except it's a solid-state memory, not a rotating platter of magnetic dipoles.
Generally, in iPhone development, when you're talking about memory, you're talking about DRAM. DRAM is a more limited resource and more likely to run out, since it's very easy for an app do eat up megabytes by poor memory management. It's a lot harder to run out of flash memory, since doing so would involve writing very large files into the file system.
A simpler way of explaining it:
Every iPhone has 128 MB of RAM. Your application generally can't use more than ~22 MB of it, and it does not use a swapfile for RAM expansion.
The advertised storage capacities (4/8/16 GB) are "disk" space for the filesystem.
The flash memory that makes up most of the iPhone's advertized "memory" is a kind of hybrid between RAM and "disk space" in its most important characteristics:
Less expensive than RAM, more expensive than a harddisk
Sequential transfer rate is lower than RAM's, about the same as a harddisk's (though this really depends on the type and quality of flash memory)
Random access delay is higher than RAM's, but much lower than a harddisk's
The last point is the most important one from a programmer's point of view. All kinds of basic programming techniques and an incredible amount of effort hinges on the fact that compared to most other things that happen in a computer, random access to harddisk memory takes eons because it involves physical movements - and that's where most of your storage is.
This basically means that in an environment with flash memory instead of a harddisk, you can get away with a lot of shit that would absolutely kill an app operating with a harddisk. There aren't really any downsides except for the limited amount of storage. Of course, conversely, it may mean that an app ported from the iPhone to a PC may exhibit godawful performance. Then again, the PC's OS might hide this by caching HD accesses in the more plentiful RAM.
Related
I recently learned that GPU can do operations as CPU do, although there is tradeoff in the operation latency. Regardless the latency, can a GPU run an OS by its own?
Imagine a computer with no persistent storage, no user input, no networking and no sense of time/date. For this hypothetical computer, there's no way for anything in the real world (e.g. a user) to influence its behavior, and no way to tell if it has an OS or is merely showing a predetermined slide show.
In theory, if you can write an OS for this hypothetical computer, you wouldn't because there's no possible reason to bother. This describes a typical "GPU + video card memory" scenario (where a host OS running on the CPU is the only means of influencing the work done by the GPU).
Now imagine a "GPU" with various devices attached to it (some persistent storage, some networking, something for user input, a graphics card, ...) so that the "GPU" is able to manage (and abstract, and maybe even allow multiple programs to securely share) these devices. In this case, the "GPU" has become a central unit that does processing (a CPU!). It'll probably be a relatively awful CPU (with poor flow control and over-powered SIMD), but it's no longer a GPU.
Can we run OS in a gpu only device?
I don't know. If a tree falls in the woods, but nobody is around to hear it, does it make a sound?
I am researching TinyOS for a school assignment and read that the "core OS is 400 bytes", and another source saying "The footprint of TinyOS is 400 bytes" What exactly does this mean? Is it the actual space it occupies on harddrive?
How big ia a "traditional" OS such as windows?
The answers I have found of what "footprint" actually means is confusing too. Because it seems to mean both actual physical space and memory/disk space.
Just to explain a bit of background, the authors of TinyOS themselves have explained that TinyOS isn't really an operating system:
TinyOS has a component-based programming model, codified by the
nesC language, a dialect of C. TinyOS is not an OS in the traditional
sense; it is a programming framework for embedded systems and set of
components that enable building an application-specific OS into
each application. A typical application is about 15K in size, of which
the base OS is about 400 bytes; the largest application, a
database-like query system, is about 64K bytes.
TinyOS is a software build system designed to allow software engineers to more easily build software for really tiny devices (like this wireless sensor), which do not have a harddrive. Instead, the program is typically stored inside the microcontroller of the device - the device I linked to for example has 48k bytes of flash memory (small embedded devices like these often use flash memory to store their program). 48k of code isn't very much, so it's really important that when you're making software to load onto the device, it takes up as little space as possible.
So, the 'base footprint of 400 bytes' means that, on top of the code that you (the software engineer) write to do whatever your tiny device needs to do, the TinyOS framework (which supports and provides services for your code) only adds an extra 400 bytes (which is really amazing!) to your program code which will actually be loaded onto the device's flash memory. However, this isn't the only overhead - depending on the device, TinyOS may also include various different supporting drivers for whatever chips and components exist on that device.
See figure 6 in this paper for some examples of actual program sizes.
Because of this I have found that building the same application for different devices using TinyOS can yield very different results. For example if I build a really simple program for the MicaZ wireless sensor I get:
compiled NullAppC to build/micaz/main.exe
610 bytes in ROM
4 bytes in RAM
Which means that the total program code, plus the base OS (400 bytes) is 610 bytes (the program will also use 4 bytes of RAM). However if I build the same program for TelosB:
compiled NullAppC to build/telosb/main.exe
1328 bytes in ROM
6 bytes in RAM
1328 bytes! Clearly TelosB requires a lot more additional software, presumably because the components on the TelosB require more complicated additional driver software.
I want to know the feasibility of these things:
1) Is it possible to download 200MB audio files to our application?
2) How much RAM can be accessed from an iPhone app? What is the largest amount of RAM an app can expect to use?
Anyone's help in this regard is deeply appreciated.
Thanks to all,
Monish
1) Yes, although you might make users angry who are not on Wifi + fast DSL. Also you will need to handle interrupted downloads.
2) No, since ARM is a 32bit processor a maximum of 4GB RAM can be addressed. Anyhow, iDevices have a maximum of 512MB right now (iPad 2). Your application will get killed by iOS if your app takes about 75% or so of the available RAM which means in reality you shouldn't use more than, say, 80MB of RAM. And if you need to address 8GB then your design is totally flawed to begin with.
There are always ways to work with a lot less (e. g. either by using better algorithms and/or by caching to disk). On the disk, you are only limited by the available space left on the device. So if you have an iDevice with just 8GB you're naturally out of luck as the system itself and other apps/data are reducing the available space. Same if you're on a 64GB iDevice which is packed with movies. You will need to be able to work with the space that is available. You can, for example, try to "reserve" the necessary space by creating a file and making it as big as you need it (via a seek and a write) but be prepared for angry customers.
I am testing my app in two different devices. My app is relies heavily on images(allocating and deallocating). I know I have a leak but I am just curious why I observe this.
The behavior between the two devices is different. Device A crashes after 4 cycles of switching between views and Device B after 10 cycles, yet Device A has more free memory than Device B.
Device A: Device B:
Type iPhone 3G 16GB iPhone 3G 8GB
Capacity 14.64GB 7.08GB
Audio 5.32GB 1.18GB
Video 48.8GB -
Photos 267.3GB 46.8GB
Apps 1.08GB 505.5MB
Other 343.9MB 370.7MB
Free 7.60GB 5.0GB
Any insights why this is the case?
I am not sure if I understand this correctly, but the figures on the last row (7.6/5 GB) refer to available flash memory, not to the RAM. Therefore they say nothing about the expected performance of a memory-intensive application. Neither the amount of free RAM is exactly telling, because the system will start killing large applications when the memory is scarce and the amount of free memory will go up.
My iPhone app will download a large amount of data from a remote server. What is the maximum amount of data that an iPhone application can store? If you try to store too much data, what happens?
Like a computer, iPhone has RAM and hard disk space. The disk space is advertised on the box (8GB, 16GB, or 32GB). Apple does not advertise the amount of RAM, but the iPhone and iPhone 3G have 128MB and the 3GS has 256MB.
If you fill up memory, your app will receive a Memory Warning notification. If you don't free up enough memory, your app will be terminated.
If you fill up the disk, your app will probably receive disk full errors when you try to write more data.
See this excellent article on memory on the iPhone.
When you first buy an iPhone it will say 8GB, 16GB, 32 GB, or 64 GB on the package. Usually they use 3 GB for something that I don't really know what for. My iPhone 4S has 64 GB on the package but on the usage settings it says that I have 62 GB still a lot but I think that apple uses some GB for some kind of settings. I Hope this Helped :)