The energy requirements to get into orbit are practically the same no matter what method you use.
True, but very misleading. If you are in a rocket, the energy cost for the cargo is the same, but there is also the energy cost of getting all of the fuel that you need. A typical rocket getting to LEO or GEO is over 90% fuel, so under 10% of the energy cost of the launch is the cost of something that is not required if you are providing the impulse from the ground.
Since this is a legal document which is going to be used in court proceedings, I would say that conspiracy to pervert the course of justice would be a better charge...
Even the, you have problems. For example, Erlang enforces the rule that nothing shared is mutable. This lets it trivially lay out data in memory so that things that are shared are not in the same cache lines as things that are going to be modified. This can cause a big reduction in cache-coherency-related bus traffic.
While it's true that you can implement the message passing of Erlang in any language, it's worth remembering that it's often more useful to take things away from a language than add things. For example, removing pointer arithmetic makes a lot of things possible, such as accurate garbage collection and allows the compiler to rearrange data structures (this can be done in C if you have whole-program analysis and gives about a 10-20% speedup alone in something like the Linux kernel with a fairly naive implementation). A language like Haskell, which disallows side effects except via monads can reorder function calls and even perform them implicitly in parallel.
This is one of the reasons why we're starting to see other languages approach and surpass C for performance for the first time. The reason that C is regarded as a fast language is that it makes the programmer do a lot of the compiler's work. There is a fairly trivial mapping from C code to machine code and a naive compiler can do a good job. Even something like LLVM really does a fairly simple set of optimisations with C code but gets good performance. In contrast, you need to do a lot more to get the same baseline performance with something like Erlang or Haskell, but you then have a lot more headroom too: there are a lot of optimisations that are then possible.
The search isn't important. What happens when every time you fly you see someone in the same queue as you refused? Are airlines going to start giving refunds? They're going to have to if there's perceived to be a significant chance of being denied access, or they'll face a big backlash. What about the delays?
Not at all. My email and IM go via a server hosted by a company that has a financial reason to act in my interests: I pay them a monthly fee. I connect to this server using a connection provided by my ISP, which has a financial reason to act in my interests: I pay them a monthly fee.
You mean the one where the KHTML devs complained that Apple was doing big changeset dumps making them hard to merge, so Apple switched to using a public svn repository? Or the one where committed sandboxing to WebKit in a way that (unlike Chrome's) is browser-agnostic and so can be used by other WebKit users?
Not quite. Anything that comes with a kernel driver will be problematic. To give a popular example, iTunes for Windows installs a driver to connect to iPods and iPhones. Something like this will be a lot easier to get working with ReactOS than WINE on Linux, because the kernel APIs will be the same on ReactOS and both the kernel and userspace components can run, while each program that does this would need custom shims on Linux.
And, another question: Which sandbox did it exploit? Chromium has a chroot-based sandbox, an SELinux sandbox, a Capsicum sandbox, and a Windows sandbox and a Mac sandbox. Was the compromise something specific to one of these implementations, or was it in the platform-agnostic code?
On the other hand, someone who assumes that everyone has a Facebook account is probably not someone I'd want to work for. Someone who delegates something as important as communication to a third party with no incentive (financial or otherwise) to act in their interests is probably not someone who is going to make good business decisions. They're likely to pick supplies based on what the salesman says or what everyone else is using rather than actually analysing what is the best tool for the job, for example.
For reference: I get paid to hack on a compiler used for HPC. The odds are that the one who is lacking the clue is not me...
Which is down to the OS process model
There is a lot that you are missing. First, modern systems are NUMA, although at the low end (and ignoring the GPU) they try to hide it. Even on cache-coherent systems, there is a cost associated with modifying the same data from two threads. Accessing data from a remote node or from another core's cache introduces latency. In languages that have a concept of threads owning data, rather than a flat address space, it is much easier for the compiler to do a whole range of optimisations. The simples of these is making sure that shared and unshared data are not in the same cache lines. Even that is difficult in a language like C, where the compiler has no way of knowing whether a pointer refers to memory that another thread will access. Beyond this there are a whole raft of optimisations that you can do if your language supports transactional memory (for example). On a NUMA system it is often a lot cheaper to copy a moderately large data structure and then merge two sets of changes (or retry one set in cases of conflict) than it is to try to do them simultaneously with the associated cache coherency issues.
Beyond using OS threads (most operating systems, by the way, optimise for well under 100 threads per process because they assume that anything with that level of concurrency will use a lightweight thread on top, as languages like Go and Erlang do) a language with message passing can make more intelligent scheduling decisions. If you have just sent a message to another thread, it's probably a good idea to wake that thread up soon. The Spring operating system from Sun actually had a primitive for doing this, but most VMs for concurrent languages do something similar. In C you can almost do something similar with condition variables, but you're liable to run into the thundering herd problem.
TLDR version: just because you're using lots of pthreads doesn't mean your code will be fast or even scalable. It's very easy to write code that, due to cache and scheduling issues, will run slower the more cores you add.
It's more than that. Often, the strength of a language is not what it adds over another language, but what it removes. Erlang, for example, makes it trivial for the compiler to tell what data structures are shared between threads, and lacks mutable data structures. This means that the compiler can replace copy-and-modify operations with modify ones if nothing else will see the result but can also do things like copy data to improve locality on NUMA systems. Even if you implement CSP-style messaging in a C-family language (I have done) then you miss out on a number of the potential optimisations.
Depends on who you ask. If you ask Alan Kay, who invented the term 'object oriented' then he disagrees, and I'm more inclined to take his word for it than anyone else. Simula had classes (which are also in Smalltalk, but not required for object orientation, as Self showed), but it did not have the late binding and message passing required for an object oriented language.
What on earth are you on about? The language has nothing to do with threading, thats down to the OS
Nonsense. Well, sure, if you have 1024 threads doing totally unrelated things then the language doesn't matter, but then you may as well be using separate OS processes and getting some isolation for free.
Back in the real world, threads need to communicate and they need to share data. How the language represents this has a massive impact on scalability.
It's only the crappy open-source platforms written by non-professionals that struggle to scale, which is why Erlang
Uh, what? You realise that Erlang is from Ericsson and was specifically designed for high-availability systems? If you've made a telephone call in the last 10 years, odds are that at least one leg was routed by some Erlang code...
Pretty much every C compiler with the partial exception of gcc compiles C code into a functional-style imaginary assembly-like language, because that allows more optimization algorithms to work.
Really? Because I've worked on several C compilers, and that's not something I've ever seen. Unless you're talking about SSA form, in which case you're wrong on several counts. First, GCC does use SSA form and has for about five years. Second, SSA form is usually quite restricted: memory is not SSA, for example, so it's not very like a functional style at all. I'm not even going to talk about your conflation of vtables with object orientation.
Any Turing complete language provides an infinite number of ways of solving any given problem. The difference between a good language and a bad one is whether the easiest and most obvious way of doing something is the correct way. The existence of things like register globals and magic quotes that can only be used incorrectly is a good sign of poor design.
The thing that really irritates me about these machines is that both the privacy issues and the uselessness are results of poor UI. The images that the TSA operatives see are false colour images. It would be trivial to map the range for biological matter to the background colour so that the only things that the operative sees are metal items. Then there would be no privacy issue (people wouldn't see you naked - they wouldn't see you at all) and you wouldn't have this kind of failure.
Or just buy it at the shop inside. You don't think deliveries of sealed bottles to those shops have every bottle opened and checked do you? They're delivered by guys earning minimum wage who don't receive security vetting. Just get one of your guys to apply for the job. He can replace a 2L bottle of booze with a 2L bottle of something explosive, or stick a few guns in a biscuit tins. You then go in, buy it, and take it onto the plane.
slight twists like Ruby where everything is a object even things like literal ints
Uh, slight twists? You mean something Ruby copied from Smalltalk, i.e. the first object oriented programming language? That's not a new feature or a twist, that's a return to older ideas. Ruby is Smalltalk with some extra convoluted syntax tacked on top.
It's also worth remembering that performance doesn't mean the same as it used to. An Erlang program, for example, typically runs at about a tenth the speed of a C program doing the same thing... when you have one core. On the other hand, it's pretty easy to write Erlang programs that scale up to 1024 processors (I've written Erlang code that, without any special effort, scaled almost linearly when moved from my single-core laptop to a 64-processor SGI machine and the profiling data indicated that the load was still pretty evenly distributed between Erlang processes so going to 512 or more CPUs would have been easy). When even mobile phones are multicore, this matters a lot more than single-threaded performance. There are lots of things in C that make it very difficult to get good performance when you go beyond about 16 threads (e.g. no differentiation between thread-private and shared data, no immutable-after-creation data types) but which were not a problem for single-threaded performance.
Slashdot Mirror
The energy requirements to get into orbit are practically the same no matter what method you use.
True, but very misleading. If you are in a rocket, the energy cost for the cargo is the same, but there is also the energy cost of getting all of the fuel that you need. A typical rocket getting to LEO or GEO is over 90% fuel, so under 10% of the energy cost of the launch is the cost of something that is not required if you are providing the impulse from the ground.
To put $180 billion in perspective, that's about the same cost 400 shuttle launches.
Since this is a legal document which is going to be used in court proceedings, I would say that conspiracy to pervert the course of justice would be a better charge...
Even the, you have problems. For example, Erlang enforces the rule that nothing shared is mutable. This lets it trivially lay out data in memory so that things that are shared are not in the same cache lines as things that are going to be modified. This can cause a big reduction in cache-coherency-related bus traffic.
While it's true that you can implement the message passing of Erlang in any language, it's worth remembering that it's often more useful to take things away from a language than add things. For example, removing pointer arithmetic makes a lot of things possible, such as accurate garbage collection and allows the compiler to rearrange data structures (this can be done in C if you have whole-program analysis and gives about a 10-20% speedup alone in something like the Linux kernel with a fairly naive implementation). A language like Haskell, which disallows side effects except via monads can reorder function calls and even perform them implicitly in parallel.
This is one of the reasons why we're starting to see other languages approach and surpass C for performance for the first time. The reason that C is regarded as a fast language is that it makes the programmer do a lot of the compiler's work. There is a fairly trivial mapping from C code to machine code and a naive compiler can do a good job. Even something like LLVM really does a fairly simple set of optimisations with C code but gets good performance. In contrast, you need to do a lot more to get the same baseline performance with something like Erlang or Haskell, but you then have a lot more headroom too: there are a lot of optimisations that are then possible.
The search isn't important. What happens when every time you fly you see someone in the same queue as you refused? Are airlines going to start giving refunds? They're going to have to if there's perceived to be a significant chance of being denied access, or they'll face a big backlash. What about the delays?
Blue people make good soldiers, when led by white officers...
Not at all. My email and IM go via a server hosted by a company that has a financial reason to act in my interests: I pay them a monthly fee. I connect to this server using a connection provided by my ISP, which has a financial reason to act in my interests: I pay them a monthly fee.
The past story with khtml webkit
You mean the one where the KHTML devs complained that Apple was doing big changeset dumps making them hard to merge, so Apple switched to using a public svn repository? Or the one where committed sandboxing to WebKit in a way that (unlike Chrome's) is browser-agnostic and so can be used by other WebKit users?
Not quite. Anything that comes with a kernel driver will be problematic. To give a popular example, iTunes for Windows installs a driver to connect to iPods and iPhones. Something like this will be a lot easier to get working with ReactOS than WINE on Linux, because the kernel APIs will be the same on ReactOS and both the kernel and userspace components can run, while each program that does this would need custom shims on Linux.
And, another question: Which sandbox did it exploit? Chromium has a chroot-based sandbox, an SELinux sandbox, a Capsicum sandbox, and a Windows sandbox and a Mac sandbox. Was the compromise something specific to one of these implementations, or was it in the platform-agnostic code?
I use a Mac, but the air of condescension surrounding my computer makes malware slink off and attack someone else's computer.
On the other hand, someone who assumes that everyone has a Facebook account is probably not someone I'd want to work for. Someone who delegates something as important as communication to a third party with no incentive (financial or otherwise) to act in their interests is probably not someone who is going to make good business decisions. They're likely to pick supplies based on what the salesman says or what everyone else is using rather than actually analysing what is the best tool for the job, for example.
Get a clue FFS
For reference: I get paid to hack on a compiler used for HPC. The odds are that the one who is lacking the clue is not me...
Which is down to the OS process model
There is a lot that you are missing. First, modern systems are NUMA, although at the low end (and ignoring the GPU) they try to hide it. Even on cache-coherent systems, there is a cost associated with modifying the same data from two threads. Accessing data from a remote node or from another core's cache introduces latency. In languages that have a concept of threads owning data, rather than a flat address space, it is much easier for the compiler to do a whole range of optimisations. The simples of these is making sure that shared and unshared data are not in the same cache lines. Even that is difficult in a language like C, where the compiler has no way of knowing whether a pointer refers to memory that another thread will access. Beyond this there are a whole raft of optimisations that you can do if your language supports transactional memory (for example). On a NUMA system it is often a lot cheaper to copy a moderately large data structure and then merge two sets of changes (or retry one set in cases of conflict) than it is to try to do them simultaneously with the associated cache coherency issues.
Beyond using OS threads (most operating systems, by the way, optimise for well under 100 threads per process because they assume that anything with that level of concurrency will use a lightweight thread on top, as languages like Go and Erlang do) a language with message passing can make more intelligent scheduling decisions. If you have just sent a message to another thread, it's probably a good idea to wake that thread up soon. The Spring operating system from Sun actually had a primitive for doing this, but most VMs for concurrent languages do something similar. In C you can almost do something similar with condition variables, but you're liable to run into the thundering herd problem.
TLDR version: just because you're using lots of pthreads doesn't mean your code will be fast or even scalable. It's very easy to write code that, due to cache and scheduling issues, will run slower the more cores you add.
It's more than that. Often, the strength of a language is not what it adds over another language, but what it removes. Erlang, for example, makes it trivial for the compiler to tell what data structures are shared between threads, and lacks mutable data structures. This means that the compiler can replace copy-and-modify operations with modify ones if nothing else will see the result but can also do things like copy data to improve locality on NUMA systems. Even if you implement CSP-style messaging in a C-family language (I have done) then you miss out on a number of the potential optimisations.
Depends on who you ask. If you ask Alan Kay, who invented the term 'object oriented' then he disagrees, and I'm more inclined to take his word for it than anyone else. Simula had classes (which are also in Smalltalk, but not required for object orientation, as Self showed), but it did not have the late binding and message passing required for an object oriented language.
No, Simula was the first class-based language. This is not the same thing.
What on earth are you on about? The language has nothing to do with threading, thats down to the OS
Nonsense. Well, sure, if you have 1024 threads doing totally unrelated things then the language doesn't matter, but then you may as well be using separate OS processes and getting some isolation for free.
Back in the real world, threads need to communicate and they need to share data. How the language represents this has a massive impact on scalability.
It's only the crappy open-source platforms written by non-professionals that struggle to scale, which is why Erlang
Uh, what? You realise that Erlang is from Ericsson and was specifically designed for high-availability systems? If you've made a telephone call in the last 10 years, odds are that at least one leg was routed by some Erlang code...
Pretty much every C compiler with the partial exception of gcc compiles C code into a functional-style imaginary assembly-like language, because that allows more optimization algorithms to work.
Really? Because I've worked on several C compilers, and that's not something I've ever seen. Unless you're talking about SSA form, in which case you're wrong on several counts. First, GCC does use SSA form and has for about five years. Second, SSA form is usually quite restricted: memory is not SSA, for example, so it's not very like a functional style at all. I'm not even going to talk about your conflation of vtables with object orientation.
Any Turing complete language provides an infinite number of ways of solving any given problem. The difference between a good language and a bad one is whether the easiest and most obvious way of doing something is the correct way. The existence of things like register globals and magic quotes that can only be used incorrectly is a good sign of poor design.
The thing that really irritates me about these machines is that both the privacy issues and the uselessness are results of poor UI. The images that the TSA operatives see are false colour images. It would be trivial to map the range for biological matter to the background colour so that the only things that the operative sees are metal items. Then there would be no privacy issue (people wouldn't see you naked - they wouldn't see you at all) and you wouldn't have this kind of failure.
Or just buy it at the shop inside. You don't think deliveries of sealed bottles to those shops have every bottle opened and checked do you? They're delivered by guys earning minimum wage who don't receive security vetting. Just get one of your guys to apply for the job. He can replace a 2L bottle of booze with a 2L bottle of something explosive, or stick a few guns in a biscuit tins. You then go in, buy it, and take it onto the plane.
slight twists like Ruby where everything is a object even things like literal ints
Uh, slight twists? You mean something Ruby copied from Smalltalk, i.e. the first object oriented programming language? That's not a new feature or a twist, that's a return to older ideas. Ruby is Smalltalk with some extra convoluted syntax tacked on top.
It's also worth remembering that performance doesn't mean the same as it used to. An Erlang program, for example, typically runs at about a tenth the speed of a C program doing the same thing... when you have one core. On the other hand, it's pretty easy to write Erlang programs that scale up to 1024 processors (I've written Erlang code that, without any special effort, scaled almost linearly when moved from my single-core laptop to a 64-processor SGI machine and the profiling data indicated that the load was still pretty evenly distributed between Erlang processes so going to 512 or more CPUs would have been easy). When even mobile phones are multicore, this matters a lot more than single-threaded performance. There are lots of things in C that make it very difficult to get good performance when you go beyond about 16 threads (e.g. no differentiation between thread-private and shared data, no immutable-after-creation data types) but which were not a problem for single-threaded performance.
Aren't the basic programming concepts understood and defined now? All a new language can really bring to the table is a different syntax.
If you really believe this, then you've been stuck in Algol-derivative land for far too long.