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 ;-) -

DIY USB camera for an optical microscope

I recently got a "new" microscope : a Lemardeley from the 60s featuring both mono and binocular eyepieces (x5, x8, x10) and x10, x25, x60 and x120 objectives Taking pictures using a standard camera/smartphone is possible but gives some vignetted pictures, what about making a dedicated camera?

The Lemardeley microscope
Old good guy

On this picture the microscope is mounted with the binocular eyepiece, note the monocular one securely placed on the left wall of the wood box. also the objectives and oculars have a place in a sliding rack.
Luckily objectives of my previous microscope (from 2003) are using the same screw thread so i could adapt its x4 objective! (and potentially the x10 and x40 but that is quite useless here)
So here is the magnifying range :

X		Ocular Lens
		5	8	10
objectives	4	20	32	40
	10	50	80	100
	25	125	200	250
	60	300	480	600
	120	600	960	1200

Modernizing
adding a camera

After reading a lot on the web, i found that best results were given with a lensless camera module and without any ocular.
What is needed :

• USB webcamera (here it was taken from an old ASUS laptop)
• Old roll of film box
• USB cable to connect the camera (either the webcam's one or a dedicated DIY one for embedded webcams
• Hot glue, pasting tape, anything to cut or drill holes

How to

1. Getting webcam and disassembling it to only keep the PCB, -not removing the lens yet-

2. Checking if the roll fits on the eyepiece tube and drilling a hole on the back of it

3. removing the camera lens and adapting roll box to fit the camera, hot gluing it (note the dust on the sensor, this will be an issue later...)


4. make/adapting the cable (will depend on the camera used...)

5. Testing

Result
looking at a random chip

Here is a sensor on an HP scanner board : click for full size, -red circle shows the region zoomed on the right -one after the other-
Pictures are taken with guvcview.

Note the black dot (circled in red) : this is the result of the dust on the camera CCD