Quickie#4 CM12.1 vs Exodus ROM: CPU/GPU

After Pure SQLite databases transactions performances, it is time to have a look at CPU/GPU pure performances (meaning benchmarking, not real-life ...)

CPU
RgbenchMM

both ROMs were tested on RgbenchMM (4 threads):

On this Benchmark, CM12.1 is slightly ahead in performances (this has no real-life impact though)

GPU: 2D
fps2D

For 2D graphics, i use fps2D, and old app that is quite great for the purpose (an keeping it helps looking back in the ages and see progression.

No, there is absolutely NO single difference regarding 2D performances. a 0.1 fps difference with a standard deviation of 10fps is not significant at all!

GPU: 3D
GPUbench

Looking at average fps performance on this benchmark shows less than 1 fps difference between the two ROMs. lowest and highest are much more variable (look at stdev!) and thus cannot be compared.

What about the score?

Looks like CM12.1 gets some higher scores here? Right, but mainly because the Benchmark didn't recognized the same screen resolution (although both are set to 320dpi [default]) ==> normalized scores are similar. This might need further investigations.

Conclusion
regarding CPU/GPU

• Contrary to the huge performance increase in SQLite (up to 900%!!) CPU/GPU performances are not better (even a little behind? not sure we can say that) on Exodus compared to CM12.1
• So after hours of benchmarking, i couldn't show Exodus superiority here. So for people wanting a pure CM experience there is no point switching to Exodus of Falcons (XT1032 at least.) to burst CPU/GPU Benchmarks.
• Nevertheless, those ROMs are pretty similar but Exodus features lots of things CM12.1 doesn't which is not something to throw out!
• Later we will try to see if various other points of comparison can (or not?) differenciate Exodus from CM12.1.
  But are we really searching overkill performances in Exodus on Falcon? I personally don't. CM12.1 is a great stable base that gave me all i wanted for a while (Features and performance wise).
  What i searched for in Exodus is not extra performances, but extra features (Pie, navigation bar customs, bottom right clear-recent, ...)

Quickie#3 CM12.1 vs Exodus ROM : SQLite performance

Having two devices with similar hardware helps a lot for "real-time" comparisons of different ROM at a given time. Here we are comparing CM12.1 (20151012 nightly) with Exodus ROM (based on 12.1 ... 20151012) regarding SQLite databases performances, this is not like a full ROM versus, simply a comparison on a very specific point.

The devices
Similar Hardware ? yes, and no...

The two devices are both XT1032, with pretty similar hardware, but with some differences regarding memory :

*	Device 1	Device 2
ROM	CM12.1	Exodus
eMMC	8GB Sandisk	16GB Toshiba
/data file system	F2FS	F2FS
DRAM	1024MB Samsung S4	1024MB Hynix S4

(does this adds a significant bias? hmmm maybe, but it won't explain the gigantic differences seen later)

Benchmarking
AndroBench 4.1

Here i am testing pure SQLite performances with AndroBench 4.1 on both devices using BFQ scheduler (default CM and Exodus I/O scheduler since quite a while)-results in Transactions Per Seconds (TPS)-

	Exodus-BFQ		CM12-BFQ
	average	stdev	average	stdev
SQLite Insert	1241,40	21,19	116,22	4,48
SQLite Update	632,82	12,41	107,78	2,82
SQLite Delete	952,57	16,57	118,21	5,81

Looks like there's quite a big difference... isn't it?
In day to day usage i don't feel much gap between those two ROMs, but this specific benchmark shows that Exodus had more in-depth optimizations regarding SQLite database operations

Discussing bias:

• Memory brand is different, your results are messed up: No, in fact other devices (aka Moto E 1st gen [XT1022, eMMC: Hynix, DRAM 1024MB Hynix S4, Snapdragon200] or MotoG 2d gen) show similar results on CM12.1 (or even lower for the MotoE). So even if the brand may have a little impact on performance, it won't explain the 10^1 between results.
• As Processing unit has a fairly big impact on I/O performances, both devices are featuring a Snapdragon 400 @1.2GHz, Interactive governor, MP decision enabled.
• Is choosing BFQ as scheduler impacts results? and why choosing it? BFQ is the default scheduler for both CM12.1 and Exodus, for this simple reason there is no point testing another in first-line. Plus it could be interesting to see if the optimizations have been directly applied to this specific scheduler or if they are more system-wide. On previous tests i couldn't show any difference in performance between BFQ and Fiops regarding SQLite Update or Delete operations.
• SQLite databases are not reflecting real-life performance though, so this only shows a very little part of everything -but should make benchmarks addicts happy ;-) -

Using a Samsung 2A travel adapter with adaptive fast charging with MotoG : How does it behave? part 2 : more data

Materials and Methods
Trying to keep things objective

See Part one for for the tools used and limitations inherent to the method used.
A few precisions :

• legend used in graphs:
  • Power-In (W) --> Power used by the samsung AC adapter
  • Power-Out (W) --> Approximated power delivered by the AC adapter
  • Out-disp (mA) --> Current displayed by Ampere App = Current received by the battery
  • Offset : +250mA (= Current used by the device idle, screen ON drain, wifi ON)
  • Offset (WifiOFF) : +160mA (= Current used by the device idle, screen ON drain, wifi OFF)
  • Out-real (mA) --> Current delivered by the AC adapter (out-disp + offset)
  • pm8226 T° (C) --> Temperature of pm8226_tz probe. (MotoG and MotoG 4G/LTE aka Falcon and Peregrine)
  • pm8110 T° (C) --> Temperature of pm8110_tz probe. (MotoE aka Condor)
  • Battery T° (C) --> Temperature given by battery probe
• ...

Charging and Time
Monitoring battery charge and Current over time

Charging curve is pretty common with a linear charge until 60% and then the rate starts decreasing. Nothing special there.
Charging Current follows the same behavior, showing that the power regulator of the MotoG does its job correctly limiting charging current to safe levels.

Charging and Temperature
Monitoring pm8226 and pm8110 Temperatures and respective charging current over Battery charge

Before showing any graph, we should keep in mind that results are highly inconsistent, T° is directly related to the way device is really idle or not, things can vary from 46 to 57°C!
I had a peak T° of 57°C when using Youtube, twitter and a few services running while charging. Though this peak T° is quickly going down to 52°C and then stabilize at about 50°C back to idle state

Do not use your device for moderate to intensive tasks while charging it (with high power charger) or it will fry!

Concerning OFFline charging, i had no way to monitor, but power used by the AC adapter is still between 7.9 and 8.7W (like ONline charging. the Screen T° felt (the pm8226 module is behind the center of the screen) is as warm as online charging when pm8226 was at about 48°C; obviously a felt T° is not objective.

We can see that the adapter provides a fairly stable current (most variations might due to measurements inaccuracies.) until 60% of charge, then it drops (expected.). Though the power management module that is pm8226 is extremely HOT (50+°C!!) --> Why is that?

• Doesn't it have an overheat protection? i'd love to investigate this...
• Is the AC adapter output too powerful for it? No, as we see, the module is able to limit current in the end of charge so it should do it at any time.
• Is the maximum Current accepted by the device to high for it? Motorola specifies the device to be able to charge with up to 1500mA, 1300 doesn't blow it up! I'm looking on a way to force a limitation to 1000mA and see if there are any improvements in T°

IMPORTANT : work hold on at this stage, i might continue it later. this article is published not to forget the already done part.

Using a Samsung 2A travel adapter with adaptive fast charging with MotoG : How does it behave? part 1 : first overview

My old Sony-Ercisson 850mA charger is ageing and i needed a new and more powerful one. i Bought the Samsung 2A travel adapter with adaptive fast charging model EP-TA20EWEUGWW (white one, with French 2 pins male plug)

• We can read everywhere that a charger will only provide what the device is capable to take, is that right?
• Is that really safe to charge a MotoG (specified to be capable of charging between 550 and 1500mA by the manufacturer) on a 2A adapter?

In the way chargers work, it should be ok, but does the device really behaves the way it is intended to?

Materials and Methods
Trying to keep things objective

• To monitor input Current:
  A wattmeter:
  
  It has a precision of +/- 1W that isn't precise at all, but this is only to roughly monitor the input current. ==> this inaccuracy will prevent me to give good efficiency predictions...


• To "monitor" output current: Ampere
  
  the app is not meant to be accurate, the idea is only to have an approximation of the current delivered by the charger.
  • The device uses between 180 and 300 mA when idle, screen ON, wifi ON.
  • Ampere mesurements display current applied to the battery, not the one coming from the adapter; so we will add 250mA to the results (or 160 with the experiments without wifi).
  • Therefore if Ampere displays +1000 mA that would mean that the adapter provides about 1250mA and Battery gets 1000mA.
  • Considering previous experiments we can assume that the results are accurate at +/-100mA; this means that when Ampere displays 1000mA, the charger provides something between 1150 and 1350mA (displayed current +250 +/-100)
• To monitor Temperature:
  Temperature is monitored with the pm8226_tz probe that looks like to be linked with the power manager of the battery -aka battery 'charger' when device is plugged to power source-

Chargers characteristics:
Sony: 5V 850mA
Samsung: 5V 2A or 9V 1.67A with fastcharging capable devicer (EP-TA20EWEUGWW)

For this first experiment the device was discharged down to about 50%

Efficiencies
When results are so inconsistent that you cannot really conclude -_-'

Sony at 50% charge:

• Input power: 6W +/-1
• Output power: 3.75~4.75W (5V 750~850mA)
• Efficiency : 54~95% (worst_case~best_case)

Samsung at 50% charge:

• Input power: 8W +/-1
• Output power: 6.35~7.35W(5V 1270~1470mA)
• Efficiency: 70~105% (No, current is not coming from anywhere, this 105% is due to the +/-1W inaccuracy of the input wattmeter!)

As best case condition cannot be used, let's see for worst cases:
Samsung worst case is above the sony's worst case so we can at least say that this adapter is NOT LESS efficient in this specific condition [50% battery, room temp @21°C ...]. As i don't have enough data yet -and the worst monitoring tools available- i am not able to say that the Samsung Charger is more efficient.

Overheating
When spare Watts become heat?

Sony at 50% charge :
Battery charging current was about 600mA meaning that the charger was providing 850+/-100mA, considering the charger cannot provide more than 850mA, the real value is somewhere between 750 and 850mA.
pm8226_tz T° is about 43°C, this threshold is never exceeded.

Samsung:

• at 50% charge :
  Battery charging current was about 1120mA meaning that the charger was providing 1370mA+/-100 pm8226_tz rises up to 51°C until the 70-75% of charge are reached,
• Then (70%+) current is limited to about 800mA and T° decrease slowly to reach 41°C at 80%.
• At 89% current is only 400mA pm8226_tz only 37°C and the Input current is lowered at 3.2W.
• When fully charged, idle and screen ON, the adapter still uses 1.9W from home circuit. which means that with an efficiency of about 70% the adapter provides about 226mA which corresponds to the device usage. When screen is OFF, the adapter input current drops under the watmetter detection threshold.

Here is a chart showing Charge Current and pm8226 Temperature against charging percentage.

Now, the questions are,

• what happens before 50% ?
• Does the adapter reaches the 1500mA that the device is theorically capable to handle?
• Is the device really able to handle that much Current ?
• How does the temperature increase if the device is NOT totally idle while charging?
• Will the battery survive multiple full charge this way?

Some answers in a few days, after i tried and get more data -and hopefully not fried my device xD-.

Quick Update before the full article : my MotoG power management unit (pm8226) reaches up to 57°C when using it really little while charging, i don't think it is safe at this level of heat ...

If i had better tools, i would try to make accurate charts about :

• pm8226 and battery T° (C) and Current (mA) against battery charge (%)
• Battery charge (%) agaisnt time (min)
• Charger efficiency (%) against Battery charge (%)
• Monitoring surface T° with a IR camera
• ...

CM12.1 : A few Drawbacks

I'm using CyanogenMod ROMs since the very beginning (started with a fork of CM6 called MiniCM6 by XDA Recognized Developer nobodyAtall).

Every CM version since then had more and more features, less and less bugs: the Sony-Ericsson X10mini (e10i, aka Robyn) started with the 'well-known' "SDcard safe to remove" reboot bug that crashed the device twice a day in the early miniCM6 ages...,
CM12.1 on Falcon (Motorola MotoG, XT1032) is far from this, a lot more mature, but still lacks a few things

CM12.1
Some lacking Features and some issues

Here is a list of a few things that bothers me in CM12.1. Don't take it wrong, CM12.1 is nice and works pretty well, the following list is only a few "cosmetic" issues, user-experience related.

• Expanded Desktop
  • Sometimes the nav bar doesn't show up when swiping up. (It needs to swipe down to display notifications, and then, nav bar shows up)
  • On some specific apps the nav bar is "ghost" meaning that once displayed (after swiping up) touching return buttons behaves as if the user had touched the content behind [like an ad........])
• "Per App" Expanded desktop
  • Enabled for all is nice,
  • Per app settings is nice, -when "Enabled for all" is un-checked-
  • BUT why can't we make per app customisation, when "Enabled for All" is checked? that would help when the user wants the expanded desktop to be enabled for NEARLY all apps, but keeping a few apps with both nav and status bar.
• 'The random Black Screen' with AmbientDisplay (with wave to wake, an pocket mode enabled)
  • In some rare cases, getting a notification wakes the device, but screen goes black (the only way to "fix" is force rebooting the device). Still no way to reproduce found yet,
• LiveDisplay : Automatic settings
  • Automatic settings only work when location is enabled. A great addition would be to set time of start and time of end of 'night-mode' as whe can do with F.lux or RedShift for users that don't keep location enabled all-the-time.
• LMK, is that really an issue?

Feel free to comment below, and i will update this article with your own feelings about the lacking features and the issues that bother you in CM12.1 (don't forget to tell your device if the issue is specific to a branch

For those complaining about Battery Life, don't forget to read this article ;-)

Moto G and Moto E : snapdragon 400 vs 200 Round2

A while ago we discussed about S200 vs S400 using the Old CPU Benchmark tool called "Linpack For Android", an app that had not been updated since ages. It was convenient for one reason : no update = no artificial MFLOPS increase due to app optimization ... but with CM11,12 and 12.1 i noticed huge performance drops in Linpack whereas i didn't feel any. It was time to try something else

Linpack for Android
A dead Benchmark app...

Linpack vs RgbenchMM on MotoE and MotoG:

RgbenchMM	1190MHz
	Moto E (S200)	Moto G (S400)
1	270	290
2	611	641
4	587	1280

Linpack	1190MHz
	Moto E (S200)	Moto G (S400)
Single	79	55
Multi	145	150
Per Core	72,5	50

Why is there so much disparity? the way the app make the CPU work and the way the workload has been set are different and so are results.
2 disparities :

• In Linpack Single Core results for MotoE (S200, stock rooted KK) and MotoG (S400, CM12.1) are not similar although they should regarding the Core frequency and the similar architecture. (results Are similar with RgbenchMM)
• MultiThread results are strange on Linpack : How a QuadCore CPU couldn't perform better than a DualCore one??
  • Linpack cannot handle more than 3 Threads
  • MotoG with CM12.1 starts with about 20% less MFLOPS with one core, and that is still the case in the multithreaded run... Not expected

Let's see how RgbenchMM performs in similar situation!

RgbenchMM
A Great CPU Benchmark app!

What do we see here?

• Results for RgbenchMM are similar with MotoE and MotoG for single and dual threading benchmarks : this is expected in the way S200 and S400 are clocked at the same frequency.
• 4 Threads run give more than 4 times the score of Single Thread one with the QuadCore S400
• Results are strictly linear to the number of cores for S400 (r²=0.97, which is pretty good for Benchmarks results)
• 4 threads benchmarking is only suitable for MotoG (the S400 is a quad-core) and gives inconsistent results with S200 (only dual-core, so 4 threads handled by 2 cores cannot give good results)
• Little lower results with MotoE could be explained since the S200 has its 2 cores shared between Benchmark and System, whereas MotoG (S400) has still 3 and 2 cores left to handle system processes during single and dual threads (although 4 threads run is strictly twice higher than 2 threads ... so even with all the cores used S400 MFLOPS/Core results are better than S200?)

• On both devices, MFLOPS/Core results are slightly better in Dual Thread run and Single Thread one

RgbenchMM dev explains the following:

it does about 6 loads and 8 multiply-accumalates (or 16 flops) inside the loop. The load instructions (FLDD) are also VFP instructions as are the FMACD instructions. Thus, the benchmark is testing the VFP performance almost exclusively. One other detail about the code is that the threads are setup so that ideally they are reading the same columns of one of the input matrices. This will be beneficial on architectures with at least 1 level of shared cache and thus you may see more than 2x speedup on a dual-core processor.

• The Extremely lower MFLOPS/Core result for 4 threads run on the DualCore S200 shows how it would handle hard multitasking.

Is the Conclusion changed?
Compared to the previous S200 vs s400 article

• Does Changing the Benchmark app modifies the conclusion about the S200 vs S400 comparison? No, i doesn't
• Does it changes the "Pure CPU benchmarks: the limits" article conclusion? Not exactly, in fact the results can't be compared since my MotoG was running CM11 at that time, but it could explain the high gap between CM11 and stock KK : it was more a Linpack bias than a ROM issue, i'll be able to test Stock ROM on a S400 soon, then the final conclusion will come.

Tip of the day: restoring WiFi settings after a factory reset

For some reason you may want to perform a clean install but don't want to waste all your spare time setting your complicated WiFi setup ?
Sadly you forgot to backup the WiFi settings (and google failed to re-sync them) but performed a Nandroid backup? 

 all the following steps can be performed directly on device, tested on Falcon running CM12 

story backgroung: after a buggy CM12 update and a failed rollback, my wifi settings were gone and google had synced the "blank" wpa_supplicant.conf file, i had no choice but trying to find a way to recover all the passphrases.

If you used TWRP, then things will be quite easy: 

• Take your backup, 
• Seek for data.f2fs.win 
• Copy it to a dedicated folder and 
• Rename it to data.tar.gz 

Assuming the backup is on your USB otg: 

1. Open terminal and type: cd /storage/usbdisk/TWRP/backup/ 
2. Make sure the file is there: ls 
3. Untar: tar -xvzf data.tar.gz 
4. After the unarchiving is completed you can search for ./misc/wifi/wpa_supplicant.conf 
5. Rename the existant one (/data/misc/wifi/wpa_supplicant.conf to wpa_supplicant.conf.bak)
6. Paste the new one there and 
7. Give proper permissions/owner/group (-rw-rw----, owner 1000-system, group 1010-wifi). 

 Your WiFi settings are back and you can now focus on more interesting things.

If you want to discuss about this subject, meet us at xdadevelopers.com

Quick Review: Hybrid Armor for Moto G : ageing

With time going on, things are ageing and a lot more when daily used. Here is the result of day to day use of a Cheap "Heavy Duty" case:

My first article about that case was written on June 17th 2014.

At that time it was brand new :

Wear and Tear Cosmmetic ageing

Time made its duty since then:

Coating is wearing a lot, not only in the angles, but also where some scratches were made:

Contrary to the "3 months later" post, the coating isn't simply getting scratches but even ripping off! 

Device protection Mechanical properties

Despite the bad cosmetic state after those 7 months of intensive usage, the mechanical properties of both rubber and hard plastic are still like on first day: providing an excellent protection to the device.

5$, 7 months (until now, but it may still last for quite a longer time) : for about 70 cents/month, it saved my device from a deadly crash a few times! It might not be pretty, but that's not what i asked it for.

CT406 : proximity and light sensor on MotoG

The CT406 module is both an Ambient Light Sensor (ALS) and a proximity sensor.

There are not much documentation on this product so here is what i understood from my research:

the above picture is a macro-picture of the ALS/prox sensor of my MotoG (MotoE has exact same module, but on the left side of the screen)

• On the left we can see a InfraRed LED (near IR range since we can see a little reddish light in the dark, but my camera catches part of IR spectrum and displays some kind of purple)
• In the middle there is a black spacer.
• On the right this looks like to be the sensor itself (from here, we know that the sensor is only an ALS that works as proximity sensor when coupled to an external IR-LED)

Here is the TAOS TSL277x chip that seems to be the base of the CT406.
TAOS (Texas Advanced Optoelectronic Solutions) brand is now known as ams.

Superposing my picture and that artwork: Pretty identical, right?

The pins are arranged this way (scheme is rotated 90° right compared to my picture):

How does the proximity sensor works? IR reflection...

The IR-LED emits Red-InfraRed lights and the right part detects if it is reflected or not (reflected == near; non-reflected == far)

To test this, it would be nice to use an external IR-LED and hide the embedded one to see if the sensor still say "far" when under IR light and "near" when IR light is turned OFF.

On our devices, the ALS sensor can only response a "high/low" output, but without the glass panel (that filter some IR) and a reworked program it could be used as presence detection (longuer range) [Source]

How does the ALS sensor works? Wide range light detection, IR detection, and human sight.

The chip features 2 photodiodes (one responds to wide range light: ch0; the other only gets IR: ch1)

In the above diagram we see ch0 respond to light from 300 (near UV) to about 1000nm (IR)
Humans see light from 390nm to 700nm (about, this means from deep-blue/ultra-violet to deep red/infrared), 

Humans don't see IR, therefore, light emitted from 700 to 1000nm produces a response from the light sensor (ch0) but Humans are actually in the dark, that would scale up light intensity of the device screen for no "human understandable reason".

That's what the IR sensor (ch1) is used for: the chip calculates something like ch0-ch1= actual human visible light intensity. Actually this is more complicated than this [Source, page 8&9]
The ALS operations have for duty to calculate what a real human would see (so, a spectrum without IR) in order to light the screen at the right human friendly level.

Luxmeter ALS outputs Lux that are then used by the device

The ch0 could give directly the light intensity with no real calculation if the system was open (no glass, whatsoever), and if there were no IR sensor. [See more page 10]

Real Life How does it work inside the MotoG?

Basically, the CT406 contains the following components :

• a sensor that is made of 2 photodiodes, one is wide range and reacts to human visible spectrum + IR; the second one reacts to IR only.
• an Infrared Light Emitting Diode (IR-LED)

The light sensor "reacts" to visible spectrum by using the signal coming from the wide range photodiode minus the IR one.

The proximity sensor is basically the IR photodiode reacting to IR light emitted by the IR-LED and reflected by a near surface.

The module speaks to the device using i2c protocol.


Proximity sensor has two states : 

• near (what the devices call "3cm") and 
• far (what the device calls "100cm")

The ALS has the following working range: 

• 2 lux (the light intensity is lower than sensor threshold)
• 65535 lux (fully saturated)

"The device can saturate if the light is brighter than can be accumulated with the light−to−frequency conversion. The full scale value for saturation will depend upon the integration time programmed into the device. In saturation, the device accumulates 1024 counts for each 2.72 ms of integration time programmed. For each ATIME programmed, the maximum count (saturation level) is the lesser of (1024 * (256 − ATIME)) or 65,535."


This explains a few things about why the screen is not at the intended brightness level.

• If the light isn't a wide range one; like a "white LED" which is actually a blue led with phosphor coating == the blue shift will saturate the sensor despite the "real" (== human felt) brightness is much lower.
• If the light is PWM controlled == is being lighten ON/OFF at high frequency to get desired "global" intensity : it would saturate the sensor  regarding sampling.
• if the light is a fluorescent light (same as for PWM controlled ones)

CM12 and MotoG

First overview Tip and Tricks

Here are some things i found after playing a little with CM12-20150108 Nightly :


How to get root ?

1. Enable Dev settings (multiple tap on "Build Number" in /settings/about phone/)
2. Go to Dev settings
3. Root access : Change to Apps and ADB

How to get Terminal app back?

It is now disabled by default, simple enable it in Dev Settings by toggling "Local Terminal"

That's all for today folks!

This blog might be totally reworked in the coming months but i don't have much time at the moment...

MotoG : Pure CPU Benchmarks, the limits

To point out pure CPU Benchmark flaws, we'll observe how does a moto G (Falcon or Peregrine, this has no relevance) behaves with Linpack Benchmark when running on Stock 4.4.4 Motorola ROM or CM11-20141124-nightly (4.4.4).

We have seen previously that Linpack didn't use all cores and was limited to 3 threads in multi-thread benchmarking (when comparing s200 and s400 SoC).

Now, we will compare MFLOPS performance between two ROMs that has similar user experience (smoothness mostly)

Stock 4.4.4 Motorola ROM vs CM11

both @1190MHz, Interactive governor.

Stock Motorola features a nearly doubled score for both Single and Multi-Thread, but does that mean it is really better optimized?

• In a way, yes, CM11 is made to be compatible with most devices, so we encounter similar problem seen with Windows against iOS : 
• An OS that fits all against a fully optimized one made for a few specific hardware. Motorola obviously optimized their software to get the best of this great device
• If you compare with the MotoG vs MotoE test, you'll see that the MotoG running CM11 has lower results than MotoE running stock ROM ...

• On the other hand, that's not all a matter of optimization :
• CM11 features KSM, zRAM, and many things that use CPU cycles to compress memory (zRAM) or merging merge-able things (KSM) ==> this reduces CPU pure performance but increase multi-tasking ability.
• The war of versatility and customization against slickness and stability...
• Honestly i can't see difference in user-felt performances...

Actually, i don't see any issues by using CM11 as a daily driver on my XT1032 (Falcon), it is not because a Benchmark say something that it is true in "real life"...

• Don't use CM11 on Moto G if you want to show off with high CPU benchmark results ...
• Stock Motorola ROM is close enough to AOSP to be acceptable as daily driver
• Xposed helps you to get the best of stock ROM
• CM11 is great for end-user customization

The real conclusion is the following :

Don't trust Benchmarks as incontestable truth, they helps to compare devices and  ROMs, but never really tell you how good devices/ROMs are.

Moto G and Moto E : snapdragon 400 vs 200

Snapdragon 400 vs Snapdragon 200 based on msm8926/8226 vs msm8610

After we studied MFLOPS per MHz ...

It is now time to compare MotoE and MotoG:

Moto G and E features a Snapdragon 400 and 200 (respectively a Quad-core Cortex A7 @1.19GHz and a Dual-core Cortex A7 @1.19GHz)

Note that previous benchmarks were performed with ONDEMAND governor on CyangenMod11 ROM, but stock Moto ROM uses Interactive by default (i didn't expected that...) so the following has been made with interactive for both devices (needed to re-bench MotoG >_<)

to check above results are applicable despite governor modification : 

MFLOPS per governor on MotoG (Falcon, CM11) @1190MHz

No significant difference between ONDEMAND and Interactive governors for the specified test.

Moto G (Peregrine) vs Moto E (Condor) msm8926 vs msm8610

To improve accuracy, instead of using my Falcon (XT1032) running CM11, we will compare results obtained on a Peregrine (XT1039) running Stock Motorola ROM :

Both Benchmarks have been run on Motorola Stock 4.4.4 ROM on Moto G (Peregrine) and Moto E (Condor):

There is no differences between msm8226 (Falcon) and msm8926 (Peregrine) despite LTE capability of msm8926, that's why we will use a Peregrine for the following part.

MotoG (Peregrine) vs MotoE (Condor) @1190MHz, stock 4.4.4

We have quite similar results on Single Thread application for one simple reason, the number of cores does not have any impact. Since the clock speed is the same, the results are the one expected.

On Multi-thread the difference is quite huge between the quad-core and the dual-core, though we don't see a x2 ratio by doubling the cores number.

MFLOPS divided per the amount of cores

x/4 for msm8926 and x/2 for msm8610, Single Thread as control.

We should have observed a similar result between Single and Multi/nbCore...
Is the msm8926 really shitty at multithreading? i don't think so, looks more like if linpack or the system only uses 3 Threads...

If we apply a corrective divider (3 instead of 4) the results are perfect :

MFLOPS divided per the amount of threads used

x/3 for msm8926 and x/2 for msm8610, Single Thread as control.

Moto E (Condor) and Moto G (Peregrine or Falcon) should have similar performance in single threaded applications.

Though the 4 Cores may no be used at their full potential in some apps, multi-threaded applications should be better handled by the msm8926/8226 featured by moto G.

Moto G? or Moto E? Which one for What...

For moderate usage, Moto E is quite enough compared to Moto G : 

• It is not weaker on Single Threaded applications
• It has a smaller battery but both smaller CPU and half size Screen in pixels (960*540 vs 1280*720) will give it a great battery life.

Moto G is still the best quality/price in its category (prefer the Peregrine version and not the Moto G 2014 aka Titan)

• Multi-threaded applications will obviously run better on it
• The better Screen density improves user experience on long term usage
• A far better Camera...

A complete Moto G - Moto E versus is available on versus.com (note that Moto G Peregrine does not have 16GB of internal memory ... but only 8, and an SDcard slot.)

CPU Freq and Performances : Single and Multi Thread

Linpack Benchmarking for Moto G, Single and Multi-Threads...

Before we compare Moto G and E Snapdragon 400 and 200 (respectively a Quad-core Cortex A7 @1.19GHz and a Dual-core Cortex A7 @1.19GHz), let's see how the Moto G performs with ONDEMAND governor and increasing CPU Clock.

MFLOPS and CPU Clock speed On Moto G XT1032 aka Falcon, CM11

A MotoG XT1032, running CM11-20141124-NIGHTLY has been used for MFLOPS per MHz tests.

The CPU is downclocked at 787MHz, and then frequency is raised up to nominal Frequency that is 1190MHz. Here are Single and Multi-Thread MFLOPS results.

You can note that 998MHz had inconsistent results due to high standard deviation...

MFLOPS/MHz A closer look to the results

Multi-thread results raise quicker than Single Thread, let's explore this closer :

As we can see, 

• MFLOPS/MHz ratio does not increase much for Single Thread, but,
• For Multi-thread the ratio increases between 787 and 998MHz but then stagnates : This means that MFLOPS increases in a linear way as Frequency is raised.

This can be explained by the following fact : 

The OS needs some CPU cycles to stay ON, so under a certain frequency it conflicts with Linpack work and decreases performances more than expected.

Conclusion? As a conclusion, we can say that CPU clock increase is more effective on multi-threaded applications (in a quite linear manner) than on Single threaded ones.