Samsung Turbo Speed Technology - Page 1
Forum section: electronics / general

author: Romain
author_rank: Regular Contributor
timestamp: August 04, 2016, 10:45:29 am
content: Hi guys, I found that video a few days ago and I thought you might be interested to see what Samsung is coming up with to speed-up your smartphones!My first reaction wasThen, the more I was listening to their "invention" the more I wanted toI may have missed a couple of things, but that's a quick summary of what I think is wrong with this video:1. Engineers are making apps smaller and more efficient. If they would have done their job properly in the first place, that wouldn't be necessary.2. More available RAM. The quantity of available RAM does not impact performance. The lack of available RAM does.3. Putting all apps icons in 1 page instead of multiple pages. Ok, they've re-arranged 10 bitmaps, and so what?4. Apps in background. Android is designed so that apps in background does not impact performances (as opposed to services, which do). They only stay in RAM (see point 2), it's only you run out of memory that you start killing apps, not before.5. Killing apps at Kernel level, and not only at service level. (First of all, have a close look at the drawing, you'll see the same apps over and over...). From an operating system POV, the Kernel is the only essential, incompressible engine to run a system. There is nothing to be killed in filesystem access, memory management and so on... Again, see point 2 in relation to RAM impact on performances.6. RAM needs decluttering. Unlike an (old school) hard drive, RAM (just like SSDs) does not need decluttering, nor defragmenting. Its Random Access (Memory) design makes it suitable for complete unorganized access without impacting the performances.I'm very curious to hear your thoughts on this!

author: wraper
author_rank: Unknown
timestamp: August 04, 2016, 10:57:38 am
content: Sounds like BS to justify weak hardware.

author: Marco
author_rank: Super Contributor
timestamp: August 04, 2016, 11:19:53 am
content: A 32 bit virtual memory space can easily fragment. Programs often want allocate large linear chunks, which you can run out of after a while. On the desktop 64 bit processing fixed this.I assume the Android Run Time has a software based virtual memory space for each app, so it can defragment the processor virtual memory space.

author: b_force
author_rank: Super Contributor
timestamp: August 04, 2016, 11:31:28 am
content: Quote from: Romain on August 04, 2016, 10:45:29 amWell, it seems that most software companies lost this.Even a freaking web browser or PDF viewer is nearly 100MB or up

author: suicidaleggroll
author_rank: Super Contributor
timestamp: August 04, 2016, 04:03:40 pm
content: Quote from: Romain on August 04, 2016, 10:45:29 amIncorrect on both fronts. Random access issignificantlyslower than sequential access, same with SSDs, and both of them can definitely become fragmented because most memory and file access is designed to work with contiguous blocks. Just a couple of weeks ago I had an embedded system with 1 GB of RAM that was throwing a fit because the disk cache was thrashing the RAM to the point that after a few hours it could no longer allocate a 32kB contiguous block in RAM and would shut down my acquisition process, despite having over 400 MB "available".

author: Romain
author_rank: Regular Contributor
timestamp: August 04, 2016, 04:56:57 pm
content: Good to know! But as stated by Samsung, apps allocate big chunks of memory, so on a freshly booted system, these are contiguous. When apps are closed, these chunks are freed, and available for reallocation (as chunks).Ultimately I agree with you, that over days and days of opening and closing apps, the memory will tend to clutter. But doesn't the linux kernel already handle memory defragmenting?Additionally : what can Samsung do in user space about ram allocation?Sent from my ASUS_Z00AD using Tapatalk

author: daqq
author_rank: Super Contributor
timestamp: August 04, 2016, 05:52:50 pm
content: So it's not exactly technology, it's more along the lines of "We actually told our software guys to give a damn about resource usage".

author: Marco
author_rank: Super Contributor
timestamp: August 04, 2016, 05:57:59 pm
content: Quote from: Romain on August 04, 2016, 04:56:57 pmBecause all of the memory allocation is under control of the runtime and the apps don't have access to raw pointers the runtime can change a base addresses and "move" data without the program noticing, next time it uses it it will point to the "moved" data.

author: suicidaleggroll
author_rank: Super Contributor
timestamp: August 04, 2016, 05:59:52 pm
content: Quote from: Romain on August 04, 2016, 04:56:57 pmIt tries, and generally does a decent job, but how you write your program can make its life significantly easierQuote from: Romain on August 04, 2016, 04:56:57 pmWell they can fix thrashing problems in any programs they write, but I don't think they could write any services that clean up the memory used byotherprograms from userspace. But I have no experience with Android so I'm not sure if there's some additional layering or abstraction taking place there.

author: Romain
author_rank: Regular Contributor
timestamp: August 04, 2016, 06:10:45 pm
content: Plus, Samsung's proposal only concerns their own apps. Who is going to address third-party inefficient apps?Of course, the "if you're not happy then don't use it" argument won't work here, as we're talking about the Web giants. As an example, here are the RAM usages on my Zenfone2 with 4GB:Facebook: 150MBMessenger: 108MBSkype: 112MBHangout: 130MBTapatalk: 76MBSo that's 500MB just for receiving notifications. Welcome to 2016!Sent from my ASUS_Z00AD using Tapatalk

author: madires
author_rank: Super Contributor
timestamp: August 04, 2016, 06:22:07 pm
content: Quote from: Marco on August 04, 2016, 11:19:53 amThat problem was fixed long time ago by the MMU, not by 64 bit CPUs or OSs.

author: Marco
author_rank: Super Contributor
timestamp: August 04, 2016, 06:33:50 pm
content: That would be true if not for bad programmers, they fragment the memory within their own address space and with compiled languages there's often nothing the MMU or kernel can do about it because they have no clue how the program is accessing its own address space (unlike with a semi-interpreted GC language).

author: Jeroen3
author_rank: Super Contributor
timestamp: August 04, 2016, 06:37:00 pm
content: Freeram is ram you've paid too much for.The memory management layer prevents fragmentation and applies address space layout randomization to prevent buffer overflow attacks and sorts.Fragmentation is not an issues, unless all your apps require consolidated 1 GB blocks. In which case you should review the apps.Apps use more memory because of the graphics. If they'd just stop increasing the amount of pixels they won't need to build an 8 GB ram smartphone.To make a faster phone, just add faster flash. The reason the iPhone 6 is fast is has the fastest flash on the market.Flash can also be used to temporarily store running apps that you don't need for a while (eg: during a game). It's called swapping, and it exists for ages.Faster flash also makes it possible to load the graphics faster and store your precious facebook ads and such when they're out of view. But is doesn't need to when there is free ram. Or ram that can be claimed, by swapping another background app.

author: madires
author_rank: Super Contributor
timestamp: August 04, 2016, 07:02:29 pm
content: Quote from: Marco on August 04, 2016, 06:33:50 pmBut that isn't fixed by 64 bit CPUs/OSs either, unless we got more than a few GB RAM in our PC or mobile phone. A bad programmer with his own memory management can't get blocks with several GBytes from the OS if there's no RAM (including any slow virtual RAM) left. In this case a 32 bit system would have the benefit that the app can't get more then 4GB (I'm hinting at PAE)

author: Marco
author_rank: Super Contributor
timestamp: August 04, 2016, 08:08:14 pm
content: You have to work hard to fragment to the point of uselessness in a 64 bit memory space, that would take some dedicated incompetence.

author: System Error Message
author_rank: Frequent Contributor
timestamp: August 04, 2016, 11:32:02 pm
content: Quote from: Romain on August 04, 2016, 10:45:29 amI've been doing (1) for years already and my apps work smoothly on ARM A9 at very low clocks.RAM cannot be fragmented/defragmented. Storage isnt exactly like what you think it is. Some systems thrive on fragmantation such as SunOS and their ZFS file system which is meant to be a multi user, multi application OS. The storage would be slower than defragmented but when you put it in its optimal use case with multiple users or apps at the same time it becomes much faster. RAM however is managed by a controller and OS nowadays. Theres no need to arrange things in RAM as every address in RAM is a fixed space. If the CPU is 32 bit than each RAM address space is 32 bits big and each sequence of addresses is unique to each program/data that trying to invade the space for more efficiency is disastrous because that fixed space method is to streamline transfer of data between RAM and CPU so the data can go straight into the pipeline without causing an error and making the CPU have to flush the pipeline. Both the program/OS and controller keeps track of the addresses. If you wanted to store a word for example each character gets its own address and they can be anywhere, no need to be next to each other. If its a single large data (like 256 bit value) than it gets a few addresses. If its an array it gets stored sequentially in RAM (this is where you can have insufficient memory) but nowadays people stick to small arrays and use lists and hash tables instead (also because everytime you search an array you have to start from the front). Perhaps fixing memory leaks would be better for samsung?Free ram isnt ram that you've paid too much for. Its a bit slower to have to clear out RAM that you use as cache when you need it but people dont notice the difference (i do). However asynchronous operations solves this. Free RAM also lets you store more 3D in it, this means more detailed graphics and better for mobile gaming.I dont use facebook mobile app as its a resource hog, it appears to me that they run their whole thing out of web code and browsers if just used for 1 website is a resource hog compared to a few because of the over head of extra layer (such as html or js parsed by a java/C program and processed and the java/C program compiled and managed by OS/hardware). All these multi platform app designers use web code and i've always criticised them for that as the apps are unresponsive, slow and a resource hog. Essentially this makes each web code app use a lot of memory. Bad coding and wrong data type choices also leads to high RAM usage as well. All these social apps store the image in RAM and VRAM rather than flash (program cache) and VRAM, At the very least they could enforce a fixed format and quality for these images such as gif which would help and not to store content images (like posts) in RAM when not viewed.On architectures like ARM and MIPS, they are less forgiving than x86 to bad coders. There are many bad coders out there. Improving your code is a good way to make things run faster.When i first got my samsung galaxy s4 i installed CM and got rid of samsung bloatware and other bloatware apps. People were complaining of battery life at that time and i was getting a weeks worth of battery life out of my samsung galaxy s4.Instead of trying to improve software improving both hardware and software at the same time is better. Just like windows 8 and above utilising SSE instruction set to make their OS much faster and boot faster. Stop using methods used on x86 on these platforms as they expose inefficient and bad coding quite easily.I thought samsung turbo speed technology was some sort of improvement in their flash technology or clocks (like better RAM speeds).

author: suicidaleggroll
author_rank: Super Contributor
timestamp: August 05, 2016, 02:24:15 am
content: Quote from: System Error Message on August 04, 2016, 11:32:02 pmcat /proc/buddyinfoRAM can and does get fragmented. My recent experience with page allocation failures due to memory fragmentation was due to over-zealous disk caching and the system's default vm.min_free_kbytes not leaving enough in reserve for the MMU to defragment it.