That's an insane patent to have been granted. The fact that the patent holder is asserting that Facebook is infringing it without having seen their source code is extremely telling - the patent holder appears well aware that the patent (which should never have been granted) is so broad as to cover functionality rather than implementation and therefore anyone who appears to be doing what the patent covers is almost certainly infringing it.
It's as is the patent office granted someone a patent on cracking nuts as opposed to a specific nutcracker design, and the lucky patent holder would then be in a position to go after anyone selling shelled nuts on the grounds that they must have shelled them, ergo they must have violated their patent. Of course nuts, unlike software claims decribed in obfusctated legalese, are easy to understand. I'm 100% positive one could describe assigning a value to a variable in such a complex way, accounting for all possible implenentations, semantics, etc, etc, that some moron at the patent office would think it sounded like a highly technical and specific discovery and no-doubt patent worthy. I think I'll go apply for a patent of comments right now ("in the 42nd embodiment, a source code file, stored in EBDIC format on a USB storage device, embeds self-descriptive components, that will be automatically stripped by the FORmula TRANslation language lexical analyzer,...").
Given how complex software is, and how difficult it is for lay people to understand it, and given that the patent office in granting things like this make it obvious that they do not have software experts examining these patents, it seems that the whole notion of software patents needs to be reexamined. They are really doing more harm than good, and the intent of patents to encourage innovation is being subverted rather than helped by software patents. The patent office doesn't seem to understand the process of software design/development at all.
I don't believe that all decisions are irrational/subconscious, but some certainly are, and the illusion of free will is largely based around the fact that we mostly believe we chose to do whatever we did...
e.g.
In tests where hypnotized subjects have been "programmed" to perform some action upon cue (and been mislead about the purpose of the experiment), they will rationalize a reason why they did it. In one clinical study subjects initially sitting down were hypnotized to get up and open the window in the room when the experimenter gave a cue. When asked *why* they had done this, they invariable gave reasons like "it's stuffy", "it's too hot in here", etc. None said "i don't know" or "i was strangely compelled to", etc.
We similarly rationalize that we deicided to act in cases such as dropping a hot coal or swerving to avoid a collision where the fast response time can be shown to have been to quick to have involved a trip through the cortex.
It seems this is the way our brain *always* works. Since our brain is in the end just a neural net/machine, our response in any situation is entirely proscribed (even if not practically knowable ahead of time), and our cortex, being the pattern-matching machine that it is then necessarily correlates the response to any precursors and concludes a causal relationship (basically "i did this because i was thinking this") which is true, but rather misleading in as much as the "i" is the neural net, not the dualistic mind with free-will that we imagine it to be... So we go thru life correctly seeing ourself as making decisions and thus apparently exercising free will, but the latter is an illusion since the decisions we associate with our responses were in fact proscribed!
Good question! It'd be the most efficient design, but maybe I assume too much!
On reflection, the fact that make -j N>1 is a speed-up is probably a good indication that the compiler doesn't itself do a good job of separating IO from CPU usage (i.e. doesn't get the multithreaded design right).
The article isn't saying that the existing scheduler is better than BFS for make -n+1 - it's just saying that BFS doesn't need make -n+1 to keep the cores busy, which is pretty good indication that it's not IO bound (regardless of intuition to the contrary). Note that scheduling is done at thread level, and I assume the compiler is anyways doing IO, preprocessing and lexical analysis in a separate thread from parsing, etc.
Having a single scheduler (and set of tuning parameteres) doesn't necessarily makes sense. It's like saying that rather than having an F-1 car when you're racing, a minivan for bringing kids to parties, and a Hummer for off-road use, you'd prefer a one-size fits all vehicle so that you didn't have to choose. Unfortunately the design compromises that go into an off-road vehicle arn't the same as the ones that go into an F-1 car, anymore than the scheduling needs of a server (thruput) are the same as those of an interactive-use desktop machine (latency).
For myself I'd prefer an install/config option of "Optimize for server/desktop use" so that for desktop use I'm not doing the equivalent of trying to compete in a formula 1 race in a Hummer or minivan.
And the fact that BFS isn't even able to properly schedule n+1 lightly-cpu-bound processes certainly doesn't talk in it's favor.
You misinterpreted TFA.
What Con actually said was that if you have a 4 core CPU then for optminal efficiency run make -j 4 rather than make -j 5/6/etc.
This OUGHT to be the case for ANY (decent) scheduler - it ought to be more efficient to have processes assigned to cores and not needlessly being swapped in and out because you've opted to run more processes than cores to gain some efficiency.
That fact that Con's scheduler does see a benefit when number of processes = number of cores does not reflect a problem with HIS scheduler - it is a problem with the standard scheduler that in order to compensate for scheduler inefficiency you need to run more jobs than you have cores in order to try to keep all cores busy.
What YOU run is irrelevant to what's useful to other people. Most people are running desktop machines or laptops, not multi-node clusters, and anyway unless each of your cluster nodes has 16+ cores (yeah, right) YOU'd also be better off with the new scheduler.
Sure I guess you could run one runqueue per CPU package instead of a global one and so on, but I have no intention whatsoever at doing that because it will compromise the performance where *I* care.
In the meantime if you care about CPU utilization and latency then use this. Tomorrow will take care of itself. It's not like if you buy one computer or graphics card, or build one kernel, that you're tied to it for the rest of your life. You use this year what's available and update when the situation warrants it.
Your post is not only ill-informed, but totally illogical. Which is it, are terrorists unpredictable (which itself is a pattern) or do they exhibit certain typical behaviors?!
Could have been a compiler (code generation) bug - you could have checked the assembler generated - or could have been a bug somewhere else in your program causing corruption. Insert/delete an arbitrary bit of code (debug statement) and the thing being corrupted changes and the bug may **appear** to have gone away (it hasn't, but it's just corrupting something harmles instead e.g. unused memory).
Mr. Robot stands there hands whizzing around juggling cellphones and manipulating grains of rice at lightening speed, then you pull out a shotgun and pump his CPU full of bird shot.
I've seen a martial arts demonstration where a guy caught arrow being shot past him. He did it **blindfold**, based on hearing the release and knowing the distance! Gotta wonder how many times he got an arrow stuck in his hand before he got the timing right!
It really doesn't make much difference. If the baby is crying at night (esp. if it sleeps in your room) they your night isn't going to be so great. Trust me! (father of an adorable but sleep-depriving 6 month old baby girl).
Even without the disrupted nights a baby is going to make you tired since there's no downtime. If mom is feeding and looking after the baby, then guess who's shopping, cooking, washing up and then looking after the baby while mom has a shower, does the laundry, etc, etc?!
My first home computer from 1978 was a Z80-based NASCOM-1 which also came as a bare board kit. Thing is, back then this was the *normal* way to buy a computer, unless you had the extra money to buy one pre-assembled.
It's kinda sad that nowadays a "news for nerds" site thinks it's newsworthy when someone does something nothing more creative than soldering together a kit computer. OOh, look! Soldering iron! Hard core!
Maybe current GPU cores/architecture, designed for vertex shading, don't map well to ray tracing, but I'd not be surprised that if ray-tracing were to become mainstream, a different highly parallel architecture (and maybe new algorithm) may be able to accelerate it.
For some games that'll be true, but I think it'll be a long time, if ever, before we see a CPU that can compete with a high end GPU especially as the bar gets higher and higher - e.g. physics simulation , ray tracing...
Note that a GPU core/thread processor is way simpler than a general purpose CPU core and so MANY more can be fit on a die. Compare an x86 chip with maybe 4 cores with something like an NVidea Tesla (CUDA) card which starts with 128 thread processors and goes up to 960(!) in a 1U format card! I think there'll always be that 10-100 factor more cores in a high end GPU vs CPU and for apps that need that degree of paralellism/power the CPU will not be a substitute.
Not if it was spinning in the horizontal plane, since then you'd not be trying to change it's plane by moving. It's also the only plane that would provide stability from falling down.
The Gyrobus used a 3 ton flywheel spinning at 3000 rpm for energy storage. I can only assume it was spinning horizontally!
Well, for that matter the Segway isn't gyroscopically balanced either - it's dynamically balanced by motors.
If a Segway included a 10lb weight being whirled around in a horizontal circle at 1000rpm, then it would be gyroscopically balanced - i.e. using the principle of conservation of angular momentum to achieve stability. That would also probably also gain it some respect/fear.
You get them here in the US for tourist use too. They have "Segway tours" in Washingtojn DC, and presumably other tourist hotspots too.
This is actually quite a good use for them - mostly entertainment with a smidgeon of utility thrown in (a 10mpg Segway will get you around faster than strolling at 3-4mph). Usage where the thing isn't left unattended also makes sense.
Contrast this to paying $4K, or whatever it is nowadays, for a device that is really only a toy because to use it for transportation you'd need to be able to leave it someplace without fear of it being stolen/vandalized.
For most practical as opposed to entertainment use an electric bicycle (which exist) makes much more sense than a Segway.
Sure, there are languages like Perl and APL that encourage good programmers to write bad code, but that's not what we're talking about here.
If you want a library that expresses common operations with intuitive operators, then that requires the languange to support it.
The kind of neophyte programmer that misapplies language features isn't going to limit it to one particular feature. The same person who abuses operator overloading because he wants to try it out, or thinks it's cool, is also going to be (in C++, for example) abusing inheritance, virtual functions, templates and everything else for the exact same reason - they want to try it out, or they want to try to look cool by using advanced features they don't actually understand. I've seen plenty of code like this, and operator overloading is the least of your problems; this is code that needs to be rewritten it it's ever to be production quality. The problem is the programmer, not the language.
Thanks for your concern over my career choices, but I'm doing fine. Maybe you learnt to program using the Pascal I implemented 25 years ago!;-)
That's an awful argument for not putting useful features into a language, because poor programmers will always write bad code, regardless of language. There's yet to be designed a language that protects you from writing bad code. Maybe one day there will be. The only protection from bad programmers is not to hire them.
What a language can do is provide features that allow good programmers to write good readable code.
There are certain things that you just expect to be implemented by certain operators, regardless of whether the underlying types are built into the language or not. Integer addition, Real addition, Complex addition, Set union, String catenation, List append. Internally we think of these things as "adding" and it's only natural to use the "+" operator for them.
Not only does operator overloading allow the programmer to implement code that maps naturally to out mental models, but it also allows more readable code to be written since it uses infix (operator) rather than prefix (function call) notation. How much easier it is to visualize the set expression (s + t) * (p + q) as opposed to Intersection(Union(s, t), Union(p, q)), or worse yet it's object orientated equivalent s.Union(t).Intersected(p.Union(q)).
The poster you relied to certainly has a point. The level of technical knowledge and experience of the average slashdotter has gone down the toilet in recent years. It used to be a mostly highly technical crowd, but now half the people here have never even programmed, or just done so for a year or two, yet have outspoken opinions on things they know nothing about.
Slashdot Mirror
That's an insane patent to have been granted. The fact that the patent holder is asserting that Facebook is infringing it without having seen their source code is extremely telling - the patent holder appears well aware that the patent (which should never have been granted) is so broad as to cover functionality rather than implementation and therefore anyone who appears to be doing what the patent covers is almost certainly infringing it.
It's as is the patent office granted someone a patent on cracking nuts as opposed to a specific nutcracker design, and the lucky patent holder would then be in a position to go after anyone selling shelled nuts on the grounds that they must have shelled them, ergo they must have violated their patent. Of course nuts, unlike software claims decribed in obfusctated legalese, are easy to understand. I'm 100% positive one could describe assigning a value to a variable in such a complex way, accounting for all possible implenentations, semantics, etc, etc, that some moron at the patent office would think it sounded like a highly technical and specific discovery and no-doubt patent worthy. I think I'll go apply for a patent of comments right now ("in the 42nd embodiment, a source code file, stored in EBDIC format on a USB storage device, embeds self-descriptive components, that will be automatically stripped by the FORmula TRANslation language lexical analyzer, ...").
Given how complex software is, and how difficult it is for lay people to understand it, and given that the patent office in granting things like this make it obvious that they do not have software experts examining these patents, it seems that the whole notion of software patents needs to be reexamined. They are really doing more harm than good, and the intent of patents to encourage innovation is being subverted rather than helped by software patents. The patent office doesn't seem to understand the process of software design/development at all.
That's all we need... an AI that's figured out how to enhance it's own intelligence by using human brains...
Maybe it won't even be conscious, just a zombie who's only motivation is to get our brains.
BRAINS...... BRAINS......
I don't believe that all decisions are irrational/subconscious, but some certainly are, and the illusion of free will is largely based around the fact that we mostly believe we chose to do whatever we did...
e.g.
In tests where hypnotized subjects have been "programmed" to perform some action upon cue (and been mislead about the purpose of the experiment), they will rationalize a reason why they did it. In one clinical study subjects initially sitting down were hypnotized to get up and open the window in the room when the experimenter gave a cue. When asked *why* they had done this, they invariable gave reasons like "it's stuffy", "it's too hot in here", etc. None said "i don't know" or "i was strangely compelled to", etc.
We similarly rationalize that we deicided to act in cases such as dropping a hot coal or swerving to avoid a collision where the fast response time can be shown to have been to quick to have involved a trip through the cortex.
It seems this is the way our brain *always* works. Since our brain is in the end just a neural net/machine, our response in any situation is entirely proscribed (even if not practically knowable ahead of time), and our cortex, being the pattern-matching machine that it is then necessarily correlates the response to any precursors and concludes a causal relationship (basically "i did this because i was thinking this") which is true, but rather misleading in as much as the "i" is the neural net, not the dualistic mind with free-will that we imagine it to be... So we go thru life correctly seeing ourself as making decisions and thus apparently exercising free will, but the latter is an illusion since the decisions we associate with our responses were in fact proscribed!
Good question! It'd be the most efficient design, but maybe I assume too much!
On reflection, the fact that make -j N>1 is a speed-up is probably a good indication that the compiler doesn't itself do a good job of separating IO from CPU usage (i.e. doesn't get the multithreaded design right).
The article isn't saying that the existing scheduler is better than BFS for make -n+1 - it's just saying that BFS doesn't need make -n+1 to keep the cores busy, which is pretty good indication that it's not IO bound (regardless of intuition to the contrary). Note that scheduling is done at thread level, and I assume the compiler is anyways doing IO, preprocessing and lexical analysis in a separate thread from parsing, etc.
Having a single scheduler (and set of tuning parameteres) doesn't necessarily makes sense. It's like saying that rather than having an F-1 car when you're racing, a minivan for bringing kids to parties, and a Hummer for off-road use, you'd prefer a one-size fits all vehicle so that you didn't have to choose. Unfortunately the design compromises that go into an off-road vehicle arn't the same as the ones that go into an F-1 car, anymore than the scheduling needs of a server (thruput) are the same as those of an interactive-use desktop machine (latency).
For myself I'd prefer an install/config option of "Optimize for server/desktop use" so that for desktop use I'm not doing the equivalent of trying to compete in a formula 1 race in a Hummer or minivan.
And the fact that BFS isn't even able to properly schedule n+1 lightly-cpu-bound processes certainly doesn't talk in it's favor.
You misinterpreted TFA.
What Con actually said was that if you have a 4 core CPU then for optminal efficiency run make -j 4 rather than make -j 5/6/etc.
This OUGHT to be the case for ANY (decent) scheduler - it ought to be more efficient to have processes assigned to cores and not needlessly being swapped in and out because you've opted to run more processes than cores to gain some efficiency.
That fact that Con's scheduler does see a benefit when number of processes = number of cores does not reflect a problem with HIS scheduler - it is a problem with the standard scheduler that in order to compensate for scheduler inefficiency you need to run more jobs than you have cores in order to try to keep all cores busy.
What YOU run is irrelevant to what's useful to other people. Most people are running desktop machines or laptops, not multi-node clusters, and anyway unless each of your cluster nodes has 16+ cores (yeah, right) YOU'd also be better off with the new scheduler.
I guess you didn't read TFA:
In the meantime if you care about CPU utilization and latency then use this. Tomorrow will take care of itself. It's not like if you buy one computer or graphics card, or build one kernel, that you're tied to it for the rest of your life. You use this year what's available and update when the situation warrants it.
Your post is not only ill-informed, but totally illogical. Which is it, are terrorists unpredictable (which itself is a pattern) or do they exhibit certain typical behaviors?!
Never too late to read TFA, you know...
Could have been a compiler (code generation) bug - you could have checked the assembler generated - or could have been a bug somewhere else in your program causing corruption. Insert/delete an arbitrary bit of code (debug statement) and the thing being corrupted changes and the bug may **appear** to have gone away (it hasn't, but it's just corrupting something harmles instead e.g. unused memory).
Just do an Indiana Jones on it.
Mr. Robot stands there hands whizzing around juggling cellphones and manipulating grains of rice at lightening speed, then you pull out a shotgun and pump his CPU full of bird shot.
I've seen a martial arts demonstration where a guy caught arrow being shot past him. He did it **blindfold**, based on hearing the release and knowing the distance! Gotta wonder how many times he got an arrow stuck in his hand before he got the timing right!
It really doesn't make much difference. If the baby is crying at night (esp. if it sleeps in your room) they your night isn't going to be so great. Trust me! (father of an adorable but sleep-depriving 6 month old baby girl).
Even without the disrupted nights a baby is going to make you tired since there's no downtime. If mom is feeding and looking after the baby, then guess who's shopping, cooking, washing up and then looking after the baby while mom has a shower, does the laundry, etc, etc?!
My first home computer from 1978 was a Z80-based NASCOM-1 which also came as a bare board kit. Thing is, back then this was the *normal* way to buy a computer, unless you had the extra money to buy one pre-assembled.
It's kinda sad that nowadays a "news for nerds" site thinks it's newsworthy when someone does something nothing more creative than soldering together a kit computer. OOh, look! Soldering iron! Hard core!
Maybe current GPU cores/architecture, designed for vertex shading, don't map well to ray tracing, but I'd not be surprised that if ray-tracing were to become mainstream, a different highly parallel architecture (and maybe new algorithm) may be able to accelerate it.
For some games that'll be true, but I think it'll be a long time, if ever, before we see a CPU that can compete with a high end GPU especially as the bar gets higher and higher - e.g. physics simulation , ray tracing...
Note that a GPU core/thread processor is way simpler than a general purpose CPU core and so MANY more can be fit on a die. Compare an x86 chip with maybe 4 cores with something like an NVidea Tesla (CUDA) card which starts with 128 thread processors and goes up to 960(!) in a 1U format card! I think there'll always be that 10-100 factor more cores in a high end GPU vs CPU and for apps that need that degree of paralellism/power the CPU will not be a substitute.
I guess the slashdot editors are just acknowledging the new slashdot demographic.
Of course it's have been better if they'd also noted that MIPS != ARM since ARM is what Android actually runs on.
it would also be fiercely difficult to turn
Not if it was spinning in the horizontal plane, since then you'd not be trying to change it's plane by moving. It's also the only plane that would provide stability from falling down.
The Gyrobus used a 3 ton flywheel spinning at 3000 rpm for energy storage. I can only assume it was spinning horizontally!
http://en.wikipedia.org/wiki/Gyrobus
Well, for that matter the Segway isn't gyroscopically balanced either - it's dynamically balanced by motors.
If a Segway included a 10lb weight being whirled around in a horizontal circle at 1000rpm, then it would be gyroscopically balanced - i.e. using the principle of conservation of angular momentum to achieve stability. That would also probably also gain it some respect/fear.
You get them here in the US for tourist use too. They have "Segway tours" in Washingtojn DC, and presumably other tourist hotspots too.
This is actually quite a good use for them - mostly entertainment with a smidgeon of utility thrown in (a 10mpg Segway will get you around faster than strolling at 3-4mph). Usage where the thing isn't left unattended also makes sense.
Contrast this to paying $4K, or whatever it is nowadays, for a device that is really only a toy because to use it for transportation you'd need to be able to leave it someplace without fear of it being stolen/vandalized.
For most practical as opposed to entertainment use an electric bicycle (which exist) makes much more sense than a Segway.
I never thought I'd see the day that a text editor needed a network-aware client-server architecture.
That day isn't here - it's only the editor that is.
Sure, there are languages like Perl and APL that encourage good programmers to write bad code, but that's not what we're talking about here.
If you want a library that expresses common operations with intuitive operators, then that requires the languange to support it.
The kind of neophyte programmer that misapplies language features isn't going to limit it to one particular feature. The same person who abuses operator overloading because he wants to try it out, or thinks it's cool, is also going to be (in C++, for example) abusing inheritance, virtual functions, templates and everything else for the exact same reason - they want to try it out, or they want to try to look cool by using advanced features they don't actually understand. I've seen plenty of code like this, and operator overloading is the least of your problems; this is code that needs to be rewritten it it's ever to be production quality. The problem is the programmer, not the language.
Thanks for your concern over my career choices, but I'm doing fine. Maybe you learnt to program using the Pascal I implemented 25 years ago! ;-)
That's an awful argument for not putting useful features into a language, because poor programmers will always write bad code, regardless of language. There's yet to be designed a language that protects you from writing bad code. Maybe one day there will be. The only protection from bad programmers is not to hire them.
What a language can do is provide features that allow good programmers to write good readable code.
There are certain things that you just expect to be implemented by certain operators, regardless of whether the underlying types are built into the language or not. Integer addition, Real addition, Complex addition, Set union, String catenation, List append. Internally we think of these things as "adding" and it's only natural to use the "+" operator for them.
Not only does operator overloading allow the programmer to implement code that maps naturally to out mental models, but it also allows more readable code to be written since it uses infix (operator) rather than prefix (function call) notation. How much easier it is to visualize the set expression (s + t) * (p + q) as opposed to Intersection(Union(s, t), Union(p, q)), or worse yet it's object orientated equivalent s.Union(t).Intersected(p.Union(q)).
The poster you relied to certainly has a point. The level of technical knowledge and experience of the average slashdotter has gone down the toilet in recent years. It used to be a mostly highly technical crowd, but now half the people here have never even programmed, or just done so for a year or two, yet have outspoken opinions on things they know nothing about.
Yeah, but Ruby doesn't need to use the Ruby VM anymore than any language is tied to a given backend.
JRuby targets the JVM
IronRuby targets the .NET/Mono CLR (i.e same VM used by C#)