Centralization of graphical awesomeness

Tue Oct 27 15:11:08 CET 2009

I am sorry, but my letter is not about trolling and blaming but about
optimization, qt and e, speed is interesting for me, not blaming. Calm
down guys! I've numbered separate points overwise my letter will look
endless :)

1. First, bit about qt scrolling - It's not so simple Carlsen want it to
be. I see background image, rendered text and 1-2 relativaly small image
each line. "Apllications" menu have ~40 entries. All scrolling very
smooth, and no rectangles where. Carlsen, have you run qtmoko? Buttons
are changing only then you press them. What prevents E from prerendering
contents of scrollable area, it is not changing on the fly? Lack of this
optimization makes menus and scrollable areas much slower. 

2. Second point of my letter was that Glamo seem should not be blamed
for everything. I wrote simple program to measure simple memcpy speed on
om... This program just allocates 2 buffers of defined size and outputs
count of memcpys of defined size it did in 1 second (interrupt via
alarm()). Initally I want to see how arm cache cleanup and task switch
influences parallel memory access tasks. Result were surprising for me:

OM:
buffer_size average_number computed_throughput
128 1260880 153Mb/s
256  540900 132Mb/s
512  252399 123Mb/s
1024 121988 119Mb/s
2048  58827 114Mb/s
4096  29000 113Mb/s
8192  14000 109Mb/s
16384  3660 57Mb/s
32768  1105 36Mb/s
65536   553 34.5Mb/s
131072  274 34.2Mb/s
262144  135 33.7Mb/s
524288   69 34.5Mb/s

I did same test on my very-old-Celeron 600 router:
256     2522958         615Mb/s
512     2088723         1019Mb/s
1024    1554162         1571Mb/s
2048    1019996         1992Mb/s
3072    762667          2234Mb/s
4096    109489          427Mb/s
16384   27389           427Mb/s
262144  318             79Mb/s
524288  151             75Mb/s
1048576 76              76Mb/s

On desktop (xeon 2Gz):
x64 binary:
26214400 74              1850 Mb/s
262144   31971           7992 Mb/s
256      53994512        13232 Mb/s

x32 binary: 
26214400        59                 1475 Mb/s
262144          29068              7267 Mb/s
256             20810406           5080 Mb/s

Old arm-based device at my work (at91rm9200, 180Mhz)
2560000 16	39Mb/s
256000	167	40Mb/s
256 	418044	102Mb/s

So, we can see that we have speed of 34Mb/s (it's ever only 5 times
declared 7Mb/s for Glamo!) can someone comment? why memcpy is so slow -
it is 2 times slower than ancient celeron, and on par with very old
arm-based machine, it is not related to glamo anyhow! We can even skip
results with cache, where om 10 times slower old machine.

3. ... e - every N seconds (see config dialogs for what it is set
to there, but let's say 60 seconds) will flush caches. ... and things are having to be repopulated
from disk ...

>From disk?! This is cost or having small memory footprint? This looks very wrong.

3. ... Actually, yes the GTA01 is very noticeably faster in
graphics. ...
Can you expose a bit more details: How much it is faster: x2 times, x3,
x1.5, x1.2?

4. ... for every second spent uploading contents to glamo, you CANNOT
spend it calculating a new fram. ... 
Yes, this is bad... But qt works :)

5. ... that's because you have 2 processes competing for the cpu to
render. ...
My measurements of parallel memcpy showed that this is neglibible.

6. ... you wont find routines for rendering faster in most of the
world. ...
I will. I can recall you previous posts on the topic.

7. but.. if i were smart.. i'd not develop apps for the freerunner. it's
a "dead product". it has no more being produced. it has no evolution
path. there won't be a gtao3, 04, 05 etc. everyone quit or was fired/let
go from om that worked on phones.. or worked on pretty much anything.
your future is other devices.. and these don't suck with EFL. i'd not
compromise the future if i were smart.

Frankly speaking you never developed for GTA02, yes? you aim seem always
were in future, and this is ok. I am sure that for example scrolling
area pre-rendering if good for future.

8. ... most games i know of are written to work on the highest end
graphics cards at the time. why? ...
Best games are written with other objectives in mind, this games are
really interesting for anyone from time to time and for sure will live
in ages (chess, nethack and so), our grandchilds will play nethack, be
sure. Is it better to make pefrect things? 
And optimization is always good - you can feel that 10ms latency and
100ms latency is different even both are more than enoght for UI, but
you feel that 10ms latency is much better.

9. ... BUSINESS CHOICE ...
Everyone here follows it's goals. Carlsen make E. Other want to do
hardware. Others want to use free hardware. Others want to increase
development skills and hack that HW. Others just feel fun reading this
book. Others have this job. Someone even makeing money from OM. ;) All
this is ok, and I see nothing bad on making some great E developer to
think a bit about optimizations - nobody loose from optimizing of E and
writing a bit of technical descriptions :)

Gennady

В Втр, 27/10/2009 в 22:37 +1100, Carsten Haitzler пишет:
...