This neatly demonstrates what's wrong with Chrome OS: Google forgot the hardware, as usual.
The fact that you can run Ubuntu on it without any hassle is exactly what's wrong. Chrome OS only makes sense if it: makes the hardware cheaper, makes the battery last longer, and lets you optimize the form factor (as in, more compact).
It makes sense it's tested on a machine which is way overspec for what they need, but it makes absolutely no sense to demonstrate the platform on it. It should have been something more like: an ARM, a tiny amount of storage (less than they have now), half thickness, half the battery (lower power consumption), and much more compact. This is just a netbook dressed up with a different OS. It should have been a new OS enabling more precisely targeted hardware. That seems to have been lost.
So I can't see why anyone would buy a device with Chrome OS on it, or convert one to it. If this was on hardware that was significantly cheaper than a netbook/laptop, people would buy into it. But this - an Atom and the associated mess of components with it - is going to be the same as everything else. So nobody will understand why they should buy a netbook that only browses.
And that's the theme from every reviewer, blogger and journalist: they don't get it. In it's current form, it just doesn't make any sense.
I frequently see hilarious convoys like this on i280: 6 cars following each other at 75mph leaving about 4ft between them. That's very likely to cause the last car in the convoy to bump into the car in front due to the amplifying effect of braking as it moves down the line. The first car could simply lift off the throttle a little. The next car has some reaction time, then has to brake as it's too late to just lift. The next car reacts and gets a little closer before braking harder. By the time this reaches the 6th car, the reaction time is larger than the gap, and there's a collision, and hopefully that happens at the 6th and not at the 2nd car in the convoy.
I do wonder what the ratio is for cops pulling over speeders to tailgaters. In my opinion tailgating is more dangerous, although most of the time the cause would be speeding too.
In California pulling over is required by law but only when people stack up behind you. So it's only when some dipshit like you is slowing down a whole BUNCH of people at once that they are legally obligated to pull over. Who cares if they want to go 5, 15, or 50 miles per hour faster than you? Why do you want them behind you anyway? I pull into a turnout at the least provocation, and if you had ever heard of a thing called the golden rule, you would too.
There's plenty of good reasons you'll find yourself in the left-most lane even if you're not the fastest car - it's interesting to see the responses from people assuming you'd only be doing that because you're a dick. In any case it is not an excuse to tailgate. It's dangerous to both cars as well as all those following as you're going to turn any minor one car incident into an unavoidable mess of two cars spinning across the highway, piling up those behind.
You could always shrug and just pass on the right, if you're in a state where it's legal, which in CA it is. In most of the cases you'd ever consider passing on the right, they just happen to be legal. See this: CA DMV 21754. I can only assume most drivers who tailgate me in CA when there's a completely empty freeway haven't read the code - I have because I moved there recently.
And while we're on the subject of what the Code actually says, the advice given in the CA code for being tailgated is to slow down. I remember the same applies in the UK code, but sadly not the pass-on-right (left in UK), unless it's the natural flow of congested traffic (I have a UK license too). It's so that braking distance is reduced to compensate for the prick behind you having basically no reaction time gap, and to lessen the speed of the two-car incident he may cause. So hey, it's actually against the recommended code of conduct on the road to maintain or increase speed if you're being tailgated. Again: why don't you just drive lawfully at a decent distance and/or change lane and pass?
And yes, CA is full of single lane roads with no passing lanes. I have yet to encounter a significant amount of time where the car in front didn't use a pull-out passing area. Sometimes they're not well-marked and they'll miss them - fair enough, I've certainly missed a few in poor visibility and held up traffic an extra half mile. In no case would I tailgate to "encourage" them to move over like some drivers do. That's the most absurdly dangerous and selfish thing you can do.
The ARM processor used by the iPhone 4 (Apple A4)...is the same than the used by the Samsung Wave (Samsung S5PC110A01).
At least according to an annalysis by cnet:...
No, that would be the same core not the same processor. You can see in the images linked that it's only a very small fraction of the total SoC that's common to both. It's a bit like calling a Xeon the same processor as a Core 2 Duo - it basically is, but that glosses over the gigantic details of everything else in the chip, and they're not even highly integrated examples.
Would I try and use exceptions and the like on a device with a harvard architecture with 4kb of code storage and 512bytes of ram? I think not, same with RAII etc, that's a lot over overhead for such a small device.
But this is something C++ is fundamentally designed to achieve: you can simply take your C program, sometimes tweak it a little, compile it in C++ mode and get almost the same code generated (because they're not identical compilers).
You can restrict which C++ constructs you use. There's no reason not to use classes if you were otherwise going to make a struct called "foo" and then a bunch of functions called "foo_init()" "foo_get_c()" etc. I see this all the time and it makes me do a facepalm for real.
Why, why, why would you restrict yourself to just plain C if you know exactly what these C++ constructs are going to do? Why would you use just plain C if that would mean less type safety, and more code? Why would you use just plain C if it got in the way of rapid development? Isn't that just language zealotry? These kind of development tools decisions are bad for you and others who use your code.
Most of the rest of your post I could agree with, but not this, there is a reason we code in c not c++ in embedded systems.
Who's "we"? I've been very successfully coding in C++ in embedded systems for over a decade, and I'm talking devices with anything from just a few KB of memory. If you don't understand what language structures do to code generation, you shouldn't be coding for embedded systems in either language. If you think C++ cannot be used for embedded systems, you don't understand the language at all.
Except C++ is not slower than C... It's actually equally fast, and can give a lot of performance optimizations with a fraction of the code needed to do the same on C.
It's even better than that. There's extra type checking and tighter rules on aliasing in C++ (unless you turn them off), so it can actually generate faster code. If you trivially convert a C program to the slightly less relaxed rules of C++, you should expect at least the same performance (if not, file a bug with your compiler provider), and often better.
I agree with the sentiment that anyone who thinks C++ is slower then C understands neither. It perfectly demonstrates their lack of understanding.
Fortran is alive and well. The 2008 standard just came out. Lots of people use it. Like C++, it is not the best language for every problem.
Hah, I'm not sure why I even wrote that now. You're right: it's still in active use for number-crunching by a large number of people.
It's because I've never used it in employment, ever. I get the same from folks who grew up with nothing but plain C or Java: they think C++ is dead because they never see it being used. They're surprised when they learn that practically everything they use on an hourly basis has C++ running at the heart of it.
I don't understand why Objective C is considered a good alternative to C++. Why not use both? You get the advantages of C++ type checking and encapsulation, while also having the runtime dynamic binding of Objective C.
Sadly, every time C++ is mentioned on Slashdot, we get a flood of unoriginal, boring comments about how bad it is. These usually come from people who either don't understand why the language exists, or have just plain never used it. But they heard it sucks somewhere and all the cool kids in the gang are saying it sucks, so they should join in the bullying.
So far, no language can replace it. If you don't understand this, you don't understand the class of programming problems it solves. C++ is a language designed for static compilation. It doesn't run in a VM. It isn't managed. This makes it great for system code (drivers, kernels), high performance, and "raw" environments. It is designed to be "wysiwyg": a line of code will translate to a sequence of unsurprising assembly if the programmer is experienced enough. It is designed to allow all that and still have high level features to reduce lines of code, improve type safety, and increase modularity.
There are good reasons it's still one of the most commonly used languages for games, kernels, embedded devices and high performance apps: it really is good at them. It's not just momentum and "lock-in". There have been plenty of languages with bigger backers that died because they were bad or just merely obsolete: Pascal, COBOL, Fortran as quick examples. Ada is still out there simply because the military backs it, and I wouldn't be surprised if that changes.
There are plenty of languages which are better in some domains: Java has the advantage of a managed VM, and Python has a neat syntax and can achieve a lot in few lines of code, as just two examples. However, you'd never write system code in Java or Python. You'd never write something high performance in Python. You'd never settle for the critical path of a high performance application being written in Java. Well, some people do, but they're either kidding themselves, or they don't really have a high performance application.
I really, really would love someone to design a language which fulfills everything C++ does, but at the same time fix up its sometimes arcane syntax and removing the shotguns constantly pointing at your feet. But until then, I'm happy with the language that makes my every day job that little bit easier. If you find that funny, then you're the target of Stroustrup's interview: you need to stop being foolish and give it a chance. I pity all the people I've met over the years who are convinced they know the "best" language and will stick with it forever. Or those who consider C better for every problem which C++ would be suited. Happy job hunting to them - that attitude will catch up with you some day.
The OP asked for the make of the CPU, in this context the CPU is the Hummingbird core. A SOC contains far more then a CPU thank you.
The OP asked no such thing. In what context is the CPU thought of as just the application core?
You might as well call a Xilinx Virtex 5 FPGA a PowerPC 440, because it has one in it. That would of course ignore the gigantic array of parallel multipliers and programmable logic it has. Calling the A4 a Samsung Hummingbird is disingenuous.
The CPU in the Iphone is the Samsung developed and made Hummingbird core (bog standard ARMv7).
If you think a smartphone SoC is defined just by the spec of the application core(s), which are a tiny fraction of its size, you've got it wrong. Hint: two SoCs with identical application cores can be vastly different in performance due to all that other stuff in the chip.
1. By definition, an internet service provider IS a man in the middle. To everyone whining about using this method - welcome to the real world. A man in the middle approach is the easiest one for the man in the middle to take.
No. By definition, an internet service provider is a bridge and router. It is not supposed to mess with your traffic. It is not supposed to be looking at these layers. Comcast has shown many times they don't care about that, though. They messed with all HTTP traffic by sending RST packets at you to upset bittorrent, also breaking normal web connections, and anything else which happened to be on port 80, e.g a lot of games. They messed with DNS to redirect to their own advertising sites for failed lookups. Now they're messing with HTTP to insert their banners. What will that do to traffic which happens to be HTTP but isn't web? News for you (and from your comment this probably IS news for you): the internet is not the web. That'll break bittorrent, games, maybe even iTunes, twitter apps, facebook apps, simple wget/curl transfers, and anything else that just happens to be HTTP on port 80.
2. Perhaps the ISP should just terminate the accounts of users of infected machines, since I am sure running an infected machine on the net is a violation of the TOS somewhere.
Yes, that's what they should actually be doing. It's in the ToS and if they have a machine connected which is degrading their network and/or being used for malicious attacks on other computers connected via their network, they are completely in their rights to disconnect them. This stinks of them trying to save money from support calls, sending out letters, hey even automated voicemail (which they do ANYWAY) or email.
OR they could just cut them off until they call tech support. OR they could filter the traffic, seeing as they've got enough of a stateful packet inspector in place to a) identify and b) modify your HTTP connections anyway. They just proved they can do it!
I WANT them to break the service and force people to upgrade, instead of continuing to spew their filthy zombie attacks all over the net. The more dramatic and attention getting, the better. Face it - your mission critical systems should not be on a residential account anyway, RIGHT? That's what the premium priced business packages are for... So what if grandpa has to click on some links to download some software and fix his machine before he can read his paper today. It's worth it to clean up the net.
I have a theory that anyone using the phrase "face it" actually knows that what they're suggested is absurd. You don't seem to understand exactly what's being done here. There's plenty of ways for them to solve this issue, and this tactic is just plain wrong.
Hell, this drops their "neutrality" altogether. They're actively inspecting traffic and inserting their own. I reckon that opens them up to being liable for it, too.
The mips-per-milliwatt is not the problem. The problem is the leakage current when in a sleep state higher than completely off.
I will change my question to: Is their SoC system design so bad that they can't power down all of the application cores? That's the whole point of having all those extra I/O and DSP cores: you don't need the "application" cores up and running when you're almost-idling playing an MP3 or something.
To be fair, it's an interesting idea having an extra core with lower leakage and more efficiency per clock, but it's at a high cost to software design. In the case of most SoCs I've used in the past decade, it's also unnecessary... but they seem to have issues with their design making it necessary.
"One or two" isn't the same as three. This chip has three application cores and six I/O or DSP cores like you describe.
It has two symmetric cores and a third of a different design which just happens to be compliant to the same spec (ARM-v7) and cache coherent. That doesn't make it "Tri-core". It's arbitrary how many they pick to claim it is. Hell, NVidia was claiming Tegra 2 was the world's first 7 core processor a while back, because they simply counted number of cores. You could probably run the OS on most of those cores, but you wouldn't. I suspect all customers of this Marvell chip will reject it for this purpose too, because they'll spot it for what it is: not a true tri-core.
The difference is that this one seems to be able to run all three cores as SMP with a single kernel being able to run on all of them. Traditionally the cores either run completely different systems, or the kernel runs on one along with general system tasks, whereas the other is dedicated to DSP-like work.
Except they're not Symmetric. If you go to Marvell's main site and look at the larger press release, it calls them - and note the use of "quote marks" here: "Heterogeneous multiprocessing". As in, not symmetric. Being cache coherent is nothing special these days.
This is just definitions. They have a 3rd core which is also ARM-v7 and happens to be cache coherent, so they're making the grand claim that it's a "Tri-core" (they also "quote mark" that because it's not strictly true). This is despite it being a different design to the 1.5GHz parts. Why stop there? Why not just claim it's a hexa-core or some other arbitrary number including all the other ARM-v7 cores in it?
I bet nobody even uses it in this configuration. Why would you want a third core which runs at a fraction the speed of the other two? What happens when your thread is scheduled onto it? Why wouldn't you just use it as an off-load core like everyone else on the planet does and save the scheduling overhead compared to the marginal gains? Why not just run the other cores at low speed in idle? Is their mips-per-milliwatt rating so bad they actually need the 3rd core for decent idling?
There's good reasons nobody else has done this. It's not because nobody has thought of it.
They're not the first, there's nothing different about this, and it's not even to market.
"Triple core" as they describe it is pretty standard stuff in the embedded/mobile world. You have one or two main "application" cores, and one or more I/O processing cores doing DSP, graphics, data processing, low rate data moves, etc. Just have a look at an NVidia Tegra 2, or even a Tegra 1 marketing slide and you'll see it has even more cores than this Marvell chip. Better yet, any Qualcomm 1GHz class cell phone chip, as those are at least actually shipping in quantity.
And hey, Tegra 2 hasn't even managed to get to market. The Marvell chip hasn't even got into a design! It's not even available for samples. How the fuck is that "to market"? There are even Tegra 2 based tablets being demoed at trade shows even if it's not available in quantity. Marvell has nothing whatsoever to show but that's not stopping them gloating about being first with something that blatantly isn't a first in any way.
Is there anything in this press release and submission which is accurate other than the clock speed? Is that even correct?
I think you are not using the definition of latency that most in the field would use.
Latency is how long it takes to process the data. Its a computer science type of thing. If you understand Knuth and his tape drive sorting examples, this is pretty obvious...
For example, heres a nice, simple, hopelessly useless codec that has almost exactly 100 ms of latency:
...
I've had great difficulty explaining this even to folks who write and maintain codecs, which is a fairly odd thing to encounter. There are fundamental design decisions about how you buffer, error correct and frame the data which can have a huge impact on latency. For example, a framing format which likes to bundle packets into pages will multiply latency by that amount. Using CRC/ECC creates a sequence point where all data up to there must be transmitted/received before it can be trusted to be decoded. (That last point is one of my biggest issues with Ogg's design, for example, which should really have separate CRC per packet, not page)
The most fundamental of all design decisions is trading off latency vs quality. The most obvious case is buffering an entire stream before deciding on the coefficients to most efficiently compress it. At the other end, you encounter issues with short bursts that need higher bitrate: if you don't buffer at all, you're stuck with fixed frame size regardless of content.
In fact, this is one of the reasons why broadcast video tends to be worse quality than stored/web content. They can't buffer up enough data to get better prediction.
I do like the example of the entire-message PTT and I will use that to illustrate the concept in future:)
I see your point about patents and the legal system. It really doesn't matter if you are right or wrong, all that matters is whether you can convince a jury. Most software patents are overly broad and/or too obvious, at least to people in the industry.
Actually, I'd say all that matters is whether you can convince both set of shareholders. They never actually want patent battles to go to jury, and most never get that far. It's pretty much a flip of the coin when it gets that far.
If the potential damage done to your future rating is greater than the cost of a license, you pay the license. It's trial by shareholder. Even then, it's mostly just players positioning themselves to get in on a cartel in a particular industry. Sadly, most shareholders don't understand The Game, and those that do understand it, know that the others don't.
It is written in legalese. And it is actually quite a bit stronger than a license as it does not require the beneficiary (you) to accept any license agreement.
Hmm, I consider myself corrected. It does not, however, answer what happens if the patents change hands either through bankruptcy or sale. In Sun's case they sold their patents along with the company. To be fair, there was never an explicit legal promise they wouldn't use them.
But that's not how software patents work. In the software patent world, it doesn't matter if you're wrong, right, have a legal claim, invented something, if it's even original, someone else's invention copied outright, or are simply just wasting everyone's time. You just need a pile of cash, lawyers, and a larger pile of cash in the hands of the party you sue. It's a meta-universe they live in. Any loophole will be exploited, and the aim is to either get a huge windfall (if you're a troll) or cross-license agreement (and become a made-company in cartel).
I can easily see Microsoft in 10-20 years getting sold, bankrupted, or whatever (no company lives forever so far). Where do the patents go, and does the promise go with them? Is there just enough doubt that it means they can be trouble anyway?
It doesn't matter how much they assure that they won't go after free implementations. Without it written in legalese, irrevocable, it's a worthless statement.
What happens in, say, 5 years if/when Microsoft is feeling the pressure of competition? Let's say they're going bankrupt. Sound unlikely? Well, replace 5 years with 20 years. They'll find they have this lovely patent pool full of wonderful words which are potentially worth billions of dollars. Like every single example I can think of in the history of computing since 1980, of course they'll sue using their patents to draw out their death.
The same applies to any of the big names: Google (you're next), Oracle (already doing it), IBM (somehow never died), Sun (via Oracle), for starters. The nuclear weapon analogy holds nicely here too. The software patent mess is Mutually Assured Destruction. But amassing them and then saying "We won't use them"... what happens when your state collapses? Where do they go?
You're completely missing the point, I thought I had made crystal clear.
I don't think that's anything out of the ordinary. Get a prototype working, impress the chiefs, get more funding for a bigger team. What's important is that it now builds on all those architectures.
The binary content of every web page that uses NaCl needs to be rebuilt for every new architecture. You don't need to recompile and ship a new version of slashdot.org's HTML every time someone makes a new processor. It's ridiculous to even suggest this is worthy of being a web standard.
If someone invents a new processor, it will NOT work with NaCl, even after NaCl is ported. Every single developer who uses NaCl will need to rebuild for that extra architecture, and ship their web pages again. What happens when the list is large? Well, folks stop building for the minority. Hell I bet nobody even bothers shipping the ARM version because there's so few people that can run it. Again, how is that in any way compatible with being a web standard? It's fucking ridiculous. This is NOT how to make platform-independent content.
And without java. And probably at the right time, given the herculean marketing department google has, with a business model even.
Sadly, I think it is only because of Google's herculean marketing department that this ever got off the starting blocks. Thankfully nobody except their own internal teams use it, because they've all spotted how insanely dumb an idea it is.
Yes, the LLVM variant solves most of my above complaints, but I contend that they should never have introduced the non-LLVM variant in the first place. It's harmful. It's also not clear exactly what niche the LLVM variant fills which a JVM doesn't already.
Native Client is a nice piece of research but it should never have been suggested for widespread use on the web. It ties web content to a particular type of CPU, which is hilariously dumb as far as cross-platform standards go. It's most telling that to begin with it wouldn't even run on 64 bit Intel/AMD boxes. And ARM? An afterthought (although now tackled). Nice fat binaries you get from that, and not to mention you have to compile it for many architectures.
And even more telling is the LLVM version (which is what should have been done in the first place) is called 'Portable Native Client'. Guess that makes the normal one the 'Non-Portable Native Client'? Bonus points for spotting the fact they just re-invented Java Applets, only slimmer.
Ross Rubin, an analyst at NPD Group, reminds us how Flash ushered in video on Web pages
No, I would have to remind him that he probably wasn't around when there were plenty of other ways to get video on Web pages. There was the QuickTime plugin for starters. There were plenty of rtsp players, of which RealPlayer was most prominent (but crappy). Flash was not first, not by a long way. If he meant interactive, sure. If he meant with lots of embedded controls, sure. But that's pretty selective, and in the era we're talking about, embedded controls weren't a killer feature.
To be fair, most of the other solutions were pretty lame. Not that Flash isn't lame either - it's just somewhat less lame an attempt. That's its legacy: it's not as shit as RealPlayer.
Slashdot Mirror
This neatly demonstrates what's wrong with Chrome OS: Google forgot the hardware, as usual.
The fact that you can run Ubuntu on it without any hassle is exactly what's wrong. Chrome OS only makes sense if it: makes the hardware cheaper, makes the battery last longer, and lets you optimize the form factor (as in, more compact).
It makes sense it's tested on a machine which is way overspec for what they need, but it makes absolutely no sense to demonstrate the platform on it. It should have been something more like: an ARM, a tiny amount of storage (less than they have now), half thickness, half the battery (lower power consumption), and much more compact. This is just a netbook dressed up with a different OS. It should have been a new OS enabling more precisely targeted hardware. That seems to have been lost.
So I can't see why anyone would buy a device with Chrome OS on it, or convert one to it. If this was on hardware that was significantly cheaper than a netbook/laptop, people would buy into it. But this - an Atom and the associated mess of components with it - is going to be the same as everything else. So nobody will understand why they should buy a netbook that only browses.
And that's the theme from every reviewer, blogger and journalist: they don't get it. In it's current form, it just doesn't make any sense.
I frequently see hilarious convoys like this on i280: 6 cars following each other at 75mph leaving about 4ft between them. That's very likely to cause the last car in the convoy to bump into the car in front due to the amplifying effect of braking as it moves down the line. The first car could simply lift off the throttle a little. The next car has some reaction time, then has to brake as it's too late to just lift. The next car reacts and gets a little closer before braking harder. By the time this reaches the 6th car, the reaction time is larger than the gap, and there's a collision, and hopefully that happens at the 6th and not at the 2nd car in the convoy.
I do wonder what the ratio is for cops pulling over speeders to tailgaters. In my opinion tailgating is more dangerous, although most of the time the cause would be speeding too.
In California pulling over is required by law but only when people stack up behind you. So it's only when some dipshit like you is slowing down a whole BUNCH of people at once that they are legally obligated to pull over. Who cares if they want to go 5, 15, or 50 miles per hour faster than you? Why do you want them behind you anyway? I pull into a turnout at the least provocation, and if you had ever heard of a thing called the golden rule, you would too.
There's plenty of good reasons you'll find yourself in the left-most lane even if you're not the fastest car - it's interesting to see the responses from people assuming you'd only be doing that because you're a dick. In any case it is not an excuse to tailgate. It's dangerous to both cars as well as all those following as you're going to turn any minor one car incident into an unavoidable mess of two cars spinning across the highway, piling up those behind.
You could always shrug and just pass on the right, if you're in a state where it's legal, which in CA it is. In most of the cases you'd ever consider passing on the right, they just happen to be legal. See this: CA DMV 21754. I can only assume most drivers who tailgate me in CA when there's a completely empty freeway haven't read the code - I have because I moved there recently.
And while we're on the subject of what the Code actually says, the advice given in the CA code for being tailgated is to slow down. I remember the same applies in the UK code, but sadly not the pass-on-right (left in UK), unless it's the natural flow of congested traffic (I have a UK license too). It's so that braking distance is reduced to compensate for the prick behind you having basically no reaction time gap, and to lessen the speed of the two-car incident he may cause. So hey, it's actually against the recommended code of conduct on the road to maintain or increase speed if you're being tailgated. Again: why don't you just drive lawfully at a decent distance and/or change lane and pass?
And yes, CA is full of single lane roads with no passing lanes. I have yet to encounter a significant amount of time where the car in front didn't use a pull-out passing area. Sometimes they're not well-marked and they'll miss them - fair enough, I've certainly missed a few in poor visibility and held up traffic an extra half mile. In no case would I tailgate to "encourage" them to move over like some drivers do. That's the most absurdly dangerous and selfish thing you can do.
The ARM processor used by the iPhone 4 (Apple A4)...is the same than the used by the Samsung Wave (Samsung S5PC110A01).
At least according to an annalysis by cnet: ...
No, that would be the same core not the same processor. You can see in the images linked that it's only a very small fraction of the total SoC that's common to both. It's a bit like calling a Xeon the same processor as a Core 2 Duo - it basically is, but that glosses over the gigantic details of everything else in the chip, and they're not even highly integrated examples.
Then they worked, and are continuing to work.
Dog barks at postman. Postman comes and goes away. Dog keeps barking at postman every day. Seems to work.
Would I try and use exceptions and the like on a device with a harvard architecture with 4kb of code storage and 512bytes of ram? I think not, same with RAII etc, that's a lot over overhead for such a small device.
But this is something C++ is fundamentally designed to achieve: you can simply take your C program, sometimes tweak it a little, compile it in C++ mode and get almost the same code generated (because they're not identical compilers).
You can restrict which C++ constructs you use. There's no reason not to use classes if you were otherwise going to make a struct called "foo" and then a bunch of functions called "foo_init()" "foo_get_c()" etc. I see this all the time and it makes me do a facepalm for real.
Why, why, why would you restrict yourself to just plain C if you know exactly what these C++ constructs are going to do? Why would you use just plain C if that would mean less type safety, and more code? Why would you use just plain C if it got in the way of rapid development? Isn't that just language zealotry? These kind of development tools decisions are bad for you and others who use your code.
Most of the rest of your post I could agree with, but not this, there is a reason we code in c not c++ in embedded systems.
Who's "we"? I've been very successfully coding in C++ in embedded systems for over a decade, and I'm talking devices with anything from just a few KB of memory. If you don't understand what language structures do to code generation, you shouldn't be coding for embedded systems in either language. If you think C++ cannot be used for embedded systems, you don't understand the language at all.
Except C++ is not slower than C... It's actually equally fast, and can give a lot of performance optimizations with a fraction of the code needed to do the same on C.
It's even better than that. There's extra type checking and tighter rules on aliasing in C++ (unless you turn them off), so it can actually generate faster code. If you trivially convert a C program to the slightly less relaxed rules of C++, you should expect at least the same performance (if not, file a bug with your compiler provider), and often better.
I agree with the sentiment that anyone who thinks C++ is slower then C understands neither. It perfectly demonstrates their lack of understanding.
Fortran is alive and well. The 2008 standard just came out. Lots of people use it. Like C++, it is not the best language for every problem.
Hah, I'm not sure why I even wrote that now. You're right: it's still in active use for number-crunching by a large number of people.
It's because I've never used it in employment, ever. I get the same from folks who grew up with nothing but plain C or Java: they think C++ is dead because they never see it being used. They're surprised when they learn that practically everything they use on an hourly basis has C++ running at the heart of it.
I don't understand why Objective C is considered a good alternative to C++. Why not use both? You get the advantages of C++ type checking and encapsulation, while also having the runtime dynamic binding of Objective C.
Sadly, every time C++ is mentioned on Slashdot, we get a flood of unoriginal, boring comments about how bad it is. These usually come from people who either don't understand why the language exists, or have just plain never used it. But they heard it sucks somewhere and all the cool kids in the gang are saying it sucks, so they should join in the bullying.
So far, no language can replace it. If you don't understand this, you don't understand the class of programming problems it solves. C++ is a language designed for static compilation. It doesn't run in a VM. It isn't managed. This makes it great for system code (drivers, kernels), high performance, and "raw" environments. It is designed to be "wysiwyg": a line of code will translate to a sequence of unsurprising assembly if the programmer is experienced enough. It is designed to allow all that and still have high level features to reduce lines of code, improve type safety, and increase modularity.
There are good reasons it's still one of the most commonly used languages for games, kernels, embedded devices and high performance apps: it really is good at them. It's not just momentum and "lock-in". There have been plenty of languages with bigger backers that died because they were bad or just merely obsolete: Pascal, COBOL, Fortran as quick examples. Ada is still out there simply because the military backs it, and I wouldn't be surprised if that changes.
There are plenty of languages which are better in some domains: Java has the advantage of a managed VM, and Python has a neat syntax and can achieve a lot in few lines of code, as just two examples. However, you'd never write system code in Java or Python. You'd never write something high performance in Python. You'd never settle for the critical path of a high performance application being written in Java. Well, some people do, but they're either kidding themselves, or they don't really have a high performance application.
I really, really would love someone to design a language which fulfills everything C++ does, but at the same time fix up its sometimes arcane syntax and removing the shotguns constantly pointing at your feet. But until then, I'm happy with the language that makes my every day job that little bit easier. If you find that funny, then you're the target of Stroustrup's interview: you need to stop being foolish and give it a chance. I pity all the people I've met over the years who are convinced they know the "best" language and will stick with it forever. Or those who consider C better for every problem which C++ would be suited. Happy job hunting to them - that attitude will catch up with you some day.
The OP asked for the make of the CPU, in this context the CPU is the Hummingbird core. A SOC contains far more then a CPU thank you.
The OP asked no such thing. In what context is the CPU thought of as just the application core?
You might as well call a Xilinx Virtex 5 FPGA a PowerPC 440, because it has one in it. That would of course ignore the gigantic array of parallel multipliers and programmable logic it has. Calling the A4 a Samsung Hummingbird is disingenuous.
The CPU in the Iphone is the Samsung developed and made Hummingbird core (bog standard ARMv7).
If you think a smartphone SoC is defined just by the spec of the application core(s), which are a tiny fraction of its size, you've got it wrong. Hint: two SoCs with identical application cores can be vastly different in performance due to all that other stuff in the chip.
Let's look at the following:
1. By definition, an internet service provider IS a man in the middle. To everyone whining about using this method - welcome to the real world. A man in the middle approach is the easiest one for the man in the middle to take.
No. By definition, an internet service provider is a bridge and router. It is not supposed to mess with your traffic. It is not supposed to be looking at these layers. Comcast has shown many times they don't care about that, though. They messed with all HTTP traffic by sending RST packets at you to upset bittorrent, also breaking normal web connections, and anything else which happened to be on port 80, e.g a lot of games. They messed with DNS to redirect to their own advertising sites for failed lookups. Now they're messing with HTTP to insert their banners. What will that do to traffic which happens to be HTTP but isn't web? News for you (and from your comment this probably IS news for you): the internet is not the web. That'll break bittorrent, games, maybe even iTunes, twitter apps, facebook apps, simple wget/curl transfers, and anything else that just happens to be HTTP on port 80.
2. Perhaps the ISP should just terminate the accounts of users of infected machines, since I am sure running an infected machine on the net is a violation of the TOS somewhere.
Yes, that's what they should actually be doing. It's in the ToS and if they have a machine connected which is degrading their network and/or being used for malicious attacks on other computers connected via their network, they are completely in their rights to disconnect them. This stinks of them trying to save money from support calls, sending out letters, hey even automated voicemail (which they do ANYWAY) or email.
OR they could just cut them off until they call tech support. OR they could filter the traffic, seeing as they've got enough of a stateful packet inspector in place to a) identify and b) modify your HTTP connections anyway. They just proved they can do it!
I WANT them to break the service and force people to upgrade, instead of continuing to spew their filthy zombie attacks all over the net. The more dramatic and attention getting, the better. Face it - your mission critical systems should not be on a residential account anyway, RIGHT? That's what the premium priced business packages are for... So what if grandpa has to click on some links to download some software and fix his machine before he can read his paper today. It's worth it to clean up the net.
I have a theory that anyone using the phrase "face it" actually knows that what they're suggested is absurd. You don't seem to understand exactly what's being done here. There's plenty of ways for them to solve this issue, and this tactic is just plain wrong.
Hell, this drops their "neutrality" altogether. They're actively inspecting traffic and inserting their own. I reckon that opens them up to being liable for it, too.
The mips-per-milliwatt is not the problem. The problem is the leakage current when in a sleep state higher than completely off.
I will change my question to: Is their SoC system design so bad that they can't power down all of the application cores? That's the whole point of having all those extra I/O and DSP cores: you don't need the "application" cores up and running when you're almost-idling playing an MP3 or something.
To be fair, it's an interesting idea having an extra core with lower leakage and more efficiency per clock, but it's at a high cost to software design. In the case of most SoCs I've used in the past decade, it's also unnecessary... but they seem to have issues with their design making it necessary.
"One or two" isn't the same as three. This chip has three application cores and six I/O or DSP cores like you describe.
It has two symmetric cores and a third of a different design which just happens to be compliant to the same spec (ARM-v7) and cache coherent. That doesn't make it "Tri-core". It's arbitrary how many they pick to claim it is. Hell, NVidia was claiming Tegra 2 was the world's first 7 core processor a while back, because they simply counted number of cores. You could probably run the OS on most of those cores, but you wouldn't. I suspect all customers of this Marvell chip will reject it for this purpose too, because they'll spot it for what it is: not a true tri-core.
The difference is that this one seems to be able to run all three cores as SMP with a single kernel being able to run on all of them. Traditionally the cores either run completely different systems, or the kernel runs on one along with general system tasks, whereas the other is dedicated to DSP-like work.
Except they're not Symmetric. If you go to Marvell's main site and look at the larger press release, it calls them - and note the use of "quote marks" here: "Heterogeneous multiprocessing". As in, not symmetric. Being cache coherent is nothing special these days.
This is just definitions. They have a 3rd core which is also ARM-v7 and happens to be cache coherent, so they're making the grand claim that it's a "Tri-core" (they also "quote mark" that because it's not strictly true). This is despite it being a different design to the 1.5GHz parts. Why stop there? Why not just claim it's a hexa-core or some other arbitrary number including all the other ARM-v7 cores in it?
I bet nobody even uses it in this configuration. Why would you want a third core which runs at a fraction the speed of the other two? What happens when your thread is scheduled onto it? Why wouldn't you just use it as an off-load core like everyone else on the planet does and save the scheduling overhead compared to the marginal gains? Why not just run the other cores at low speed in idle? Is their mips-per-milliwatt rating so bad they actually need the 3rd core for decent idling?
There's good reasons nobody else has done this. It's not because nobody has thought of it.
They're not the first, there's nothing different about this, and it's not even to market.
"Triple core" as they describe it is pretty standard stuff in the embedded/mobile world. You have one or two main "application" cores, and one or more I/O processing cores doing DSP, graphics, data processing, low rate data moves, etc. Just have a look at an NVidia Tegra 2, or even a Tegra 1 marketing slide and you'll see it has even more cores than this Marvell chip. Better yet, any Qualcomm 1GHz class cell phone chip, as those are at least actually shipping in quantity.
And hey, Tegra 2 hasn't even managed to get to market. The Marvell chip hasn't even got into a design! It's not even available for samples. How the fuck is that "to market"? There are even Tegra 2 based tablets being demoed at trade shows even if it's not available in quantity. Marvell has nothing whatsoever to show but that's not stopping them gloating about being first with something that blatantly isn't a first in any way.
Is there anything in this press release and submission which is accurate other than the clock speed? Is that even correct?
I think you are not using the definition of latency that most in the field would use.
Latency is how long it takes to process the data. Its a computer science type of thing. If you understand Knuth and his tape drive sorting examples, this is pretty obvious...
For example, heres a nice, simple, hopelessly useless codec that has almost exactly 100 ms of latency:
I've had great difficulty explaining this even to folks who write and maintain codecs, which is a fairly odd thing to encounter. There are fundamental design decisions about how you buffer, error correct and frame the data which can have a huge impact on latency. For example, a framing format which likes to bundle packets into pages will multiply latency by that amount. Using CRC/ECC creates a sequence point where all data up to there must be transmitted/received before it can be trusted to be decoded. (That last point is one of my biggest issues with Ogg's design, for example, which should really have separate CRC per packet, not page)
The most fundamental of all design decisions is trading off latency vs quality. The most obvious case is buffering an entire stream before deciding on the coefficients to most efficiently compress it. At the other end, you encounter issues with short bursts that need higher bitrate: if you don't buffer at all, you're stuck with fixed frame size regardless of content.
In fact, this is one of the reasons why broadcast video tends to be worse quality than stored/web content. They can't buffer up enough data to get better prediction.
I do like the example of the entire-message PTT and I will use that to illustrate the concept in future :)
I see your point about patents and the legal system. It really doesn't matter if you are right or wrong, all that matters is whether you can convince a jury. Most software patents are overly broad and/or too obvious, at least to people in the industry.
Actually, I'd say all that matters is whether you can convince both set of shareholders. They never actually want patent battles to go to jury, and most never get that far. It's pretty much a flip of the coin when it gets that far.
If the potential damage done to your future rating is greater than the cost of a license, you pay the license. It's trial by shareholder. Even then, it's mostly just players positioning themselves to get in on a cartel in a particular industry. Sadly, most shareholders don't understand The Game, and those that do understand it, know that the others don't.
It is written in legalese. And it is actually quite a bit stronger than a license as it does not require the beneficiary (you) to accept any license agreement.
Hmm, I consider myself corrected. It does not, however, answer what happens if the patents change hands either through bankruptcy or sale. In Sun's case they sold their patents along with the company. To be fair, there was never an explicit legal promise they wouldn't use them.
But that's not how software patents work. In the software patent world, it doesn't matter if you're wrong, right, have a legal claim, invented something, if it's even original, someone else's invention copied outright, or are simply just wasting everyone's time. You just need a pile of cash, lawyers, and a larger pile of cash in the hands of the party you sue. It's a meta-universe they live in. Any loophole will be exploited, and the aim is to either get a huge windfall (if you're a troll) or cross-license agreement (and become a made-company in cartel).
I can easily see Microsoft in 10-20 years getting sold, bankrupted, or whatever (no company lives forever so far). Where do the patents go, and does the promise go with them? Is there just enough doubt that it means they can be trouble anyway?
It doesn't matter how much they assure that they won't go after free implementations. Without it written in legalese, irrevocable, it's a worthless statement.
What happens in, say, 5 years if/when Microsoft is feeling the pressure of competition? Let's say they're going bankrupt. Sound unlikely? Well, replace 5 years with 20 years. They'll find they have this lovely patent pool full of wonderful words which are potentially worth billions of dollars. Like every single example I can think of in the history of computing since 1980, of course they'll sue using their patents to draw out their death.
The same applies to any of the big names: Google (you're next), Oracle (already doing it), IBM (somehow never died), Sun (via Oracle), for starters. The nuclear weapon analogy holds nicely here too. The software patent mess is Mutually Assured Destruction. But amassing them and then saying "We won't use them"... what happens when your state collapses? Where do they go?
You're completely missing the point, I thought I had made crystal clear.
I don't think that's anything out of the ordinary. Get a prototype working, impress the chiefs, get more funding for a bigger team. What's important is that it now builds on all those architectures.
The binary content of every web page that uses NaCl needs to be rebuilt for every new architecture. You don't need to recompile and ship a new version of slashdot.org's HTML every time someone makes a new processor. It's ridiculous to even suggest this is worthy of being a web standard.
If someone invents a new processor, it will NOT work with NaCl, even after NaCl is ported. Every single developer who uses NaCl will need to rebuild for that extra architecture, and ship their web pages again. What happens when the list is large? Well, folks stop building for the minority. Hell I bet nobody even bothers shipping the ARM version because there's so few people that can run it. Again, how is that in any way compatible with being a web standard? It's fucking ridiculous. This is NOT how to make platform-independent content.
And without java. And probably at the right time, given the herculean marketing department google has, with a business model even.
Sadly, I think it is only because of Google's herculean marketing department that this ever got off the starting blocks. Thankfully nobody except their own internal teams use it, because they've all spotted how insanely dumb an idea it is.
Yes, the LLVM variant solves most of my above complaints, but I contend that they should never have introduced the non-LLVM variant in the first place. It's harmful. It's also not clear exactly what niche the LLVM variant fills which a JVM doesn't already.
Native Client is a nice piece of research but it should never have been suggested for widespread use on the web. It ties web content to a particular type of CPU, which is hilariously dumb as far as cross-platform standards go. It's most telling that to begin with it wouldn't even run on 64 bit Intel/AMD boxes. And ARM? An afterthought (although now tackled). Nice fat binaries you get from that, and not to mention you have to compile it for many architectures.
And even more telling is the LLVM version (which is what should have been done in the first place) is called 'Portable Native Client'. Guess that makes the normal one the 'Non-Portable Native Client'? Bonus points for spotting the fact they just re-invented Java Applets, only slimmer.
Ross Rubin, an analyst at NPD Group, reminds us how Flash ushered in video on Web pages
No, I would have to remind him that he probably wasn't around when there were plenty of other ways to get video on Web pages. There was the QuickTime plugin for starters. There were plenty of rtsp players, of which RealPlayer was most prominent (but crappy). Flash was not first, not by a long way. If he meant interactive, sure. If he meant with lots of embedded controls, sure. But that's pretty selective, and in the era we're talking about, embedded controls weren't a killer feature.
To be fair, most of the other solutions were pretty lame. Not that Flash isn't lame either - it's just somewhat less lame an attempt. That's its legacy: it's not as shit as RealPlayer.