Active Topics

 


Reply
Thread Tools
javispedro's Avatar
Posts: 2,355 | Thanked: 5,249 times | Joined on Jan 2009 @ Barcelona
#181
Originally Posted by attila77 View Post
Can't really agree - C(++) is the one that can go to (almost any) platform, Qt alone *officially* addresses ~12 platforms. Dalvik is not a full Java VM so while generic code is transferable, APIs aren't. Android code runs only on Android...
Well, I'm quite sure both languages (Java/C++) are quite portable (back in PalmOS days I had a Java-to-C++ code converter); however, code using "C++ APIs" are not transferable either, and you have a prime example around: Symbian. I haven't had the pleasure to code for it, but word is out I would quickly find out any of its multiple standard template library "discrepancies".

Last edited by javispedro; 2011-03-04 at 18:58.
 
Posts: 3,319 | Thanked: 5,610 times | Joined on Aug 2008 @ Finland
#182
Symbian's roots are (gasp) older than the C++ standard so suffer from a number of historical artifacts that resulted in it using a C++ dialect (Dalvik is a different story as the Java standard was intentionally broken/subverted for performance/platsec reasons). Now, C++ *does* have a (not overly extensive, but nonetheless defined) standard library. And if that's not enough (and POSIX is a pain), there's good old Qt which has a fairly wide and OS agnostic API.
__________________
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
 
