A little over a decade ago was when Apple announced that laptop sales had passed desktop sales for them. This wasn't surprising, because their desktops were far less competitive than their laptops (and no one bought an Apple desktop to save money). The rest of the industry followed about two years later. We've been in a world where more laptops are sold than desktops for almost a decade. Even accounting for the fact that laptops are replaced rather than upgraded, there are now more people who use laptops as their only computer than there are desktop users.
It launched for me after doing that, but didn't actually work. It ran in FireFox, using about 50% of one core of a 2.2GHz i7 (Haswell). The same game runs very happily on a 1GHz ARM core, but I don't know what percentage of the CPU it's using there. Aside from being slow, the UI really sucks (I managed to zoom in, but not to zoom out). On a touchscreen device, I really liked the Auralux UI.
Oh please, the same arguments were made when API's like DirectX first started surfacing. You may as well argue that unless you're programming directly at the assembly level, you're wasting your time.
DirectX came with some advantages as well though. Like OpenGL, you ended up with a slower game than writing specialised code for a specific graphics accelerator, but the trade was that you got to support all shipping accelerators (and ones that hadn't shipped yet) by allowing them to write the code once and get a speedup everywhere. With Direct2D, you got things like accelerated sprite drawing from hundreds of graphics cards that all had different interfaces for bit blits. This meant that your Direct2D game would often be faster than a DOS version that was talking to the VGA hardware (or SGVA via VESA) and doing the same thing entirely in software.
An abstraction layer that has a small cost but buys you acceleration support in exchange is worthwhile, because the net result is faster (and simpler) code. An abstraction layer that has a big cost and doesn't give you faster code much harder to justify.
Beyond a certain point, I agree. There's a world of difference in readability between code written by people who are comfortable typing and people who type very slowly. If typing is a chore, there's always a temptation to use very short variable and function names and avoid comments. If typing a comment is something you can do while you're thinking about what the next bit of code should do, then you end up with much more readable code because the tendency is to write a description of what the code should do (and, importantly, why) in a comment, and then write the code.
The 10 lines of code a day comes from an IBM report. Note that it's not just 10 lines written, it's 10 lines of bug-free code complete with documentation and tests, averaged over large projects. For each day that you're churning out thousands of lines of code, how many days are you (or someone else) finding and fixing bugs in that code?
It depends a lot on the data structures. There were a number of papers using TSX at EuroSys this year. The main conclusion was that TSX lets you get similar performance from simple approaches as you can get already from complex approaches. For example, you can protect a long linked list in a single lock and use HLE to get a big speedup with lots of concurrent insertions and accesses, but you can achieve similar performance with a fine-grained locking scheme. There was a nice paper about Cuckoo hashing where they initially found that TSX gave them a performance win, but then were able to get a similar speedup without it.
The big win with TSX is that it's pretty easy to reason about coarse-grained locking and much harder to reason about fine-grained locking. If you can make coarse-grained locking almost as fast as fine-grained, then that's a huge saving on testing and debugging time.
Possibly, although the described sequence sounds exactly like what happens in a ROP attach. In this case, giving the attacker the opportunity to incorrectly update the stack pointer may make the attack easier.
MPX doesn't help here either. It provides bounds checking by storing the bounds in a look-aside table that must be atomically updated if you have pointers that are visible to multiple threads, which means that every pointer store to a global must be wrapped in a transactional region (ooops, TSX doesn't work anymore, hopefully they'll have fixed it by the time MPX ships). It looks like the overhead of actually using MPX will be more - in terms of both speed and memory usage - than pure software approaches.
The big one coming up is the doubling of the integer registers from 16 to 32 in skylake. Which should be interesting in emulation scenarios and code that is kind of knarly.
The only source I can find for that is Wikipedia, with the edit made by an anonymous user. Do you have anything a little bit more authoritative than that? 16 seems to be close to the sweet spot for integer registers, with enough that modern register allocation algorithms can do a good job, but not so many that context switches are overly expensive.
No, they're saying that you can't just take their research and make claims that it doesn't substantiate and then appeal to their authority to support your claims.
To give a computer science analogy (I'm out of stock of car analogies), imagine that you worked on Hadoop and you'd made sorting large data sets go 50% faster. Then someone publishes a book arguing that P=NP and uses your result (which doesn't even do comparison-based sorting) as the basis for their claim. You'd be in pretty much the same position as the researchers in TFA. Would you say that the author is an idiot, or would you keep quiet?
Crusade had a few bad episodes, but hinted at some interesting story arcs and was mostly fun. Legend of the Rangers was mostly good, but fell into the trap of 'here's a big bad enemy who's even bigger and more bad than the last big bad enemy you fought'. It would have needed a later episode to discover (quite soon!) that The Hand were overstating their abilities and history.
I suspect that part of the problem is that JMS won't embrace new distribution methods. I would happily throw $50 into a pot to create a new series in the B5 universe to be released under a license that permits free non-commercial redistribution, with commercial boxed sets available for purchase for collectors. I suspect that there are enough B5 fans who'd be willing to do the same that it would be possible to finance one.
Some do. For example, there's a big window in the captain's office that looks out over the centre of the station (they're really inconsistent about gravity in B5, but that's a different issue), and it was only when I watched a 'making of' thing after seeing the entire series that I realised that it was meant to be a window. I thought it was a painting. I still think the space scenes look okay, but some of the backdrops - especially on planets - are pretty bad. They used CGI because they couldn't afford the location / model work that bigger-budget shows used.
The flashbacks to the telepath war in Crusade make it look interesting, and apparently it is in the novels. The real problem with season 5 was that it was set in the lull between interesting things. After the Shadow War, after the Civil Wars (human and minbari), but before the Telepath War or any of the other things that JMS had put into the timeline. Even the fall of Centauri Prime was more setup than main event (providing a base for the Drakh to operate from over the next 20 years). It was Part 1, but you can't put Part 1 at the end of a 5-year story.
Boxleitner grew into the role, but at the start he lacked the gravitas that O'Hare brought to the part. He just didn't seem like someone that I'd trust to be in charge of something as complex as a battleship, let alone a huge diplomatic outpost.
ARM's Mali has supported OpenCL (not just the mobile subset) for a couple of generations too. The problem is that Google hates OpenCL and tries hard to make sure that it doesn't work on Android. I don't know what makes nVidia think that they're different in this regard.
How long ago and what were the games? On startup, The Witcher 2 (which isn't even a very recent game anymore) seems to read several hundred MBs and then loads more for each environment. Fast random reads would seem to be a benefit there - the CPU in my laptop isn't at 100% even reading the data from SSD...
The reason that we've open sourced our CPU (not the one in TFA) is to promote research. The vast number of papers published in computer architecture conferences and journals evaluate their approach solely on a simulator and hope that there's some relationship between the simulator and reality. While a softcore CPU is not exactly like a real CPU, being able to implement your ideas in an FPGA (and pass timing!) does at least mean that it is possible to implement them in a real CPU, although it doesn't guarantee that they'd be more efficient than another approach. It also lets you do evaluation with real software: we can boot FreeBSD on our system and run real programs on it for benchmarking, which is a lot more realistic than taking some existing instruction trace, permuting it based on some assumptions, and then feeding it into your simulator.
So they make very crappy tools. For the record, we want good quality (no crashing, sensible error messages (not "unknown error")) command line tools, like how normal compilers work.
I have here a log file containing the output from a command-line build of our CPU using the Altera tools. This file is 10460 lines long. The relevant information it contains can be summarised as: No errors, passed timing.
Occasionally, we've had serious issues reported (the reset line on the ethernet MAC wasn't connected, so ended up being set high, which cost us over a week of time debugging the driver and trying to discover why the FIFOs weren't behaving correctly), but they're hidden in so much noise that there's absolutely no chance that a human will ever see them. They're not differentiated from trivial warnings that no one will ever care about.
In the software world, we've (with my Clang developer hat on) learned that warnings have to have a low false-positive rate or you end up with everyone ignoring them. We therefore expect reasonable developers to be able to set -Werror on large codebases and fix everything that breaks the build. If your code doesn't build with -Werror, then it's a big warning sign.
In the FPGA world, thousands of warnings (and even more 'information' lines) in the output are normal for any nontrivial build.
This is precisely the issue that we have. Our core (MIPS IV compatible, 7-stage pipeline, branch predictor, SMP support) is open source (Apache-style), but it's written in a proprietary high-level HDL. After compiling it, you get Verilog, but even that isn't very useful by itself. There are a few open source Verilog simulators, but if you want to either run it on an FPGA or synthesise an ASIC, you're going to need proprietary tools. There's little incentive to produce open source versions, because they tend to be tied quite closely with their targets (either expensive FPGAs or even more expensive fabs).
Separate. Isolate. Defend. Treat every piece of third-party code that you don't have source for as an enemy whose only goal is to financially rape you. I don't care if that enemy goes by Oracle, Microsoft, or Joe's Discount Software.
Having the source doesn't help you if it's an unmaintainable piece of crap, which is presumably where the OP's requirement for a community came from - if a load of people are hacking on it actively then there's a good chance that, if you end up needing to maintain it in-house, there's a pool of people to hire or send consulting work to.
Slashdot Mirror
A little over a decade ago was when Apple announced that laptop sales had passed desktop sales for them. This wasn't surprising, because their desktops were far less competitive than their laptops (and no one bought an Apple desktop to save money). The rest of the industry followed about two years later. We've been in a world where more laptops are sold than desktops for almost a decade. Even accounting for the fact that laptops are replaced rather than upgraded, there are now more people who use laptops as their only computer than there are desktop users.
It launched for me after doing that, but didn't actually work. It ran in FireFox, using about 50% of one core of a 2.2GHz i7 (Haswell). The same game runs very happily on a 1GHz ARM core, but I don't know what percentage of the CPU it's using there. Aside from being slow, the UI really sucks (I managed to zoom in, but not to zoom out). On a touchscreen device, I really liked the Auralux UI.
Oh please, the same arguments were made when API's like DirectX first started surfacing. You may as well argue that unless you're programming directly at the assembly level, you're wasting your time.
DirectX came with some advantages as well though. Like OpenGL, you ended up with a slower game than writing specialised code for a specific graphics accelerator, but the trade was that you got to support all shipping accelerators (and ones that hadn't shipped yet) by allowing them to write the code once and get a speedup everywhere. With Direct2D, you got things like accelerated sprite drawing from hundreds of graphics cards that all had different interfaces for bit blits. This meant that your Direct2D game would often be faster than a DOS version that was talking to the VGA hardware (or SGVA via VESA) and doing the same thing entirely in software.
An abstraction layer that has a small cost but buys you acceleration support in exchange is worthwhile, because the net result is faster (and simpler) code. An abstraction layer that has a big cost and doesn't give you faster code much harder to justify.
If it's nondeterministic, yes. If it's 'you can change the stack pointer in this way with this sequence of instructions' then it may be easier.
Beyond a certain point, I agree. There's a world of difference in readability between code written by people who are comfortable typing and people who type very slowly. If typing is a chore, there's always a temptation to use very short variable and function names and avoid comments. If typing a comment is something you can do while you're thinking about what the next bit of code should do, then you end up with much more readable code because the tendency is to write a description of what the code should do (and, importantly, why) in a comment, and then write the code.
The 10 lines of code a day comes from an IBM report. Note that it's not just 10 lines written, it's 10 lines of bug-free code complete with documentation and tests, averaged over large projects. For each day that you're churning out thousands of lines of code, how many days are you (or someone else) finding and fixing bugs in that code?
It depends a lot on the data structures. There were a number of papers using TSX at EuroSys this year. The main conclusion was that TSX lets you get similar performance from simple approaches as you can get already from complex approaches. For example, you can protect a long linked list in a single lock and use HLE to get a big speedup with lots of concurrent insertions and accesses, but you can achieve similar performance with a fine-grained locking scheme. There was a nice paper about Cuckoo hashing where they initially found that TSX gave them a performance win, but then were able to get a similar speedup without it.
The big win with TSX is that it's pretty easy to reason about coarse-grained locking and much harder to reason about fine-grained locking. If you can make coarse-grained locking almost as fast as fine-grained, then that's a huge saving on testing and debugging time.
Possibly, although the described sequence sounds exactly like what happens in a ROP attach. In this case, giving the attacker the opportunity to incorrectly update the stack pointer may make the attack easier.
MPX doesn't help here either. It provides bounds checking by storing the bounds in a look-aside table that must be atomically updated if you have pointers that are visible to multiple threads, which means that every pointer store to a global must be wrapped in a transactional region (ooops, TSX doesn't work anymore, hopefully they'll have fixed it by the time MPX ships). It looks like the overhead of actually using MPX will be more - in terms of both speed and memory usage - than pure software approaches.
The big one coming up is the doubling of the integer registers from 16 to 32 in skylake. Which should be interesting in emulation scenarios and code that is kind of knarly.
The only source I can find for that is Wikipedia, with the edit made by an anonymous user. Do you have anything a little bit more authoritative than that? 16 seems to be close to the sweet spot for integer registers, with enough that modern register allocation algorithms can do a good job, but not so many that context switches are overly expensive.
No, they're saying that you can't just take their research and make claims that it doesn't substantiate and then appeal to their authority to support your claims.
To give a computer science analogy (I'm out of stock of car analogies), imagine that you worked on Hadoop and you'd made sorting large data sets go 50% faster. Then someone publishes a book arguing that P=NP and uses your result (which doesn't even do comparison-based sorting) as the basis for their claim. You'd be in pretty much the same position as the researchers in TFA. Would you say that the author is an idiot, or would you keep quiet?
Crusade had a few bad episodes, but hinted at some interesting story arcs and was mostly fun. Legend of the Rangers was mostly good, but fell into the trap of 'here's a big bad enemy who's even bigger and more bad than the last big bad enemy you fought'. It would have needed a later episode to discover (quite soon!) that The Hand were overstating their abilities and history.
I suspect that part of the problem is that JMS won't embrace new distribution methods. I would happily throw $50 into a pot to create a new series in the B5 universe to be released under a license that permits free non-commercial redistribution, with commercial boxed sets available for purchase for collectors. I suspect that there are enough B5 fans who'd be willing to do the same that it would be possible to finance one.
I enjoyed Crusade, but it was killed before any of the major plot elements could be resolved, which was annoying.
Some do. For example, there's a big window in the captain's office that looks out over the centre of the station (they're really inconsistent about gravity in B5, but that's a different issue), and it was only when I watched a 'making of' thing after seeing the entire series that I realised that it was meant to be a window. I thought it was a painting. I still think the space scenes look okay, but some of the backdrops - especially on planets - are pretty bad. They used CGI because they couldn't afford the location / model work that bigger-budget shows used.
The flashbacks to the telepath war in Crusade make it look interesting, and apparently it is in the novels. The real problem with season 5 was that it was set in the lull between interesting things. After the Shadow War, after the Civil Wars (human and minbari), but before the Telepath War or any of the other things that JMS had put into the timeline. Even the fall of Centauri Prime was more setup than main event (providing a base for the Drakh to operate from over the next 20 years). It was Part 1, but you can't put Part 1 at the end of a 5-year story.
Boxleitner grew into the role, but at the start he lacked the gravitas that O'Hare brought to the part. He just didn't seem like someone that I'd trust to be in charge of something as complex as a battleship, let alone a huge diplomatic outpost.
ARM's Mali has supported OpenCL (not just the mobile subset) for a couple of generations too. The problem is that Google hates OpenCL and tries hard to make sure that it doesn't work on Android. I don't know what makes nVidia think that they're different in this regard.
Oh, sorry. I was thinking of Sean. Both of you switched jobs at almost the same time.
How long ago and what were the games? On startup, The Witcher 2 (which isn't even a very recent game anymore) seems to read several hundred MBs and then loads more for each environment. Fast random reads would seem to be a benefit there - the CPU in my laptop isn't at 100% even reading the data from SSD...
The reason that we've open sourced our CPU (not the one in TFA) is to promote research. The vast number of papers published in computer architecture conferences and journals evaluate their approach solely on a simulator and hope that there's some relationship between the simulator and reality. While a softcore CPU is not exactly like a real CPU, being able to implement your ideas in an FPGA (and pass timing!) does at least mean that it is possible to implement them in a real CPU, although it doesn't guarantee that they'd be more efficient than another approach. It also lets you do evaluation with real software: we can boot FreeBSD on our system and run real programs on it for benchmarking, which is a lot more realistic than taking some existing instruction trace, permuting it based on some assumptions, and then feeding it into your simulator.
So they make very crappy tools. For the record, we want good quality (no crashing, sensible error messages (not "unknown error")) command line tools, like how normal compilers work.
I have here a log file containing the output from a command-line build of our CPU using the Altera tools. This file is 10460 lines long. The relevant information it contains can be summarised as: No errors, passed timing.
Occasionally, we've had serious issues reported (the reset line on the ethernet MAC wasn't connected, so ended up being set high, which cost us over a week of time debugging the driver and trying to discover why the FIFOs weren't behaving correctly), but they're hidden in so much noise that there's absolutely no chance that a human will ever see them. They're not differentiated from trivial warnings that no one will ever care about.
In the software world, we've (with my Clang developer hat on) learned that warnings have to have a low false-positive rate or you end up with everyone ignoring them. We therefore expect reasonable developers to be able to set -Werror on large codebases and fix everything that breaks the build. If your code doesn't build with -Werror, then it's a big warning sign.
In the FPGA world, thousands of warnings (and even more 'information' lines) in the output are normal for any nontrivial build.
This is precisely the issue that we have. Our core (MIPS IV compatible, 7-stage pipeline, branch predictor, SMP support) is open source (Apache-style), but it's written in a proprietary high-level HDL. After compiling it, you get Verilog, but even that isn't very useful by itself. There are a few open source Verilog simulators, but if you want to either run it on an FPGA or synthesise an ASIC, you're going to need proprietary tools. There's little incentive to produce open source versions, because they tend to be tied quite closely with their targets (either expensive FPGAs or even more expensive fabs).
I like the APIs for Apple's PDFKit, but without cross-platform support I wouldn't use it for anything other than toy projects.
Separate. Isolate. Defend. Treat every piece of third-party code that you don't have source for as an enemy whose only goal is to financially rape you. I don't care if that enemy goes by Oracle, Microsoft, or Joe's Discount Software.
Having the source doesn't help you if it's an unmaintainable piece of crap, which is presumably where the OP's requirement for a community came from - if a load of people are hacking on it actively then there's a good chance that, if you end up needing to maintain it in-house, there's a pool of people to hire or send consulting work to.