I don't remember being asked to show ID on checking into a hotel anywhere in Europe. In the US, however, credit card and photo ID are the first things that they ask for at every checkin desk at every hotel I've stayed at (about a dozen over the last couple of years, in quite a few states).
Gay Marriage. States should be allowed to ban gay marriage but be forced to recognize it when performed in states which allow it. You keep those who find it in conflict with their faith happy and provide a solution to those who are homosexual who wish to wed.
And states should be allowed to legalise slavery. Because that worked so well the last time.
1) Cut all the legacy crap. Forget emulating x86-32b/x86-16b, just build a straight 64-bit chip
Most of that is microcoded. There's no benefit in removing most of the 32-bit stuff, because it's exactly the same in 64-bit mode. Things like segments are microcoded and if you have a non-zero base you hit a really slow microcoded path on Intel's low-power CPUs.
First, to know that it actually is a compiler bug. You can spend days debugging your code and failing to find the error if you regard your compiler as infallible. Second, because you want it to actually be fixed. There are a few thousand bugs open in LLVM and GCC. If you want yours to be fixed, then you need the people doing bug triage to be able to work out who to assign it to. A simple reduced test case and an explanation of exactly what the compiler is doing wrong means that it is likely to be fixed the same day that it's filed. Without that... come back in a year and we might have fixed it if someone better at writing bug reports than you has filed a duplicate.
I would suggest you leave the compiler debugging to the compiler experts because what *you* describe as stupid may actually have a larger purpose behind it.
I spend most of my time fixing compiler bugs (when I'm lucky, I get to add new compiler features), so perhaps I'm slightly biased about compiler code quality. Most recently, I was working on an error in LLVM where functions with more than 8 integer / pointer arguments were mangled on big-endian MIPS (if they were smaller than register size), because they were spilled to the stack in the little-endian position. If you encountered this as a programmer and weren't able to look at the function call and prologue, then you'd have absolutely no idea why your code was doing seemingly random things.
The people that are triggering this debate are being incredibly abusive and awful to women, simply because they dared to express an opinion online that doesn't align with the troll's opinion. If that doesn't meet the criteria for being a misogynist, what does?
Nope, that doesn't meet the definition of being a misogynist in the slightest. If they were being incredible abusive and awful to women simply because they were women, then that would meet the definition of being a misogynist. If they are being awful to people for having an opinion, then they are jerks.
The real problem with this entire issue is the people who try to frame it as misogynistic men against oppressed women and not antisocial idiots against sensible people.
Yet, I plan to teach her arithmetic with jelly beans, hands on, doing it manually, so that she UNDERSTANDS what multiplication is all about. Once she really understands it, she'll know when and how to use it. She can then use the calculator as a shortcut, but use it effectively.
There are a few questions to ask about this sort of teaching:
Can you understand what the machine is doing?
Can you get the same answer as the machine?
Can you get the answers faster than the machine?
In the case of simple arithmetic, if you include the time of getting the phone out of your pocket, then the answer should be yes to all of them - it's just useful. The education system (in the UK, at least) unfortunately tries to take the same approach for things like calculus. You can understand how to solve differential equations (although more by applying rote-learned rules than really understanding what's going on), and that's useful. After a year of practicing, you may take 10 minutes instead of 30 to solve some complex equations, but the computer will take under a second, so was it really worth spending that year practicing?
The same is true for most automated tools. There's no benefit in writing your own, but there's a big benefit in being able to write your own. Or in writing your own and then understanding why it's not as good as the one that loads of other people have been working on for years...
I'm fully supportive of the idea that programmers shouldn't write assembly. I'm a lot more hesitant about a programmer who never reads assembly. Compilers do odd things. Sometimes they do clever odd things, sometimes they do stupid odd things. And sometimes they just contain bugs.
The grandparent's sorting a list is actually a pretty good example. There are lots of library sort implementations that do a reasonable job over arbitrary data but you can often do a lot better with some knowledge about the data that you're sorting. If you know that you have a roughly even distribution between n ranges and it's cheap to test which of those n ranges your data are in, then you can do a (linear time) bucket sort and then use the off-the-shelf comparison sort to do n sub-sorts in parallel. The generic sorting code can't do this, because it doesn't have enough information: it just has a comparison operator defined on the data. If you understand the underlying concepts then you should know when you can beat a generic implementation with a domain-specific one. If you've had a bit of experience then you should know when it's not worth bothering.
Anyone who thinks that programming is getting easier due to automation isn't a programmer.
I disagree. Automation has definitely made a lot of things easier, but it's been offset by an increase in requirements. Autocomplete for APIs, for example, popping up a snippet of documentation when you're typing is essential on some of the APIs I work with today, with hundreds of classes each of which have dozens of methods - remembering the exact name of the one that you might use once a year is impossible (especially when it's code that Google people work on and so randomly do bulk refactoring runs renaming methods to fit some private aesthetic every month). When I started programming, the entire set of APIs I had to work with fitted into a quite small book and it was easy to memorise the whole thing.
First, 'just producing an SoC' is not trivial. The interrupt controllers designed for ARM11 are not going to work well with a Cortex A9, for example. DMA units will have different interfaces. The amount of effort required to try to shoehorn older on-chip peripherals to work with a new core is pretty large. Imagine trying to fit a Pentium into a 486 motherboard - it was possible, but only with a custom Pentium chip designed for it (and only on motherboards designed for the P24T 'Pentium Overdrive'), but the result was a really slow Pentium. The coupling between parts on an SoC is far tighter than between components on an x86 motherboard.
I did, you're still being silly. It's easy to run non-branching code on a branching processor, it's almost impossible to do the opposite.
True, although you end up keeping a large amount of the die powered for no benefit at all. Similarly, you can run sequential code on a GPU by just leaving most of the threads powered and doing nothing.
It's easy to run code with weak locality on a processor with strong locality, it's almost impossible to do the opposite.
Not true. This is one of the reasons why GPUs and DSPs are significantly faster. There are large categories of algorithms with predictable access patterns that can leave a CPU with a conventional cache hierarchy (even with prefetch instructions) completely data starved. To load a value into a conventional CPU, you have to hit two or three layers of cache miss, each of which then has to pull in a complete cache line (typically 64 bytes). Meanwhile, a DSP can be sending memory requests at word granularity to the DRAM. Even with a quarter of the memory bandwidth, it can often achieve more throughput than a commodity CPU.
They won't run them well, for example software rendering on CPUs is horribly slow but t's still orders of magnitude better than trying to use your GPU as a CPU.
Your GPU is also turing complete, so aside from the memory protection aspects (which actually are present on some modern GPUs), your argument applies in reverse too. You can run sequential code on a GPU: only use one thread. You can run code that branches a lot, you'll just take a load of pipeline flushes as a penalty. You can run code that exhibits locality of reference, you'll just end up fighting the memory controller. So does that mean that your GPU is a general-purpose processor? In both directions, your performance overhead for using the wrong processor is a couple of orders of magnitude.
The A53 cores (the 64-bit equivalent to the A7) are already starting to get pretty cheap. I wouldn't be surprised if they become cheap enough for the RPi Master (or whatever they call it) some time next year. Especially as they can guarantee that whichever chip goes in the RPi is going to have a lot of third-party software spending on it. That is very valuable to SoC makers: knowing that anyone who wants to do some embedded project can already get well-tested and well-supported off-the-shelf toolchains and operating systems for their part.
This is why we at one time had Lisp Machines with specialized hardware optimized for running Lisp efficiently. Message based machines were tried for Smalltalk
The main reason that Lisp machines lost out was that they were stack based. Stack-based instruction sets don't (easily) expose any instruction-level parallelism, which means that you can't easily extend them to take advantage of pipelining. That wouldn't have been such a problem if Lisp had been parallel (a barrel-scheduled multithreaded stack-based CPU can be very simple to design, have very good instruction cache usage, and get good power / performance ratios), but Lisp machines ran an single-threaded environments. I don't know of any machines (other than the Mushroom project from Manchester) that were designed for Smalltalk - it originally ran with custom microcode on the Alto - but the most successful message-passing machine was the Transputer, optimised for Occam code. Erlang has a similar abstract model and it run in telecoms systems, but on CPUs that are very poorly optimised for it.
They are backwards compatible. The problem is not ARM - it's the rest of the SoC. If you can find exactly the same other components on an SoC with a newer ARM core, then it will be fine. The problem is that ARMv6 didn't standardise things like the interrupt controller (ARMv7 does, but only in a later revision) or the bootloader interface. You'll need a different kernel to support a newer SoC, because most of the other components will be different..
Why can't that decide your thinking or, more specifically, the court's thinking? The court has to decide whether copyright protection should cover APIs. The justification for this is right there in the constitution:
To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries.
The court has to decide whether copyright protection for APIs would promote the progress of science and useful arts. The EFF and others are arguing that it would hamper progress of science.
But what sets general purpose processors apart is that they assume the worst and tries to make all code perform, no matter how ugly. They optimize for flexibility, with an emphasis on minimizing the worst cases
Read TFA. They optimise for a specific category of algorithm, that is branch heavy (although comparatively light in computed branches), has strong locality of reference, is either single-threaded or has shared-everything parallelism, and a few other constraints. That's not a general purpose processor, that's something optimised for a specific workload and, because they've been the cheapest way of buying processing power for a few decades, people put a lot of effort into trying to shoehorn algorithms to have those characteristics. As GPUs became cheaper per FLOPS, people tried to shoehorn algorithms to fit on processors that are optimised for code with almost no branches, little locality of reference, explicit parallelism and synchronisation, and highly predictable memory accesses. These are also not general purpose processors. They are two points on a design space and we're going to see a lot more as it becomes increasingly cheap to put rarely-used processors on die. If you can only power 5% of the chip at any time, then you can afford to have a load of different pipelines optimised for very different classes of algorithm on the same die, even if they have the same (or mostly the same) instruction set and some of them can run code intended for any of them (albeit slowly and inefficiently).
And it's worth noting that Amazon's low profits are largely due to the fact that they heavily invest their revenue in entering new markets (cloud hosting, music downloads, eBook readers, video streaming, tablets, and so on). Most of these are long-term investments. A company with a lot of diverse product lines can handle changes in the market much more easily than one that is just an online book retailer. If Amazon just sold books online, they'd probably have much higher profits relative to their size, but they'd be in a very fragile position.
A modern standard ARMv7 instead of the odd ARMv6 would be greatly appreciated too.
Connecting up the performance counter interrupt line would, but ARMv7 wouldn't. Having to have different OS images for different models of RPi makes them a lot less interesting. If you want an ARMv7 board, then go and buy one - there are loads of them.
There's a lot of overlap between those constraints. Cheap doesn't just mean cheap to buy, it means cheap to replace. And that means that when you break one, if the exact model doesn't exist anymore then you need to be able to run everything that was working on the old one on a newer model. The advantage of the RPi over more powerful ARM boards is that it comes with that guarantee - the A+ will run everything (including the same OS image) as the A and B.
The hypothetical 700MHz vs 1GHz issue that the grandparent talks about isn't that much of a problem. More importantly, a new SoC would likely be dual (or quad or octo) core and would be ARMv7, not ARMv6. That's a big change. I expect that the RPi will skip ARMv7 entirely and that eventually there will be an ARMv8 model (possible ARMv8.1 / ARMv8.2), but the jump to 64-bit gives a good excuse for needing a new OS image.
Disclaimer: I work a couple of floors below several of the RPi Foundation, but the only thing that they've told me about their future plans is that they have some. Everything in this post is uninformed guesswork.
There are two questions and it's important not to conflate them:
Are APIs creative works?
Is the industry better served by protecting them or not?
Anyone who has written a nontrivial library can tell you that the answer to the first is a definite yes. Designing a good API is hard and requires a lot of thought (designing a bad API is pretty trivial). The second question is more subtle. If a good API is hard to design, then the company that designs one does deserve some advantage. In general, they get this advantage by being the first mover in their market. If they had the added advantage that no one could create a compatible implementation, would that be a significant advantage for them and would it hurt the industry as a whole? I suspect that the answer to that is that it wouldn't be a massive advantage (there aren't very many cases of people producing identical implementations, and where there are it's often of mutual benefit because their customers like having a second source), but it would be a big disadvantage to the industry because it would mean that you'd always have lock-in for every piece of software.
Slashdot Mirror
So now it's a high-skill, high-stress job that's earning $26.89/hour (above the living wage in Manhattan, but not by much)?
I don't remember being asked to show ID on checking into a hotel anywhere in Europe. In the US, however, credit card and photo ID are the first things that they ask for at every checkin desk at every hotel I've stayed at (about a dozen over the last couple of years, in quite a few states).
Gay Marriage. States should be allowed to ban gay marriage but be forced to recognize it when performed in states which allow it. You keep those who find it in conflict with their faith happy and provide a solution to those who are homosexual who wish to wed.
And states should be allowed to legalise slavery. Because that worked so well the last time.
1) Cut all the legacy crap. Forget emulating x86-32b/x86-16b, just build a straight 64-bit chip
Most of that is microcoded. There's no benefit in removing most of the 32-bit stuff, because it's exactly the same in 64-bit mode. Things like segments are microcoded and if you have a non-zero base you hit a really slow microcoded path on Intel's low-power CPUs.
How about because they're not open sourcing any of the client side bits?
First, to know that it actually is a compiler bug. You can spend days debugging your code and failing to find the error if you regard your compiler as infallible. Second, because you want it to actually be fixed. There are a few thousand bugs open in LLVM and GCC. If you want yours to be fixed, then you need the people doing bug triage to be able to work out who to assign it to. A simple reduced test case and an explanation of exactly what the compiler is doing wrong means that it is likely to be fixed the same day that it's filed. Without that... come back in a year and we might have fixed it if someone better at writing bug reports than you has filed a duplicate.
There are only two sides and all idiots are on one side only?
Yup. Unfortunately, the people in the idiots camp seem to be trying to make it all about them.
Also, where are the innocent bystanders and people who don't really give a fuck but still get bombarded with the issue - like me?
In the non-idiots group.
I would suggest you leave the compiler debugging to the compiler experts because what *you* describe as stupid may actually have a larger purpose behind it.
I spend most of my time fixing compiler bugs (when I'm lucky, I get to add new compiler features), so perhaps I'm slightly biased about compiler code quality. Most recently, I was working on an error in LLVM where functions with more than 8 integer / pointer arguments were mangled on big-endian MIPS (if they were smaller than register size), because they were spilled to the stack in the little-endian position. If you encountered this as a programmer and weren't able to look at the function call and prologue, then you'd have absolutely no idea why your code was doing seemingly random things.
The original post isn't talking about getting rid of the abusers though. It's talking about boycotting Slashdot because some ACs are trolls.
The people that are triggering this debate are being incredibly abusive and awful to women, simply because they dared to express an opinion online that doesn't align with the troll's opinion. If that doesn't meet the criteria for being a misogynist, what does?
Nope, that doesn't meet the definition of being a misogynist in the slightest. If they were being incredible abusive and awful to women simply because they were women, then that would meet the definition of being a misogynist. If they are being awful to people for having an opinion, then they are jerks.
The real problem with this entire issue is the people who try to frame it as misogynistic men against oppressed women and not antisocial idiots against sensible people.
Yet, I plan to teach her arithmetic with jelly beans, hands on, doing it manually, so that she UNDERSTANDS what multiplication is all about. Once she really understands it, she'll know when and how to use it. She can then use the calculator as a shortcut, but use it effectively.
There are a few questions to ask about this sort of teaching:
In the case of simple arithmetic, if you include the time of getting the phone out of your pocket, then the answer should be yes to all of them - it's just useful. The education system (in the UK, at least) unfortunately tries to take the same approach for things like calculus. You can understand how to solve differential equations (although more by applying rote-learned rules than really understanding what's going on), and that's useful. After a year of practicing, you may take 10 minutes instead of 30 to solve some complex equations, but the computer will take under a second, so was it really worth spending that year practicing?
The same is true for most automated tools. There's no benefit in writing your own, but there's a big benefit in being able to write your own. Or in writing your own and then understanding why it's not as good as the one that loads of other people have been working on for years...
I'm fully supportive of the idea that programmers shouldn't write assembly. I'm a lot more hesitant about a programmer who never reads assembly. Compilers do odd things. Sometimes they do clever odd things, sometimes they do stupid odd things. And sometimes they just contain bugs.
The grandparent's sorting a list is actually a pretty good example. There are lots of library sort implementations that do a reasonable job over arbitrary data but you can often do a lot better with some knowledge about the data that you're sorting. If you know that you have a roughly even distribution between n ranges and it's cheap to test which of those n ranges your data are in, then you can do a (linear time) bucket sort and then use the off-the-shelf comparison sort to do n sub-sorts in parallel. The generic sorting code can't do this, because it doesn't have enough information: it just has a comparison operator defined on the data. If you understand the underlying concepts then you should know when you can beat a generic implementation with a domain-specific one. If you've had a bit of experience then you should know when it's not worth bothering.
Anyone who thinks that programming is getting easier due to automation isn't a programmer.
I disagree. Automation has definitely made a lot of things easier, but it's been offset by an increase in requirements. Autocomplete for APIs, for example, popping up a snippet of documentation when you're typing is essential on some of the APIs I work with today, with hundreds of classes each of which have dozens of methods - remembering the exact name of the one that you might use once a year is impossible (especially when it's code that Google people work on and so randomly do bulk refactoring runs renaming methods to fit some private aesthetic every month). When I started programming, the entire set of APIs I had to work with fitted into a quite small book and it was easy to memorise the whole thing.
First, 'just producing an SoC' is not trivial. The interrupt controllers designed for ARM11 are not going to work well with a Cortex A9, for example. DMA units will have different interfaces. The amount of effort required to try to shoehorn older on-chip peripherals to work with a new core is pretty large. Imagine trying to fit a Pentium into a 486 motherboard - it was possible, but only with a custom Pentium chip designed for it (and only on motherboards designed for the P24T 'Pentium Overdrive'), but the result was a really slow Pentium. The coupling between parts on an SoC is far tighter than between components on an x86 motherboard.
I did, you're still being silly. It's easy to run non-branching code on a branching processor, it's almost impossible to do the opposite.
True, although you end up keeping a large amount of the die powered for no benefit at all. Similarly, you can run sequential code on a GPU by just leaving most of the threads powered and doing nothing.
It's easy to run code with weak locality on a processor with strong locality, it's almost impossible to do the opposite.
Not true. This is one of the reasons why GPUs and DSPs are significantly faster. There are large categories of algorithms with predictable access patterns that can leave a CPU with a conventional cache hierarchy (even with prefetch instructions) completely data starved. To load a value into a conventional CPU, you have to hit two or three layers of cache miss, each of which then has to pull in a complete cache line (typically 64 bytes). Meanwhile, a DSP can be sending memory requests at word granularity to the DRAM. Even with a quarter of the memory bandwidth, it can often achieve more throughput than a commodity CPU.
They won't run them well, for example software rendering on CPUs is horribly slow but t's still orders of magnitude better than trying to use your GPU as a CPU.
Your GPU is also turing complete, so aside from the memory protection aspects (which actually are present on some modern GPUs), your argument applies in reverse too. You can run sequential code on a GPU: only use one thread. You can run code that branches a lot, you'll just take a load of pipeline flushes as a penalty. You can run code that exhibits locality of reference, you'll just end up fighting the memory controller. So does that mean that your GPU is a general-purpose processor? In both directions, your performance overhead for using the wrong processor is a couple of orders of magnitude.
The A53 cores (the 64-bit equivalent to the A7) are already starting to get pretty cheap. I wouldn't be surprised if they become cheap enough for the RPi Master (or whatever they call it) some time next year. Especially as they can guarantee that whichever chip goes in the RPi is going to have a lot of third-party software spending on it. That is very valuable to SoC makers: knowing that anyone who wants to do some embedded project can already get well-tested and well-supported off-the-shelf toolchains and operating systems for their part.
This is why we at one time had Lisp Machines with specialized hardware optimized for running Lisp efficiently. Message based machines were tried for Smalltalk
The main reason that Lisp machines lost out was that they were stack based. Stack-based instruction sets don't (easily) expose any instruction-level parallelism, which means that you can't easily extend them to take advantage of pipelining. That wouldn't have been such a problem if Lisp had been parallel (a barrel-scheduled multithreaded stack-based CPU can be very simple to design, have very good instruction cache usage, and get good power / performance ratios), but Lisp machines ran an single-threaded environments. I don't know of any machines (other than the Mushroom project from Manchester) that were designed for Smalltalk - it originally ran with custom microcode on the Alto - but the most successful message-passing machine was the Transputer, optimised for Occam code. Erlang has a similar abstract model and it run in telecoms systems, but on CPUs that are very poorly optimised for it.
They are backwards compatible. The problem is not ARM - it's the rest of the SoC. If you can find exactly the same other components on an SoC with a newer ARM core, then it will be fine. The problem is that ARMv6 didn't standardise things like the interrupt controller (ARMv7 does, but only in a later revision) or the bootloader interface. You'll need a different kernel to support a newer SoC, because most of the other components will be different..
To promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the exclusive Right to their respective Writings and Discoveries.
The court has to decide whether copyright protection for APIs would promote the progress of science and useful arts. The EFF and others are arguing that it would hamper progress of science.
But what sets general purpose processors apart is that they assume the worst and tries to make all code perform, no matter how ugly. They optimize for flexibility, with an emphasis on minimizing the worst cases
Read TFA. They optimise for a specific category of algorithm, that is branch heavy (although comparatively light in computed branches), has strong locality of reference, is either single-threaded or has shared-everything parallelism, and a few other constraints. That's not a general purpose processor, that's something optimised for a specific workload and, because they've been the cheapest way of buying processing power for a few decades, people put a lot of effort into trying to shoehorn algorithms to have those characteristics. As GPUs became cheaper per FLOPS, people tried to shoehorn algorithms to fit on processors that are optimised for code with almost no branches, little locality of reference, explicit parallelism and synchronisation, and highly predictable memory accesses. These are also not general purpose processors. They are two points on a design space and we're going to see a lot more as it becomes increasingly cheap to put rarely-used processors on die. If you can only power 5% of the chip at any time, then you can afford to have a load of different pipelines optimised for very different classes of algorithm on the same die, even if they have the same (or mostly the same) instruction set and some of them can run code intended for any of them (albeit slowly and inefficiently).
And it's worth noting that Amazon's low profits are largely due to the fact that they heavily invest their revenue in entering new markets (cloud hosting, music downloads, eBook readers, video streaming, tablets, and so on). Most of these are long-term investments. A company with a lot of diverse product lines can handle changes in the market much more easily than one that is just an online book retailer. If Amazon just sold books online, they'd probably have much higher profits relative to their size, but they'd be in a very fragile position.
A modern standard ARMv7 instead of the odd ARMv6 would be greatly appreciated too.
Connecting up the performance counter interrupt line would, but ARMv7 wouldn't. Having to have different OS images for different models of RPi makes them a lot less interesting. If you want an ARMv7 board, then go and buy one - there are loads of them.
There's a lot of overlap between those constraints. Cheap doesn't just mean cheap to buy, it means cheap to replace. And that means that when you break one, if the exact model doesn't exist anymore then you need to be able to run everything that was working on the old one on a newer model. The advantage of the RPi over more powerful ARM boards is that it comes with that guarantee - the A+ will run everything (including the same OS image) as the A and B.
The hypothetical 700MHz vs 1GHz issue that the grandparent talks about isn't that much of a problem. More importantly, a new SoC would likely be dual (or quad or octo) core and would be ARMv7, not ARMv6. That's a big change. I expect that the RPi will skip ARMv7 entirely and that eventually there will be an ARMv8 model (possible ARMv8.1 / ARMv8.2), but the jump to 64-bit gives a good excuse for needing a new OS image.
Disclaimer: I work a couple of floors below several of the RPi Foundation, but the only thing that they've told me about their future plans is that they have some. Everything in this post is uninformed guesswork.
Anyone who has written a nontrivial library can tell you that the answer to the first is a definite yes. Designing a good API is hard and requires a lot of thought (designing a bad API is pretty trivial). The second question is more subtle. If a good API is hard to design, then the company that designs one does deserve some advantage. In general, they get this advantage by being the first mover in their market. If they had the added advantage that no one could create a compatible implementation, would that be a significant advantage for them and would it hurt the industry as a whole? I suspect that the answer to that is that it wouldn't be a massive advantage (there aren't very many cases of people producing identical implementations, and where there are it's often of mutual benefit because their customers like having a second source), but it would be a big disadvantage to the industry because it would mean that you'd always have lock-in for every piece of software.