Posts: 3,319 | Thanked: 5,610 times | Joined on Aug 2008 @ Finland
#183
Heh, just ran accross this (disclaimer: yes, it's flammable



http://www.tiobe.com/index.php/conte...definition.htm
__________________
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
 

The Following User Says Thank You to attila77 For This Useful Post:
javispedro's Avatar
Posts: 2,355 | Thanked: 5,249 times | Joined on Jan 2009 @ Barcelona
#184
I distrust all language trends statistics whose primary source is Web stuff. They tend to favour Web languages, for obvious reasons.

(Or would anyone that has been outside in the real world seriously consider for a moment that PHP rivals with C++ in terms of deployment)
 
Posts: 1,341 | Thanked: 708 times | Joined on Feb 2010
#185
Originally Posted by attila77 View Post
cpuinfo is not really what I was getting at - what it comes down is that memory management *cannot* be handled independently by applications/processes because there is not a single winning strategy - in fact, it's a bit like the Prisoner's dilemma. Firefox fails at this, but it is by choice, to obtain as much platform independence as possible.
procinfo was just an example that program can know for example is it running on platform with 1 CPU, or multiple cores and what are the sizes of L2-data-cache. When JVM would notice it can have at least two concurrent running threads, it could do runtime profiling without disturbing the 1st main thread too much and also do some "fancy" GC-tricks in the background.

I got interested how for example I would check the rate of L2-cache misses/hits in Firefox, and found this: PAPI

Out of curiosity I tried, if Fedora 14 would know something about it (yum search papi) and yes it was supported out of the box.

So for example in my laptop, Linux would give these information to an appplication, so VMs could see physical memory fragmentation is getting worse (rate of cache misses increases).

Code:
$ papi_avail 
Available events and hardware information.
--------------------------------------------------------------------------------
PAPI Version             : 4.1.0.0
Vendor string and code   : AuthenticAMD (2)
Model string and code    : AMD Turion(tm) 64 Mobile Technology ML-32 (36)
CPU Revision             : 2.000000
CPUID Info               : Family: 15  Model: 36  Stepping: 2
CPU Megahertz            : 1800.000000
CPU Clock Megahertz      : 1800
Hdw Threads per core     : 1
Cores per Socket         : 1
NUMA Nodes               : 1
CPU's per Node           : 1
Total CPU's              : 1
Number Hardware Counters : 4
Max Multiplex Counters   : 512
--------------------------------------------------------------------------------
The following correspond to fields in the PAPI_event_info_t structure.

    Name        Code    Avail Deriv Description (Note)
PAPI_L1_DCM  0x80000000  Yes   No   Level 1 data cache misses
PAPI_L1_ICM  0x80000001  Yes   No   Level 1 instruction cache misses
PAPI_L2_DCM  0x80000002  Yes   No   Level 2 data cache misses
PAPI_L2_ICM  0x80000003  Yes   No   Level 2 instruction cache misses
PAPI_L3_DCM  0x80000004  No    No   Level 3 data cache misses
PAPI_L3_ICM  0x80000005  No    No   Level 3 instruction cache misses
PAPI_L1_TCM  0x80000006  Yes   Yes  Level 1 cache misses
PAPI_L2_TCM  0x80000007  Yes   No   Level 2 cache misses
PAPI_L3_TCM  0x80000008  No    No   Level 3 cache misses
PAPI_CA_SNP  0x80000009  No    No   Requests for a snoop
PAPI_CA_SHR  0x8000000a  No    No   Requests for exclusive access to shared cace
PAPI_CA_CLN  0x8000000b  No    No   Requests for exclusive access to clean cache
PAPI_CA_INV  0x8000000c  No    No   Requests for cache line invalidation
PAPI_CA_ITV  0x8000000d  No    No   Requests for cache line intervention
PAPI_L3_LDM  0x8000000e  No    No   Level 3 load misses
PAPI_L3_STM  0x8000000f  No    No   Level 3 store misses
PAPI_BRU_IDL 0x80000010  No    No   Cycles branch units are idle
PAPI_FXU_IDL 0x80000011  No    No   Cycles integer units are idle
PAPI_FPU_IDL 0x80000012  Yes   No   Cycles floating point units are idle
PAPI_LSU_IDL 0x80000013  No    No   Cycles load/store units are idle
PAPI_TLB_DM  0x80000014  Yes   No   Data translation lookaside buffer misses
PAPI_TLB_IM  0x80000015  Yes   No   Instruction translation lookaside buffer mis
PAPI_TLB_TL  0x80000016  Yes   Yes  Total translation lookaside buffer misses
PAPI_L1_LDM  0x80000017  No    No   Level 1 load misses
PAPI_L1_STM  0x80000018  No    No   Level 1 store misses
PAPI_L2_LDM  0x80000019  No    No   Level 2 load misses
PAPI_L2_STM  0x8000001a  No    No   Level 2 store misses
PAPI_BTAC_M  0x8000001b  No    No   Branch target address cache misses
PAPI_PRF_DM  0x8000001c  No    No   Data prefetch cache misses
PAPI_L3_DCH  0x8000001d  No    No   Level 3 data cache hits
PAPI_TLB_SD  0x8000001e  No    No   Translation lookaside buffer shootdowns
PAPI_CSR_FAL 0x8000001f  No    No   Failed store conditional instructions
PAPI_CSR_SUC 0x80000020  No    No   Successful store conditional instructions
PAPI_CSR_TOT 0x80000021  No    No   Total store conditional instructions
PAPI_MEM_SCY 0x80000022  No    No   Cycles Stalled Waiting for memory accesses
PAPI_MEM_RCY 0x80000023  No    No   Cycles Stalled Waiting for memory Reads
PAPI_MEM_WCY 0x80000024  No    No   Cycles Stalled Waiting for memory writes
PAPI_STL_ICY 0x80000025  Yes   No   Cycles with no instruction issue
PAPI_FUL_ICY 0x80000026  No    No   Cycles with maximum instruction issue
PAPI_STL_CCY 0x80000027  No    No   Cycles with no instructions completed
PAPI_FUL_CCY 0x80000028  No    No   Cycles with maximum instructions completed
PAPI_HW_INT  0x80000029  Yes   No   Hardware interrupts
PAPI_BR_UCN  0x8000002a  No    No   Unconditional branch instructions
PAPI_BR_CN   0x8000002b  No    No   Conditional branch instructions
PAPI_BR_TKN  0x8000002c  Yes   No   Conditional branch instructions taken
PAPI_BR_NTK  0x8000002d  No    No   Conditional branch instructions not taken
PAPI_BR_MSP  0x8000002e  Yes   No   Conditional branch instructions mispredicted
PAPI_BR_PRC  0x8000002f  No    No   Conditional branch instructions correctly pd
PAPI_FMA_INS 0x80000030  No    No   FMA instructions completed
PAPI_TOT_IIS 0x80000031  No    No   Instructions issued
PAPI_TOT_INS 0x80000032  Yes   No   Instructions completed
PAPI_INT_INS 0x80000033  No    No   Integer instructions
PAPI_FP_INS  0x80000034  Yes   No   Floating point instructions
PAPI_LD_INS  0x80000035  No    No   Load instructions
PAPI_SR_INS  0x80000036  No    No   Store instructions
PAPI_BR_INS  0x80000037  Yes   No   Branch instructions
PAPI_VEC_INS 0x80000038  Yes   No   Vector/SIMD instructions (could include int)
PAPI_RES_STL 0x80000039  Yes   No   Cycles stalled on any resource
PAPI_FP_STAL 0x8000003a  No    No   Cycles the FP unit(s) are stalled
PAPI_TOT_CYC 0x8000003b  Yes   No   Total cycles
PAPI_LST_INS 0x8000003c  No    No   Load/store instructions completed
PAPI_SYC_INS 0x8000003d  No    No   Synchronization instructions completed
PAPI_L1_DCH  0x8000003e  Yes   Yes  Level 1 data cache hits
PAPI_L2_DCH  0x8000003f  Yes   Yes  Level 2 data cache hits
PAPI_L1_DCA  0x80000040  Yes   No   Level 1 data cache accesses
PAPI_L2_DCA  0x80000041  Yes   No   Level 2 data cache accesses
PAPI_L3_DCA  0x80000042  No    No   Level 3 data cache accesses
PAPI_L1_DCR  0x80000043  No    No   Level 1 data cache reads
PAPI_L2_DCR  0x80000044  No    No   Level 2 data cache reads
PAPI_L3_DCR  0x80000045  No    No   Level 3 data cache reads
PAPI_L1_DCW  0x80000046  No    No   Level 1 data cache writes
PAPI_L2_DCW  0x80000047  No    No   Level 2 data cache writes
PAPI_L3_DCW  0x80000048  No    No   Level 3 data cache writes
PAPI_L1_ICH  0x80000049  Yes   Yes  Level 1 instruction cache hits
PAPI_L2_ICH  0x8000004a  Yes   No   Level 2 instruction cache hits
PAPI_L3_ICH  0x8000004b  No    No   Level 3 instruction cache hits
PAPI_L1_ICA  0x8000004c  Yes   No   Level 1 instruction cache accesses
PAPI_L2_ICA  0x8000004d  Yes   No   Level 2 instruction cache accesses
PAPI_L3_ICA  0x8000004e  No    No   Level 3 instruction cache accesses
PAPI_L1_ICR  0x8000004f  Yes   No   Level 1 instruction cache reads
PAPI_L2_ICR  0x80000050  No    No   Level 2 instruction cache reads
PAPI_L3_ICR  0x80000051  No    No   Level 3 instruction cache reads
PAPI_L1_ICW  0x80000052  No    No   Level 1 instruction cache writes
PAPI_L2_ICW  0x80000053  No    No   Level 2 instruction cache writes
PAPI_L3_ICW  0x80000054  No    No   Level 3 instruction cache writes
PAPI_L1_TCH  0x80000055  Yes   Yes  Level 1 total cache hits
PAPI_L2_TCH  0x80000056  Yes   Yes  Level 2 total cache hits
PAPI_L3_TCH  0x80000057  No    No   Level 3 total cache hits
PAPI_L1_TCA  0x80000058  Yes   Yes  Level 1 total cache accesses
PAPI_L2_TCA  0x80000059  Yes   No   Level 2 total cache accesses
PAPI_L3_TCA  0x8000005a  No    No   Level 3 total cache accesses
PAPI_L1_TCR  0x8000005b  No    No   Level 1 total cache reads
PAPI_L2_TCR  0x8000005c  No    No   Level 2 total cache reads
PAPI_L3_TCR  0x8000005d  No    No   Level 3 total cache reads
PAPI_L1_TCW  0x8000005e  No    No   Level 1 total cache writes
PAPI_L2_TCW  0x8000005f  No    No   Level 2 total cache writes
PAPI_L3_TCW  0x80000060  No    No   Level 3 total cache writes
PAPI_FML_INS 0x80000061  Yes   No   Floating point multiply instructions
PAPI_FAD_INS 0x80000062  Yes   No   Floating point add instructions
PAPI_FDV_INS 0x80000063  No    No   Floating point divide instructions
PAPI_FSQ_INS 0x80000064  No    No   Floating point square root instructions
PAPI_FNV_INS 0x80000065  No    No   Floating point inverse instructions
PAPI_FP_OPS  0x80000066  Yes   No   Floating point operations (Counts speculati)
PAPI_SP_OPS  0x80000067  No    No   Floating point operations; optimized to cous
PAPI_DP_OPS  0x80000068  No    No   Floating point operations; optimized to cous
PAPI_VEC_SP  0x80000069  No    No   Single precision vector/SIMD instructions
PAPI_VEC_DP  0x8000006a  No    No   Double precision vector/SIMD instructions
-------------------------------------------------------------------------
Of 107 possible events, 36 are available, of which 8 are derived.

avail.c                                  PASSED


I think (as I've said) it is just question of when those "academic" known compiling optimizations are taken into VMs, especially because most of the devices will have multiple cores and fancy tricks wouldn't increase latency.

The ideal setup is IMHO Python+QML for extremely quick prototyping and then gradually replacing the Python functions with C++ for better resource usage & performance.
I haven't coded anything with QML, but I studied it briefly. I found it abit frustrating one should use two different programming languages and syntaxes to do a GUI-program. If there is a separate persons doing GUI and logic, then of course it doesn't matter. Also maybe, I do not know, it could help to separate UX from program logic which can be good when porting program to other platforms and UIs.
But....was it really necessary to create a new language?
 
Posts: 3,319 | Thanked: 5,610 times | Joined on Aug 2008 @ Finland
#186
Originally Posted by zimon View Post
procinfo was just an example that program can know for example is it running on platform with 1 CPU, or multiple cores and what are the sizes of L2-data-cache. When JVM would notice it can have at least two concurrent running threads, it could do runtime profiling without disturbing the 1st main thread too much and also do some "fancy" GC-tricks in the background.
As said previously, applications (and VMs) *can* get too smart for their own good. In the example above, *seeing* multiple CPUs means little. They could be separate cores. They could be virtual (for example on Intel CPUs that do hyperthreading). They could be differently clocked. They could be a remnant of the virtualizer (the physical machine having separate CPUs but your process might be still limited to one). The L2 cache also can be dedicated or shared, which would require different usage patterns. And, back to the prisoner dilemma - you don't know how those resources are used by other tasks so by trying to be too smart you might actually be lowering overall efficiency.

I haven't coded anything with QML, but I studied it briefly. I found it abit frustrating one should use two different programming languages and syntaxes to do a GUI-program. If there is a separate persons doing GUI and logic, then of course it doesn't matter. Also maybe, I do not know, it could help to separate UX from program logic which can be good when porting program to other platforms and UIs.
But....was it really necessary to create a new language?
With hindsight: Absolutely. QML doesn't do anything you couldn't do with any Qt binding. You could write (and many did) your GUI using QGraphicsView/QGraphicsItems/Q*Animations. However, with the 'old' approach, that would end up with hundreds of lines of unreadable code and designers would get a stroke if they needed to just look at it.

But since I know you love Java I can tell you Java actually did the same thing (whether they succeeded is still up for debate) - check JavaFX, it's the Java 'equivalent' of QML.
__________________
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
 
Posts: 3,319 | Thanked: 5,610 times | Joined on Aug 2008 @ Finland
#187
Originally Posted by javispedro View Post
I distrust all language trends statistics whose primary source is Web stuff. They tend to favour Web languages, for obvious reasons.

(Or would anyone that has been outside in the real world seriously consider for a moment that PHP rivals with C++ in terms of deployment)
Might not be obvious from the graph, but this is about popularity, not deployment (very evident for example from the Objective C graph). Plus, C++ and C are counted as separate entities, while in reality they are more like parts of one family. But as disclaimed, I'm not trying to prove anything and know it will touch many people in sensitive places It was just something funny I ran across.
__________________
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
 
Capt'n Corrupt's Avatar
Posts: 3,524 | Thanked: 2,958 times | Joined on Oct 2007 @ Delta Quadrant
#188
Using a markup language to separate interface from logic concerns seems remarkably aspect-like.

Which hints at at least one major point of differentiation between the systems besides their compilation strategies or runtime-efficiencies: Aspect-Oriented programming.

While there is an AspectC++ available as a language extension, it seems quite young, compared to AspectJ, while using a similar strategy. Other than that, there are few examples (that I have found) of AOP in C++.

I'm curious to hear your thoughts about Aspect Oriented Programming as a complement to OOP. It seems that this style is unpopular at best, and generally not well understood.
 
Posts: 1,341 | Thanked: 708 times | Joined on Feb 2010
#189
Originally Posted by attila77 View Post
As said previously, applications (and VMs) *can* get too smart for their own good. In the example above, *seeing* multiple CPUs means little. They could be separate cores. They could be virtual (for example on Intel CPUs that do hyperthreading). They could be differently clocked. They could be a remnant of the virtualizer (the physical machine having separate CPUs but your process might be still limited to one).
The PAPI will probably tell all those things in the future, if there really is those complicated cases. Seems like PAPI is just what VMs will need to enable some of the modern known compiling science optimizations. It makes sense to extend PAPI to tell sensible information when if running in a virtual machine.

For example hyperthreading or not can already be seen (papi_avail):
Code:
Hdw Threads per core     : 1
Cores per Socket         : 2
NUMA Nodes               : 1
CPU's per Node           : 2
Total CPU's              : 2
Hyperthreading or how many concurrent threads there can be, can be tested quickly also without PAPI (rdtsc) in modern CPUs.

Would be interesting to get PAPI ported to the maemo kernel-power to monitor cache misses and hits. I seem to notice same phenomena in Fennec and microB as with desktop Firefox; when using it long (many days) it is better to just restart the browser totally and open windows/tabs again.

The L2 cache also can be dedicated or shared, which would require different usage patterns. And, back to the prisoner dilemma - you don't know how those resources are used by other tasks so by trying to be too smart you might actually be lowering overall efficiency.
All these special cases are much easier to tackle in VMs than in C++ code of every applications. VMs need to be optimized only once per platform.

You said that Firefox is by its own choice maybe inefficient in memory management and perhaps Linux' native own memory management would be better. Maybe it is just too much work to optimize Firefox to every different platform, but for VMs it makes sense and probably will be done at least on high end systems.
Another plus for Java over C++ in future systems.

What it comes to popularity of programming languages, the graph was good. But in mobile systems the number of applications in Android Market is a good indication that Java seems not to have poor productivity.
On December 31, 2010 the Android market reached the 200,000 app milestone.

Last edited by zimon; 2011-03-07 at 16:51.
 
Posts: 3,319 | Thanked: 5,610 times | Joined on Aug 2008 @ Finland
#190
Long story short - too much optimizing on an *application level* for hardware WILL backfire (except for very special cases like audio/video/opengl) because you try to anticipate how the OS/hardware works, and the OS/hardware tries to anticipate what you want to do. That stuff should be left to the OS, period.

Originally Posted by zimon View Post
All these special cases are much easier to tackle in VMs than in C++ code of every applications. VMs need to be optimized only once per platform.
? Again back to language vs platform ? But that's not even platform, I was making a point that even with X86 (even if I forget OSes), you have dozens of very different configurations, which in practice make all these targeted cache and thread level optimizations pointless at best or counterproductive at worst.

You said that Firefox is by its own choice maybe inefficient in memory management and perhaps Linux' native own memory management would be better. Maybe it is just too much work to optimize Firefox to every different platform, but for VMs it makes sense and probably will be done at least on high end systems.
Another plus for Java over C++ in future systems.
That is jumping to conclusions. There is nothing saying that EVERY VM will have a better memory management (we always stop at 'a VM *could* do this or that', not at real life numbers on how exact VMs operate) than EVERY custom memory-management lib/function. As said previously, I could use the same argument to claim both C++ and Java suck and that we should be coding in Lisp/Prolog/Haskell, because in theory they *could* be better at everything you are trying to do with a structural programming language.

What it comes to popularity of programming languages, the graph was good. But in mobile systems the number of applications in Android Market is a good indication that Java seems seems not to have poor productivity.
No, that only means that Android as a platform is very popular. J2ME was Java and it was *terrible* productivity-wise. See also Objective C. It's been around for quite some time now but until the AppStore came along, nobody cared. Plus the detail that 200K refers to the number of entries in general (native, dalvik, wallpaper or other).
__________________
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
 

The Following User Says Thank You to attila77 For This Useful Post:
Reply

Tags
bada rox, dalvik, future, java haters, meego, meego?fail, nokia, sandbox sucks


 
Forum Jump


All times are GMT. The time now is 09:46.