Linked by sawboss on Mon 14th Feb 2011 23:09 UTC
Hardware, Embedded Systems "The name Snapdragon is fast becoming well-known among consumers as the chip to have inside your smartphone. Offering speeds of up to 1.5GHz at the moment, it's certainly one of the fastest mobile chips out there. Qualcomm doesn't want the reputation of Snapdragon to falter, though, so the chip manufacturer has just announced an update that will have smartphone and tablet users drooling. The next iteration of the Snapdragon processor line is codenamed Krait and uses 28nm manufacturing technology. It will be offered in single, dual, and quad-core versions with clock speeds up to 2.5GHz. If the huge increase in performance wasn’t enough for you, Qualcomm also boast a 65% reduction in power use over existing mobile ARM chips."
Thread beginning with comment 462542
To view parent comment, click here.
To read all comments associated with this story, please click here.
moondevil
Member since:
2005-07-08

Exactly the opposite. With a VM you can do code validation as the verifiers present in the JVM and CLR attest to.

You cannot so easily do code validation with assembly, because of the lower level of allowed operations.

That is the main reason why Google is forced to restrict the NaCL instruction set.

Plus thanks to dynamic code profiling, it is possible to have a JIT generate better code for the actual running processor, as a static compiler would be able to.

Reply Parent Score: 2

Neolander Member since:
2010-03-08

The opposite of what ?

Well, I think I'll try to reword this post differently.

You can just as well re-build code which is not based on a VM if it's designed with portability in mind to start with.

This means that provided that multiplatform frameworks and device-independent coding practices are used, most programming language allow recompilation of code, so that it may run on a new architecture. This has nothing to do with the performance discussion, and I'm not talking about Assembly.

But this is more of a duck-taped workaround than a real solution. You move the complexity of adaptation to multiple nonstandard hardware to the VM or the compiler, which means making it much more complicated, and thus potentially slower, more buggy and in the case of a VM less secure.

This means that using VMs or framework/compiler tricks (which one you use doesn't matter for this part of the comment) doesn't solve the problem of not having a single standard architecture. Why ? Because the myriad of workarounds that this brings still have to get somewhere. You just put them in the VM or the compiler, close the black box, put the screws back, and pray that it will work.

This is deceptive reasoning, because you've still added code somewhere. Adding code in these areas generally means adding bugs and reducing generated code speed, in a classic example of bloat.

In some areas (mobile devices especially), VMs are also responsible for enforcing system security. Making them more complicated may also mean that this part is more prone to failure, making the VMs, and thus the OSs, less secure.

In short, no matter what development tools you use, you do want to have a standard hardware architecture. Because it simplifies the whole stack, and thus results in code that's more maintainable, which in turn means less bugs, better speed, and more secure VMs.

Edited 2011-02-15 12:50 UTC

Reply Parent Score: 1

moondevil Member since:
2005-07-08

Ah, ok.

Then please ignore my previous reply, I do agree with you.

Reply Parent Score: 2