Creating processes on Linux is exactly the same overhead as threads (they both use the same syscall, clone()) and both are comparable in performance to creating threads on Windows and Solaris.
There are a bunch of flags passed to clone() that specify which aspects of the task are shared between the old and new tasks and which ones aren't. I imagine there's a performance difference between "all shared" and "all different." But I'm just guessing; please comment.
When technology hits a dead end on one track, the industry goes looking for another track where progress can be made. A few brilliant people stay at the dead end beating their brains against the wall. You can stand there with your arms folded, tapping your foot, waiting for the brilliant people to knock down the wall, but I'm going to pursue the low-hanging fruit elsewhere. When they do knock it down, I'll be right behind you, and what will I have lost?
If you're willing to give up a little bit of performance for a lot of reliability, why not use a language with a few safety and concurrency features built in? Then you don't have to worry about code scribbling all over memory, and you have to worry less about protecting shared resources. Shared memory isn't much protection against either of those. If a process needs to maintain any state at all, then putting incorrect data into its shared memory space will put it off on the wrong track, requiring a shutdown or really complex recovery logic. Using multiple processes with shared memory doesn't do anything to decrease the likelihood of poor protection of shared resources, either, which is the most common cause of concurrency issues.
The difference between processes and threads isn't very important compared to the quality of the program design and the safety of the programming language. In practice I think the biggest advantage of using processes is that the awkwardness of using shared memory motivates lazy designers to come up with better designs with less sharing.
Thesaurus lookup would come in handy once in a while, but much more often I use specific language to get the hits I want. When I know a word that is mostly particular to one group people or one style of writing, I can use it to limit your searches. Until we reach the point where a search engine can understand the intent behind different search terms, I'd much prefer a stupid tool that trusts my word (yuk yuk) and doesn't use its "intelligence" to draw in a bunch of results I'm trying to leave out.
The problem with the Semantic Web is that it can't decide whether to enable dumb, limited, ad-hoc models of intelligence -- traditional, logical programming in which data and behavior are precisely specified -- or a general-purpose semantic model using original reasoning about discrete concepts. The first option has been happening for years in small, unexciting ways and will not be advanced in any way by the Semantic Web. The second is a perennial pipe dream of AI. Maybe the global scale of the internet, the masses of data and computing power, will finally make this dream a reality, but we have no good reason for believing so. More likely we will end up with tools just smart enough to be useless, like a search engine that always uses thesaurus lookup.
In other words, when he stopped managing himself and started managing other people, he suddenly realized that things he could impose by fiat and evaluate at a glance were much more important than he previously thought. What a shocker.
When you only have a hammer, the whole world's a nail, and when your only tool is ordering people around, you tend not to give a damn about anything that can't be accomplished that way.
For a 27-year-old example of prior art, see Data Structure Techniques, Thomas A. Standish, Adison-Wesley, (c) 1980, ISBN 0-201-07256-4, chapter 5, section 5.3.2.4 Threaded Lists: "Threaded lists are pure lists in which additional linkage structures called "threads" have been added to provide for traversals in special orders."
Just giving the parent post some visibility. Nice find, give him a mod point.
What he's saying, which is absolutely true, is that it makes more sense to simply charge everyone for their emissions.
There's a big difference between managing one's own environmental footprint through personal choices and managing society's footprint through public policy. It's a false choice to say that one trumps or invalidates the other. They can (in most cases) and should be pursued independently. Responding to one by talking about the other, as the GGP did, is just a clever way of changing the subject.
Those points aren't original, nor are they unfamiliar to people concerned with the environment. They're all covered in my copy of The Consumer's Guide to Effective Environmental Choices, a quick-reading layman's paperback which has been out for years. I'm not sure that the environmental penalty of newer, less-developed technologies is discussed in the context of cars, but it is explained and discussed with respect to other products.
The bad numbers are all that is original. So the report that contains much that is new, and much that is true, but what is true is not new and what is new is not true. What's the point, then?
I guess if he wants to push open source, he should find someone who will install, configure, and support a complete open-source solution. It's better to pay those guys than a commercial company, since some of your dollars will pay for testing and enhancing open-source projects.
Those decisions clearly explain their assumptions and reasoning. I imagine that any court faced with a decision where the stated assumptions and reasoning of existing decisions don't apply would feel quite free to make its own decisions.
For instance, the stated reasoning would apply to many C++ header files, but not to the template-heavy C++ header files in the Boost libraries or in an implementation of the Standard Template Library.
Implemenation swapping frequency is exaggerated in most literature in my opinion.
I have to say that in my experience, the messiness of the real world is what forces implementation swapping. Half a dozen input file formats, misimplemented variations on those formats, the need to support both local and distributed processing, the need to interface with different forms of flow control, a long list of optional data filters, motley assortments of hardware peripherals that act differently but serve the same function -- we have to use exactly the ones available in the machine, even if they are of several different kinds --, etc. Polymorphism is the only thing that keeps my code readable, and the partial ignorance enabled by polymorphism is the only way I can wrap my head around the whole thing.
I don't doubt that other domains have different demands, but in my case, I am constantly faced with things that serve the same function but have very different implementations.
And let me add that I include many experienced managers in the category of "inexperienced developers." A programmer comes out of college thinking, "Everything is easy; these guys must not be too bright if they're having problems." If he makes it into management without having an attitude adjustment, he's going to blame all his failures on the fact that his developers are missing some wonderful insight that he possesses. Then he grabs onto different fads as ways of making his programmers see the light. If the great new thing is just a repackaging of something he already knows, so much the better, since he already knows everything.
People have a tendency to confuse bluster and arrogance with ability and experience.
They do, yet in my experience, these things are inversely correlated.
I have a math degree and am now taking CS classes. It seems to me that in contrast to mathematics and physics training, the CS curriculum makes computing seem easier than it really is. There's a pervasive "it's simple" attitude that is enabled by focusing on solved problems and simple situations. I wonder if that has anything to do with why inexperienced developers get themselves into trouble with their arrogance.
The other response said it all, but here's another way of looking at it:
For a processor, the minimum clock speed required is
(rate of incoming data) * (# of instructions to process a unit of data) / (average number of instructions per clock cycle, aka IPC)
For a nicely pipelined hardware design, you could theoretically get away with a clock rate equal to the rate of incoming data, or even less, if you can process more than one unit of data per clock and have a separate, higher-clocked piece capturing the input.
The original poster seems to want a lot of control and the possibility of tinkering with different configurations -- "Be a kick to have it in a relatively standard box, with easily replaceable components." Working with FPGAs gives you that software-like ability to create or download new components and rearrange them to fit your needs. A DSP board gives you one fixed layout of components. Plus, you can have fun turning the FPGA into anything else you want.
You can buy a decent FPGA development board and turn it into a DSP for the price of a high-end graphics card. It isn't a trivial project to get started with, but it might be easier than using a GPU. Plus, the skills and hardware from this project will take you much farther than GPU skills.
Get started here and find some example DSP cores here.
I don't mean that the official.NET APIs will be riddled with dependencies, but that the open-source ecosystem (which is very important in Java, less so now that many official APIs have copied ideas and designs from open source projects) will have these crazy dependencies. I've ported a couple (okay, exactly two) chunks of Windows code to Linux, and both times all of the functionality was in GUI controls, even though it wasn't intrinsically dependent on a GUI. The programmer just assumed it would always be used as part of a GUI application, and he designed it to be impossible to use any other way. In one case the programmer wasn't a total chump. The application scanned, probed, and configured a class of hardware devices (using WinDriver, a cross-platform PCI interface library, in case you're wondering why PCI code was portable to Linux), and all the code to twiddle the registers and read the PCI configuration spaces and so forth was in button-push handlers. The app ran solidly, looked nice, and seemed professional in every way except the bizarre code organization. If this is a common practice in the Windows world, then Mono developers are going to have a hard time benefiting from.NET open-source projects.
OTOH, it seems that many of the Boost developers are Windows guys, so Windows programmers can't be stereotyped as modularity-impaired GUI addicts.
Take a look at what people got themselves into with MFC in C++, and then see how well laid out a chump app is with.NET and C#.
Forgive my cynicism, but hasn't Microsoft ported all their wonderful spaghetti-producing IDE wizards to.NET? Won't.NET development be just as "easy" and "productive" as MFC programming?
Given that datasets and user expectations are growing along with speed, you should imagine an expanding universe in which I can walk 10,000 miles per hour, but I have to go 5,000 miles to get to the grocery store and buy milk:-P
Is it safe to bet on Mono? Linux developers I know seem to be assuming that MS will find a way to keep Mono one step behind. They like.NET and would love to develop for it, but they're scared to.
They're also scared that the.NET ecosystem developed by Windows programmers will have all kinds of weird and unexpected dependencies... that every web services framework and cryptography library and logging API will end up requiring Windows Forms and DirectX. (After all, every Windows program seems to hide all its functionality inside GUI controls, which makes just as much sense.)
My question is where the hell does this guy think that 10X faster is, first, impressive, and secondly worth a damn? Has he never heard of time complexity?
Whether I walk, ride my bike, or drive my car, I cover a distance that is roughly linear with time. Are all of these methods are roughly equivalent? Join the real world. I care whether my build finishes in twenty seconds or two hundred seconds. I care whether my text editor takes 200 milliseconds or 2 seconds to respond to a command.
Of course performance differences of this kind depend heavily on architecture and implementation, so it's suspicious to see an announcement without any architectural details.
You say, "Addiction is not a valid concept," and then casually mention free will. That's the best laugh I've had all day.
By the way, I found the Rat Park link very fascinating, and I wish more research was done along those lines, but I don't see that it even has the potential to invalidate the concept of addiction. Physical withdrawal from some substances is an observable physiological phenomenon. It makes sense that given the opportunity to use a drug, people or rats use more, become addicted more easily, and have a much harder time quitting when they are exposed to severe psychological stress. It's possible -- and I think this is what experiments like Rat Park have the potential to prove -- that external psychological stress can be a necessary factor for addiction to a drug of a certain kind and potency. That doesn't invalidate addiction any more than the polio vaccine invalidates the concept of polio.
Of course, free will has nothing to do with any of this -- free will can't be tested in a scientific experiment.
You've shown why the article is very poor advocacy
on
From Bess to Worse
·
· Score: 1
I have to say the article writer pissed me off quite a bit by opening the door to this topic. When you're looking for support on a moderately controversial cause, it's counterproductive to burden it with much more controversial views. It cuts down the number of people the article can be shown to and suggests that the two views have to go hand in hand.
Writers, keep in mind that persuading people who might disagree with you is very, very different from whipping up support among people who already agree with you. We need much more of the former and rather less of the latter, and the latter should not be exposed to people who disagree with you, because it is apt to insult and alienate them.
Slashdot Mirror
There are a bunch of flags passed to clone() that specify which aspects of the task are shared between the old and new tasks and which ones aren't. I imagine there's a performance difference between "all shared" and "all different." But I'm just guessing; please comment.
When technology hits a dead end on one track, the industry goes looking for another track where progress can be made. A few brilliant people stay at the dead end beating their brains against the wall. You can stand there with your arms folded, tapping your foot, waiting for the brilliant people to knock down the wall, but I'm going to pursue the low-hanging fruit elsewhere. When they do knock it down, I'll be right behind you, and what will I have lost?
And of course everyone here will get bored and leave before they finish downloading the movie.
If you're willing to give up a little bit of performance for a lot of reliability, why not use a language with a few safety and concurrency features built in? Then you don't have to worry about code scribbling all over memory, and you have to worry less about protecting shared resources. Shared memory isn't much protection against either of those. If a process needs to maintain any state at all, then putting incorrect data into its shared memory space will put it off on the wrong track, requiring a shutdown or really complex recovery logic. Using multiple processes with shared memory doesn't do anything to decrease the likelihood of poor protection of shared resources, either, which is the most common cause of concurrency issues.
The difference between processes and threads isn't very important compared to the quality of the program design and the safety of the programming language. In practice I think the biggest advantage of using processes is that the awkwardness of using shared memory motivates lazy designers to come up with better designs with less sharing.
Thesaurus lookup would come in handy once in a while, but much more often I use specific language to get the hits I want. When I know a word that is mostly particular to one group people or one style of writing, I can use it to limit your searches. Until we reach the point where a search engine can understand the intent behind different search terms, I'd much prefer a stupid tool that trusts my word (yuk yuk) and doesn't use its "intelligence" to draw in a bunch of results I'm trying to leave out.
The problem with the Semantic Web is that it can't decide whether to enable dumb, limited, ad-hoc models of intelligence -- traditional, logical programming in which data and behavior are precisely specified -- or a general-purpose semantic model using original reasoning about discrete concepts. The first option has been happening for years in small, unexciting ways and will not be advanced in any way by the Semantic Web. The second is a perennial pipe dream of AI. Maybe the global scale of the internet, the masses of data and computing power, will finally make this dream a reality, but we have no good reason for believing so. More likely we will end up with tools just smart enough to be useless, like a search engine that always uses thesaurus lookup.
In other words, when he stopped managing himself and started managing other people, he suddenly realized that things he could impose by fiat and evaluate at a glance were much more important than he previously thought. What a shocker.
When you only have a hammer, the whole world's a nail, and when your only tool is ordering people around, you tend not to give a damn about anything that can't be accomplished that way.
Because we don't have robots to keep our physical stuff in order, only computers to keep our information in (virtual) order.
Just giving the parent post some visibility. Nice find, give him a mod point.
There's a big difference between managing one's own environmental footprint through personal choices and managing society's footprint through public policy. It's a false choice to say that one trumps or invalidates the other. They can (in most cases) and should be pursued independently. Responding to one by talking about the other, as the GGP did, is just a clever way of changing the subject.
Those points aren't original, nor are they unfamiliar to people concerned with the environment. They're all covered in my copy of The Consumer's Guide to Effective Environmental Choices, a quick-reading layman's paperback which has been out for years. I'm not sure that the environmental penalty of newer, less-developed technologies is discussed in the context of cars, but it is explained and discussed with respect to other products.
The bad numbers are all that is original. So the report that contains much that is new, and much that is true, but what is true is not new and what is new is not true. What's the point, then?
Of course you have to assume a vacuum; they asked a physicist, not an engineer. The physicist also assumed a spherical Hummer....
I guess if he wants to push open source, he should find someone who will install, configure, and support a complete open-source solution. It's better to pay those guys than a commercial company, since some of your dollars will pay for testing and enhancing open-source projects.
Those decisions clearly explain their assumptions and reasoning. I imagine that any court faced with a decision where the stated assumptions and reasoning of existing decisions don't apply would feel quite free to make its own decisions.
For instance, the stated reasoning would apply to many C++ header files, but not to the template-heavy C++ header files in the Boost libraries or in an implementation of the Standard Template Library.
I have to say that in my experience, the messiness of the real world is what forces implementation swapping. Half a dozen input file formats, misimplemented variations on those formats, the need to support both local and distributed processing, the need to interface with different forms of flow control, a long list of optional data filters, motley assortments of hardware peripherals that act differently but serve the same function -- we have to use exactly the ones available in the machine, even if they are of several different kinds --, etc. Polymorphism is the only thing that keeps my code readable, and the partial ignorance enabled by polymorphism is the only way I can wrap my head around the whole thing.
I don't doubt that other domains have different demands, but in my case, I am constantly faced with things that serve the same function but have very different implementations.
And let me add that I include many experienced managers in the category of "inexperienced developers." A programmer comes out of college thinking, "Everything is easy; these guys must not be too bright if they're having problems." If he makes it into management without having an attitude adjustment, he's going to blame all his failures on the fact that his developers are missing some wonderful insight that he possesses. Then he grabs onto different fads as ways of making his programmers see the light. If the great new thing is just a repackaging of something he already knows, so much the better, since he already knows everything.
I have a math degree and am now taking CS classes. It seems to me that in contrast to mathematics and physics training, the CS curriculum makes computing seem easier than it really is. There's a pervasive "it's simple" attitude that is enabled by focusing on solved problems and simple situations. I wonder if that has anything to do with why inexperienced developers get themselves into trouble with their arrogance.
The other response said it all, but here's another way of looking at it:
For a processor, the minimum clock speed required is
(rate of incoming data) * (# of instructions to process a unit of data) / (average number of instructions per clock cycle, aka IPC)
For a nicely pipelined hardware design, you could theoretically get away with a clock rate equal to the rate of incoming data, or even less, if you can process more than one unit of data per clock and have a separate, higher-clocked piece capturing the input.
The original poster seems to want a lot of control and the possibility of tinkering with different configurations -- "Be a kick to have it in a relatively standard box, with easily replaceable components." Working with FPGAs gives you that software-like ability to create or download new components and rearrange them to fit your needs. A DSP board gives you one fixed layout of components. Plus, you can have fun turning the FPGA into anything else you want.
Get started here and find some example DSP cores here.
OTOH, it seems that many of the Boost developers are Windows guys, so Windows programmers can't be stereotyped as modularity-impaired GUI addicts.
Forgive my cynicism, but hasn't Microsoft ported all their wonderful spaghetti-producing IDE wizards to .NET? Won't .NET development be just as "easy" and "productive" as MFC programming?
Given that datasets and user expectations are growing along with speed, you should imagine an expanding universe in which I can walk 10,000 miles per hour, but I have to go 5,000 miles to get to the grocery store and buy milk :-P
Is it safe to bet on Mono? Linux developers I know seem to be assuming that MS will find a way to keep Mono one step behind. They like .NET and would love to develop for it, but they're scared to.
.NET ecosystem developed by Windows programmers will have all kinds of weird and unexpected dependencies... that every web services framework and cryptography library and logging API will end up requiring Windows Forms and DirectX. (After all, every Windows program seems to hide all its functionality inside GUI controls, which makes just as much sense.)
They're also scared that the
Whether I walk, ride my bike, or drive my car, I cover a distance that is roughly linear with time. Are all of these methods are roughly equivalent? Join the real world. I care whether my build finishes in twenty seconds or two hundred seconds. I care whether my text editor takes 200 milliseconds or 2 seconds to respond to a command.
Of course performance differences of this kind depend heavily on architecture and implementation, so it's suspicious to see an announcement without any architectural details.
You say, "Addiction is not a valid concept," and then casually mention free will. That's the best laugh I've had all day.
By the way, I found the Rat Park link very fascinating, and I wish more research was done along those lines, but I don't see that it even has the potential to invalidate the concept of addiction. Physical withdrawal from some substances is an observable physiological phenomenon. It makes sense that given the opportunity to use a drug, people or rats use more, become addicted more easily, and have a much harder time quitting when they are exposed to severe psychological stress. It's possible -- and I think this is what experiments like Rat Park have the potential to prove -- that external psychological stress can be a necessary factor for addiction to a drug of a certain kind and potency. That doesn't invalidate addiction any more than the polio vaccine invalidates the concept of polio.
Of course, free will has nothing to do with any of this -- free will can't be tested in a scientific experiment.
I have to say the article writer pissed me off quite a bit by opening the door to this topic. When you're looking for support on a moderately controversial cause, it's counterproductive to burden it with much more controversial views. It cuts down the number of people the article can be shown to and suggests that the two views have to go hand in hand.
Writers, keep in mind that persuading people who might disagree with you is very, very different from whipping up support among people who already agree with you. We need much more of the former and rather less of the latter, and the latter should not be exposed to people who disagree with you, because it is apt to insult and alienate them.