I have a slow AMD E-350 (1.6GHz, dual core, low power chip) in the machine I use as a media centre. With the original MESA software fallback, I got about 3 frames per second in the UI. It was totally unusable. After FreeBSD gained support for the GPU, I tried it again and got about 20-30fps. This seemed a bit low, and I discovered that I'd misconfigured it and it was still using the software fallback, only now it was using LLVMPipe. I don't know how much faster the GPU actually is, because at 60fps it hits vsync and doesn't try to go faster, though CPU usage drops from 100% to around 10% (of one core). Of course, this CPU doesn't have AVX, so won't benefit from this code.
The release announcement has a couple more details. This new back end is optimised for workloads with large vertex counts but simple shaders and for machines with a lot of cores. There are a lot of ways that you can make OpenGL shaders faster if you're optimising for the simple case. Half Life 1 works on a fixed-function pipeline, so should be fast on this. Half Life 2 uses a bit more by way of shaders, but possibly not enough to cause it to struggle. Stuff that runs well on a GPU is likely to also run well on multiple cores, if you get the synchronisation right, but the existing LLVM pipe uses a single thread.
My main interest in this is whether you can turn off the GPU entirely for normal compositing desktop workloads and whether it will make a big difference to the power consumption if you do. Compositing desktops generally do a lot of simple compositing, but have very simple shaders and quite simple geometry. I'd be very interested to see whether doing this on the AVX pipelines is cheaper than having an entire separate core doing the work, especially given that the GPU core is generally optimised for more complex graphical workloads.
People who don't want to have a device that spends 100% of its time connected to a network and has remotely exploitable vulnerabilities. Try reading this paper for an overview of how long Android phones go without vulnerabilities (note that the latest Stagefright exploit, that affects all versions of Android since 1.5 was discovered after the paper).
I do agree that Google should crack down on their OEM partners' shoddy support
Google created the problem. The Android ecosystem has lots of competition from hardware vendors, so margins are razor thin. The only company that makes money from it is the company that takes a cut of all app sales (i.e. Google on most phones, Amazon on phones with their market installed and I think Samsung also has their own app store).
Google could easily have fixed this by having some kind of revenue-sharing agreement with vendors that ship the Google Play store: if you're getting 5% of all app sales (still leaving Google with 25%), then you've suddenly got an incentive to ensure that the phone that you sold two years ago still receives the updates that it requires to run the latest apps. Particularly if the market will detect vulnerable versions of Android and refuse to install apps that use the vulnerable subsystems...
I do! But the problem for these people (as with professional sports players) is that they get paid for something that is superficially like their hobby, but isn't really the same. It's the hobby with the enjoyment removed and replaced with a hyper-competitive need to win.
And the code written by the top programmer in his 40s will be so simple that no one will be impressed by it, because it's obvious and only a couple of hundred lines.
I've seen this post before, yet I know of several companies in San Diego that employ people in their 40s and 50s, do embedded development, and are hiring. I think almost everyone I know at Qualcomm's site there is over 40. I think the clue is here:
mostly my resume submissions are ignored
How did you get to 50 and not know other people doing embedded development? Especially if you were working on Linux, where it's a big community. Most people hiring for this kind of skill set know that it's a waste of time to go through agencies and recommendations from existing (and former) employees are the best way of hiring.
Nonsense. That's only true if you're measuring income in dollars as if that's some absolute and not adjusting for local cost of living. Cost of living varies hugely across the world. Even within a relatively small country country, I moved from somewhere in the UK where my cost of living was around £10K/year living very comfortably to somewhere on the other side of the country where that won't even pay my rent.
Someone else who is also a billionaire – they don't want anything from you!
Anyone who claims that has no understanding of the psychology of the majority of billionaires. See Carly Fiorina and her 'good friend' Steve Jobs for an example. If you're a billionaire, then other billionaires are the ones that have the most of what you value and therefore the best targets. Stealing from the poor is far more effort - you need to steal from loads of them.
Which is in grossly overvalued like most other damned startups.
The value of disruptive startups is measured differently to established businesses. If this company has a 10% chance of growing to control a $100bn industry, then it's valued correctly. That doesn't mean that the most likely outcome isn't that it will crash and burn, it means that it's a the high-risk, high-returns end of investments.
Why? The web is meant to be client-agnostic. I use different browsers on mobile and desktop. The main thing that I want from a web browser (beyond actually working) is to integrate cleanly with the host environment and that's far more likely in a browser that's developed for a single platform than one that's written to be portable. For example, Chrome 'runs' on OS X, but it doesn't integrate properly with the system keychain, so you end up with passwords scattered between two credential stores. Chrome and Firefox are both cross-platform, yet have quite different feature sets and levels of integration on different platforms.
If security is a priority, then I'd want to be able to ensure that, once a known vulnerability is patched, the update needs to be installed in only one place.
Java can take advantage of some, though most existing JVMs don't. A few research projects do. If we're talking about the language, rather than the language implementation (on the basis that the latter can improve without changing the source), then any language that makes field order undefined can take advantage of these things. If the language has primitive integer types, then exploiting SIMD in its equivalent of structs is much easier.
For concurrency, you want a language that either has garbage collection, or one that strictly enforces the shared xor mutable rule. Garbage collection means that you can have concurrent mutation with no synchronisation, though you pay a penalty when it comes to actually running the collection. Pony takes the latter route (as does Erlang, though via a degenerate case of having no mutable state other than the process dictionary).
A modern language should be designed from the ground up with three primary concerns:
Security and, in particular, compartmentalisation. It should be easy to take a program and split a part of it into a separate process with limited rights (i.e. all communication between parts of the program must be explicit). Erlang meets this requirement, few other languages do.
Error handling must be easy. This is really hard to get right. Common Lisp had some nice models for error handling, but most later languages have been fairly horrible. Maybe types are one mechanism for this, but they're only part of the solution. It should be obvious when reading code in the language that error handling has been omitted and the error-handing paths should be easy to test (because a huge number of bugs end up there if they're not).
Concurrency. With modern systems (even cache-coherent SMP systems), this means minimising sharing of mutable data and providing primitives for explicit communication. A few languages (Erlang, Go, and even Rust) manage this to a degree.
I look forward to someone developing a modern language (I have some sketches of a design, but nothing concrete - hopefully someone with more free time than me will get to it before I do). Aside from these goals, the language should be designed for modern tools (e.g. static analysis should be part of the normal development cycle), should have some form of static elaboration (more in the Bluespec style than C++ templates) and should interface cleanly with legacy code in C/C++ (though should have the option of running this code in a separate process, for security).
In 2012, around 80% of all security vulnerabilities exploited in the wild came from some memory safety error. If you use Java, or you use C++ with strict discipline about the use of shared_ptr / unique_ptr, then you immediately remove the possibility of these kinds of vulnerability. You may still fail to sanitise inputs and allow other kinds of high-level vulnerability, but at least eliminating 80% of vulnerabilities would be a nice start.
So no matter what we are going to attach cars and the "street" to the Internet? That's a good idea?
Of course it's a good idea! It will allow more tracking to sell even better-targetted advertising spots. And Google will keep us secure. After all, they've done such a good job with Android...
The total time to parse about 5-10MB of C includes, on a modern machine, is a few tens of milliseconds. It has almost no impact on a modern C program - if you're compiling with optimisation, you'll spend far longer in the optimisers than in the parser.
C++ is different, because it's not just the parsing, it's also the template instantiation. This is where you burn time. You also lose a lot if you have definitions in the headers where you have generate code, then you'll spend time parsing, more time generating your compiler's intermediate representation, more time optimising it, more time generating code, and then even more time in the linker throwing it away.
An excellent engineer can write excellent C, but a poor engineer can overflow buffers and leave dangling pointers hanging around... but not in Rust.
A poor developer will write C code that doesn't work at all. A mediocre developer will write C code that works, but is rife with security vulnerabilities. An excellent developer will write C code that needs an excellent attacker to exploit. Unfortunately, the world has quite a lot of excellent attackers in it.
It's optimised for speed, as long as your target is basically a fast PDP-11. C does not allow the compiler to rearrange data layouts, which makes it hard to take advantage of SIMD or to avoid false sharing. C makes it very hard to statically reason about memory ownership, requiring a defensive programming style with redundant operations when writing multithreaded code. C only recently had a memory model for concurrent accesses at all and so most multithreaded C programs contain undefined behaviour.
As long as the conventions are understood and consistent, then who cares if all strings have to be null terminated or if the strings returned as static, garbage collected or must be free'd?
That information has to be encoded somewhere. If your convention is that every char* parameter is a null-terminated C string that must be copied by the callee if it is expected to persist beyond the duration of the function call, then that's great (you'd better be really consistent about not using char* for arbitrary data though). Similarly, if every pointer that is returned needs freeing by the caller, then that's also fine, and you can machine-generate the wrappers on that assumption.
If you're going to create a metamodel with the primary goal of allowing wrappers from other languages, then you need to think about these things. EFL now has a metamodel intended for FFI, and it doesn't think about these things. Functions take char* arguments (and the metamodel describes their type solely as char*), which may be null-termianted C strings or blobs of data with the length encoded somewhere else. They may be held by the callee and freed later, or the caller may be responsible for freeing them. None of this information is encoded in anything machine readable.
This is repeated a lot, but it's not actually backed up by evidence. Few societies ever go through a significant barter phase. Most move from a gift economy to some form of currency without barter playing a significant role in between.
Voter turnout, for one. Fix may be too strong a word, I would go with address.
The problem is not the number of people that vote, it's the number of informed people that vote. And, by that, I don't mean educated people who have spent a long time studying the issues, I mean people who have a basic clue as to what their candidates views are (beyond 'wears a {red,blue} ribbon'). Forcing more people to turn up doesn't fix this, it can only be addressed by having an impartial media that's willing to cover the candidates public and private opinions without fear of reprisals.
Often they just say 'wealth redistribution', which is the phrase that annoys me more than any other in political discussions. The people who say it are always implicitly in favour of wealth redistribution in one direction and often opposed to things that slow it, not just things that might reverse it. If I have $1m, and I invest it at a return 1% above the rate of inflation (not so hard when you have $1m), then I make $10K/year just from having money. If I have $10m and I make the same investments, then I'm making $100K/year, which is more than most people who work for a living, again just from starting with capital.
The average net worth of US senators in 2011 (I couldn't find newer figures) was $14m, for senators it was $7m (before anyone jumps in with partisan claims, the average for Republicans was higher in the Senate, but lower in the House). These people are earning more from their investments than most of their constituents. They're all - on both sides of the aisle - very much in favour of wealth redistribution, as long as that wealth keeps flowing to them.
Because the emergency dialler requirement is not intended solely for the person who owns the phone. It's expected that any telephone that you pick up (land line or mobile) will work for emergency calls. This is also why landlines can still make emergency calls even if they are nominally disconnected by the phone company.
I'm not particularly familiar with either company's process, but it's been a couple of generations since you could actually make meaningful comparisons based on the quoted nm size, because everyone has different smallest features that they measure when deciding that they are Xnm. That said, we passed the end of Dennard scaling a long time ago. You'd expect the same chip to be consuming about as much power, be slightly more able to dissipate the heat. It may also have less leakage, though that depends on a number of other factors.
His point about ownership is spot on, however. Newer EFL is starting to use an IDL so that it can integrate with other languages. I talked to the designer of it at FOSDEM. The idea that your IDL couldn't just use char* for strings (without something to indicate that these ones were null-terminated strings and these other ones were data buffers whose length is represented in this other parameter) and needed to know who was responsible for freeing pointers had not occurred to him. My interest in Enlightenment ended shortly after that: it's not just FFIs that need to know these things, it's C programmers too, and if the underlying APIs are not designed with this in mind then code using them is going to be buggy.
Slashdot Mirror
You mean, projects like MESA, X.org, and the existing DRI stack? Of which this is a third-party contribution, under the original license?
I have a slow AMD E-350 (1.6GHz, dual core, low power chip) in the machine I use as a media centre. With the original MESA software fallback, I got about 3 frames per second in the UI. It was totally unusable. After FreeBSD gained support for the GPU, I tried it again and got about 20-30fps. This seemed a bit low, and I discovered that I'd misconfigured it and it was still using the software fallback, only now it was using LLVMPipe. I don't know how much faster the GPU actually is, because at 60fps it hits vsync and doesn't try to go faster, though CPU usage drops from 100% to around 10% (of one core). Of course, this CPU doesn't have AVX, so won't benefit from this code.
The release announcement has a couple more details. This new back end is optimised for workloads with large vertex counts but simple shaders and for machines with a lot of cores. There are a lot of ways that you can make OpenGL shaders faster if you're optimising for the simple case. Half Life 1 works on a fixed-function pipeline, so should be fast on this. Half Life 2 uses a bit more by way of shaders, but possibly not enough to cause it to struggle. Stuff that runs well on a GPU is likely to also run well on multiple cores, if you get the synchronisation right, but the existing LLVM pipe uses a single thread.
My main interest in this is whether you can turn off the GPU entirely for normal compositing desktop workloads and whether it will make a big difference to the power consumption if you do. Compositing desktops generally do a lot of simple compositing, but have very simple shaders and quite simple geometry. I'd be very interested to see whether doing this on the AVX pipelines is cheaper than having an entire separate core doing the work, especially given that the GPU core is generally optimised for more complex graphical workloads.
People who don't want to have a device that spends 100% of its time connected to a network and has remotely exploitable vulnerabilities. Try reading this paper for an overview of how long Android phones go without vulnerabilities (note that the latest Stagefright exploit, that affects all versions of Android since 1.5 was discovered after the paper).
I do agree that Google should crack down on their OEM partners' shoddy support
Google created the problem. The Android ecosystem has lots of competition from hardware vendors, so margins are razor thin. The only company that makes money from it is the company that takes a cut of all app sales (i.e. Google on most phones, Amazon on phones with their market installed and I think Samsung also has their own app store).
Google could easily have fixed this by having some kind of revenue-sharing agreement with vendors that ship the Google Play store: if you're getting 5% of all app sales (still leaving Google with 25%), then you've suddenly got an incentive to ensure that the phone that you sold two years ago still receives the updates that it requires to run the latest apps. Particularly if the market will detect vulnerable versions of Android and refuse to install apps that use the vulnerable subsystems...
wouldn't you want to get paid for your hobby?
I do! But the problem for these people (as with professional sports players) is that they get paid for something that is superficially like their hobby, but isn't really the same. It's the hobby with the enjoyment removed and replaced with a hyper-competitive need to win.
And the code written by the top programmer in his 40s will be so simple that no one will be impressed by it, because it's obvious and only a couple of hundred lines.
mostly my resume submissions are ignored
How did you get to 50 and not know other people doing embedded development? Especially if you were working on Linux, where it's a big community. Most people hiring for this kind of skill set know that it's a waste of time to go through agencies and recommendations from existing (and former) employees are the best way of hiring.
Nonsense. That's only true if you're measuring income in dollars as if that's some absolute and not adjusting for local cost of living. Cost of living varies hugely across the world. Even within a relatively small country country, I moved from somewhere in the UK where my cost of living was around £10K/year living very comfortably to somewhere on the other side of the country where that won't even pay my rent.
Someone else who is also a billionaire – they don't want anything from you!
Anyone who claims that has no understanding of the psychology of the majority of billionaires. See Carly Fiorina and her 'good friend' Steve Jobs for an example. If you're a billionaire, then other billionaires are the ones that have the most of what you value and therefore the best targets. Stealing from the poor is far more effort - you need to steal from loads of them.
Which is in grossly overvalued like most other damned startups.
The value of disruptive startups is measured differently to established businesses. If this company has a 10% chance of growing to control a $100bn industry, then it's valued correctly. That doesn't mean that the most likely outcome isn't that it will crash and burn, it means that it's a the high-risk, high-returns end of investments.
Why? The web is meant to be client-agnostic. I use different browsers on mobile and desktop. The main thing that I want from a web browser (beyond actually working) is to integrate cleanly with the host environment and that's far more likely in a browser that's developed for a single platform than one that's written to be portable. For example, Chrome 'runs' on OS X, but it doesn't integrate properly with the system keychain, so you end up with passwords scattered between two credential stores. Chrome and Firefox are both cross-platform, yet have quite different feature sets and levels of integration on different platforms.
If security is a priority, then I'd want to be able to ensure that, once a known vulnerability is patched, the update needs to be installed in only one place.
Java can take advantage of some, though most existing JVMs don't. A few research projects do. If we're talking about the language, rather than the language implementation (on the basis that the latter can improve without changing the source), then any language that makes field order undefined can take advantage of these things. If the language has primitive integer types, then exploiting SIMD in its equivalent of structs is much easier.
For concurrency, you want a language that either has garbage collection, or one that strictly enforces the shared xor mutable rule. Garbage collection means that you can have concurrent mutation with no synchronisation, though you pay a penalty when it comes to actually running the collection. Pony takes the latter route (as does Erlang, though via a degenerate case of having no mutable state other than the process dictionary).
A modern language should be designed from the ground up with three primary concerns:
I look forward to someone developing a modern language (I have some sketches of a design, but nothing concrete - hopefully someone with more free time than me will get to it before I do). Aside from these goals, the language should be designed for modern tools (e.g. static analysis should be part of the normal development cycle), should have some form of static elaboration (more in the Bluespec style than C++ templates) and should interface cleanly with legacy code in C/C++ (though should have the option of running this code in a separate process, for security).
In 2012, around 80% of all security vulnerabilities exploited in the wild came from some memory safety error. If you use Java, or you use C++ with strict discipline about the use of shared_ptr / unique_ptr, then you immediately remove the possibility of these kinds of vulnerability. You may still fail to sanitise inputs and allow other kinds of high-level vulnerability, but at least eliminating 80% of vulnerabilities would be a nice start.
So no matter what we are going to attach cars and the "street" to the Internet? That's a good idea?
Of course it's a good idea! It will allow more tracking to sell even better-targetted advertising spots. And Google will keep us secure. After all, they've done such a good job with Android...
C++ is different, because it's not just the parsing, it's also the template instantiation. This is where you burn time. You also lose a lot if you have definitions in the headers where you have generate code, then you'll spend time parsing, more time generating your compiler's intermediate representation, more time optimising it, more time generating code, and then even more time in the linker throwing it away.
An excellent engineer can write excellent C, but a poor engineer can overflow buffers and leave dangling pointers hanging around... but not in Rust.
A poor developer will write C code that doesn't work at all. A mediocre developer will write C code that works, but is rife with security vulnerabilities. An excellent developer will write C code that needs an excellent attacker to exploit. Unfortunately, the world has quite a lot of excellent attackers in it.
It's optimised for speed, as long as your target is basically a fast PDP-11. C does not allow the compiler to rearrange data layouts, which makes it hard to take advantage of SIMD or to avoid false sharing. C makes it very hard to statically reason about memory ownership, requiring a defensive programming style with redundant operations when writing multithreaded code. C only recently had a memory model for concurrent accesses at all and so most multithreaded C programs contain undefined behaviour.
As long as the conventions are understood and consistent, then who cares if all strings have to be null terminated or if the strings returned as static, garbage collected or must be free'd?
That information has to be encoded somewhere. If your convention is that every char* parameter is a null-terminated C string that must be copied by the callee if it is expected to persist beyond the duration of the function call, then that's great (you'd better be really consistent about not using char* for arbitrary data though). Similarly, if every pointer that is returned needs freeing by the caller, then that's also fine, and you can machine-generate the wrappers on that assumption.
If you're going to create a metamodel with the primary goal of allowing wrappers from other languages, then you need to think about these things. EFL now has a metamodel intended for FFI, and it doesn't think about these things. Functions take char* arguments (and the metamodel describes their type solely as char*), which may be null-termianted C strings or blobs of data with the length encoded somewhere else. They may be held by the callee and freed later, or the caller may be responsible for freeing them. None of this information is encoded in anything machine readable.
This is repeated a lot, but it's not actually backed up by evidence. Few societies ever go through a significant barter phase. Most move from a gift economy to some form of currency without barter playing a significant role in between.
Voter turnout, for one. Fix may be too strong a word, I would go with address.
The problem is not the number of people that vote, it's the number of informed people that vote. And, by that, I don't mean educated people who have spent a long time studying the issues, I mean people who have a basic clue as to what their candidates views are (beyond 'wears a {red,blue} ribbon'). Forcing more people to turn up doesn't fix this, it can only be addressed by having an impartial media that's willing to cover the candidates public and private opinions without fear of reprisals.
socialist wealth redistribution
Often they just say 'wealth redistribution', which is the phrase that annoys me more than any other in political discussions. The people who say it are always implicitly in favour of wealth redistribution in one direction and often opposed to things that slow it, not just things that might reverse it. If I have $1m, and I invest it at a return 1% above the rate of inflation (not so hard when you have $1m), then I make $10K/year just from having money. If I have $10m and I make the same investments, then I'm making $100K/year, which is more than most people who work for a living, again just from starting with capital.
The average net worth of US senators in 2011 (I couldn't find newer figures) was $14m, for senators it was $7m (before anyone jumps in with partisan claims, the average for Republicans was higher in the Senate, but lower in the House). These people are earning more from their investments than most of their constituents. They're all - on both sides of the aisle - very much in favour of wealth redistribution, as long as that wealth keeps flowing to them.
Because the emergency dialler requirement is not intended solely for the person who owns the phone. It's expected that any telephone that you pick up (land line or mobile) will work for emergency calls. This is also why landlines can still make emergency calls even if they are nominally disconnected by the phone company.
I'm not particularly familiar with either company's process, but it's been a couple of generations since you could actually make meaningful comparisons based on the quoted nm size, because everyone has different smallest features that they measure when deciding that they are Xnm. That said, we passed the end of Dennard scaling a long time ago. You'd expect the same chip to be consuming about as much power, be slightly more able to dissipate the heat. It may also have less leakage, though that depends on a number of other factors.
His point about ownership is spot on, however. Newer EFL is starting to use an IDL so that it can integrate with other languages. I talked to the designer of it at FOSDEM. The idea that your IDL couldn't just use char* for strings (without something to indicate that these ones were null-terminated strings and these other ones were data buffers whose length is represented in this other parameter) and needed to know who was responsible for freeing pointers had not occurred to him. My interest in Enlightenment ended shortly after that: it's not just FFIs that need to know these things, it's C programmers too, and if the underlying APIs are not designed with this in mind then code using them is going to be buggy.