There have been claims like this made throughout history. The patent office was closed because of this, bill gates once declared a maximum filesize we'd ever need, and the list goes on and on.
Sorry, I didn't mean to imply that we had come to the end of invention, even in a small area.
But all of the effective techniques *that we know about* have been implemented, and the chip makers have been banging their heads on the wall for years trying to come up with new ones. They went to multi-core processors as an absolute last resort, and 5 years later it's probably time for most programmers to accept that and learn to target multi-core platforms.
The above is only true for non-strict functional languages. Strict functional languages require the value to be known at the time of binding.
It's still true for strict functional languages, in the degenerate sense that before a variable is bound you haven't discovered its value. Which is basically the same as for a non-strict language, except that in the strict language the order of evaluation is the same as the order that the code is written down.
My point is that 16 slightly faster ones are more useful given the state of programming today.
Realistically, most code that will scale to 16 cores should scale to 64 cores. The real problem is code for 1/2 cores not scaling to 8+ cores. Once 8+ cores are common, this problem will quietly vanish as no-one clings to the 1/2 core solutions anymore. You can already see this to a large extent in server applications.
It's true that standard hash algorithms are generally serial in nature. Luckily, you can use well-tested hash algorithms to build hash trees and get the same security properties with excellent parallelism. Some modern hash algorithms are even designed for tree modes to support parallel computation.
Granted, they tend to do this on an instruction level basis, but the concepts are no different at the thread level and beyond.
That's not really true. Supporting instruction level parallelism is reasonably straightforward - you just analyses the per-instruction data dependencies and output things ordered in such a way that the hardware instruction scheduler can do it's thing. There's only one problem - optimally ordering a set of instructions is NP-hard. So if you want to do a good job ordering 5 instructions you're fine, 15 instructions is obnoxious, and 150 instructions is basically impossible.
Further, instruction level re-ordering doesn't change the basic algorithm. If you're compiling a heapsort routine, the re-ordered instructions are still going to implement heapsort. And heapsort doesn't parallelize well. Maybe you could build logic into your compiler to detect heapsort and automatically replace it with parallel quicksort, but that doesn't help you when you run into a non-sorting routine.
Realistically, programmers have to write parallel code for many-processor platforms. It's not amazingly difficult (given reasonable training and a reasonable set of tools), but it is different. But it's not something that's going to go away when the gcc guys / java team / VS.NET team implement some clever optimization.
The real question is if Intel and AMD will save some cash from their MMC(massive multi-core) projects and deliver a more sensible number of faster cores. You just can't depend on a given user's programs being set up to run efficiently in parallel.
I'd much rather have 64 fast cores than 16 slightly faster (but horribly power-inefficient) cores, and that's really the tradeoff that you're talking about. All of the reasonable ways of throwing transistors at getting faster straight-line code execution have already happened. Hell, even the unreasonable ones have been implemented, like fast 64-bit division units.
Intel and AMD have the choice of releasing dual-core processors that are 5-10% faster than last years, or they can release 4/6 core processors for about the same transistor budget. The multi-core processors are better for almost everyone - there's no way to get a 5x speedup out of a 10% faster processor.
The way it should work is that if you're implementing a pararell algorithm like merge sort http://en.wikipedia.org/wiki/Merge_sort it should just go and get a new processor core each time you make a recursive call.
How do you implement that so that for N processors each call after the Nth isn't horribly inefficient? Sometimes you want a new thread, sometimes you don't, and if you can figure out how to tell the difference with static analysis before you know about the target machine...
Well, the problem is that no matter how much you bash an algorithm with a functional language you can't magically make a sequential task into a parallel one.
Thing is, you probably have a parallel task that was already bashed into a sequential one.
Most real-world problems are parallel problems. Even the ones that aren't (say... compiling a file in C) you can usually run a lot of instances of in parallel.
What language would you recommend for an OO programmer to start with?
Scheme or Standard ML would be good places to start. One of the key points of learning a functional language, if you think of yourself as an "OO programmer", is being able to look at problems and come up with solutions that *aren't* OO, so try to avoid looking for a functional / OO hybrid language until you're comfortable with functional problem decomposition.
You mean to say that in a functional programming language, variables aren't? A paradox, a paradox, a most delightful paradox!
Functional variables are like mathematic variables - they're variable in that you may not have discovered their value yet, but once you discover their value it stays the same for the current instance of the problem. For the next instance of the problem (i.e. the next call to the function), you're talking about a different set of variables that potentially have different values.
Warner is finally doing something the EFF wanted all along... collective licensing. Shouldn't we be supporting this?
It's absolutely essential to be able to tell the difference between superficially similar policy proposals. It's very easy to change just a few words in a policy so it sounds the same but smells radically, radically different.
In this case, the key difference is mandatory vs. voluntary licensing by segments of the public. Under no circumstances is a law *ever* acceptable that requires payments from members of the public to specific private companies. That's what the RIAA is proposing here - a law that requires people to give them money forever.
How would you like it if you were a musician, and I started bootlegging every single last piece of merchandise that you every produced and gave it away for free or at just cost? Your t-shirts, your stickers, your cds, everything. Oh, and I stood there recording every live performance in high quality HD and gave it away for free to anyone too lazy or cheap to go to your show?
Interesting question. Let's imagine for a moment that all of your proposed actions are strictly legal - there is no restriction on your using my name, songs, or cover art commercially. In that case you're free advertising for me. I don't have to pay and you get people to think about my music more frequently. I better book a bigger venue for my next concert, and maybe charge more money for tickets.
Now, very few people are suggesting a legal change quite that drastic. If I just get my trademark back, and you can't sell "official looking" merchandise, then I get all the benifits of the free advertising without losing much in the way of merchandise sales.
Beyond that, it's mostly diminishing returns. Only the absolute superstar musicians make any significant amount of money on CD sales from people who wouldn't buy concert ticket or a t-shirt.
I want a system where people are allowed to listen to the music they choose without being put at risk of severe civil/criminal punishment.
If we just wait a bit and *don't* give the music industry a legally-ensured revenue stream, they'll gov out of business and stop bothering us. The only problem here is RIAA members having enough money for lawyers - and this proposal just makes that problem worse.
Richard Stallman advocates for a similar thing, a music tax on ISP connections or blank media. Like a radio station that pays an annual fee and and just reports back what they played so that the artists who were broadcasted get their cut.
Really? Do you have a reference? Usually Stallman doesn't support obviously evil ideas.
but it seems a premature optimization when a central repository works most of the time.
Evaluating experimental branches of FOSS projects like that doesn't make a lot of sense. Someone's doing this because they think it's a good idea. Either they're right and they make something great that lots of people use, or they're wrong and they learn something. Like any research, it's awfully hard to tell if it's going to pan out until someone tries it.
Think of it as abstracting away servers, sort of like the "cloud computing" concept but from a different angle. At minimum, it gives you automatic load balancing between mirrors.
I'm not sure if this particular implementation is the greatest thing since sliced bread, but there are still a ton of areas where just adding distribution + pgp signatures will make the world a better place.
That's 20Mbps symmetric for both the regular and business accounts.
If consumer accounts are symmetric, then you don't have the general problem that was being complained about in this thread to begin with. Many people are stuck with drastically asymmetric connections as the only consumer-level internet accounts available (think 10Mbps down / 1Mbps up).
They do cost more, but in my case I get 5 static IPs, guaranteed bandwidth, and no interference of any kind with my data (no port blocking, no throttling, and no caps) for $140.
Is that for a symmetric link, or do you just get a standard asymmetric account with a couple IPs and a different TOS?
Slashdot Mirror
From personal experience, compiling C program with multiple files is significantly faster on a four core machine than a one core machine.
Sorry, I didn't mean to imply that we had come to the end of invention, even in a small area.
But all of the effective techniques *that we know about* have been implemented, and the chip makers have been banging their heads on the wall for years trying to come up with new ones. They went to multi-core processors as an absolute last resort, and 5 years later it's probably time for most programmers to accept that and learn to target multi-core platforms.
It's still true for strict functional languages, in the degenerate sense that before a variable is bound you haven't discovered its value. Which is basically the same as for a non-strict language, except that in the strict language the order of evaluation is the same as the order that the code is written down.
Realistically, most code that will scale to 16 cores should scale to 64 cores. The real problem is code for 1/2 cores not scaling to 8+ cores. Once 8+ cores are common, this problem will quietly vanish as no-one clings to the 1/2 core solutions anymore. You can already see this to a large extent in server applications.
It's true that standard hash algorithms are generally serial in nature. Luckily, you can use well-tested hash algorithms to build hash trees and get the same security properties with excellent parallelism. Some modern hash algorithms are even designed for tree modes to support parallel computation.
That's not really true. Supporting instruction level parallelism is reasonably straightforward - you just analyses the per-instruction data dependencies and output things ordered in such a way that the hardware instruction scheduler can do it's thing. There's only one problem - optimally ordering a set of instructions is NP-hard. So if you want to do a good job ordering 5 instructions you're fine, 15 instructions is obnoxious, and 150 instructions is basically impossible.
Further, instruction level re-ordering doesn't change the basic algorithm. If you're compiling a heapsort routine, the re-ordered instructions are still going to implement heapsort. And heapsort doesn't parallelize well. Maybe you could build logic into your compiler to detect heapsort and automatically replace it with parallel quicksort, but that doesn't help you when you run into a non-sorting routine.
Realistically, programmers have to write parallel code for many-processor platforms. It's not amazingly difficult (given reasonable training and a reasonable set of tools), but it is different. But it's not something that's going to go away when the gcc guys / java team / VS.NET team implement some clever optimization.
I'd much rather have 64 fast cores than 16 slightly faster (but horribly power-inefficient) cores, and that's really the tradeoff that you're talking about. All of the reasonable ways of throwing transistors at getting faster straight-line code execution have already happened. Hell, even the unreasonable ones have been implemented, like fast 64-bit division units.
Intel and AMD have the choice of releasing dual-core processors that are 5-10% faster than last years, or they can release 4/6 core processors for about the same transistor budget. The multi-core processors are better for almost everyone - there's no way to get a 5x speedup out of a 10% faster processor.
I'm pretty sure that a system call will always be drastically more expensive than a function call.
How do you implement that so that for N processors each call after the Nth isn't horribly inefficient? Sometimes you want a new thread, sometimes you don't, and if you can figure out how to tell the difference with static analysis before you know about the target machine...
Thing is, you probably have a parallel task that was already bashed into a sequential one.
Most real-world problems are parallel problems. Even the ones that aren't (say... compiling a file in C) you can usually run a lot of instances of in parallel.
Scheme or Standard ML would be good places to start. One of the key points of learning a functional language, if you think of yourself as an "OO programmer", is being able to look at problems and come up with solutions that *aren't* OO, so try to avoid looking for a functional / OO hybrid language until you're comfortable with functional problem decomposition.
Functional variables are like mathematic variables - they're variable in that you may not have discovered their value yet, but once you discover their value it stays the same for the current instance of the problem. For the next instance of the problem (i.e. the next call to the function), you're talking about a different set of variables that potentially have different values.
Probably cheaper and less economically harmful to buy this insurance from an insurance company than from the record companies, etc.
It's absolutely essential to be able to tell the difference between superficially similar policy proposals. It's very easy to change just a few words in a policy so it sounds the same but smells radically, radically different.
In this case, the key difference is mandatory vs. voluntary licensing by segments of the public. Under no circumstances is a law *ever* acceptable that requires payments from members of the public to specific private companies. That's what the RIAA is proposing here - a law that requires people to give them money forever.
Interesting question. Let's imagine for a moment that all of your proposed actions are strictly legal - there is no restriction on your using my name, songs, or cover art commercially. In that case you're free advertising for me. I don't have to pay and you get people to think about my music more frequently. I better book a bigger venue for my next concert, and maybe charge more money for tickets.
Now, very few people are suggesting a legal change quite that drastic. If I just get my trademark back, and you can't sell "official looking" merchandise, then I get all the benifits of the free advertising without losing much in the way of merchandise sales.
Beyond that, it's mostly diminishing returns. Only the absolute superstar musicians make any significant amount of money on CD sales from people who wouldn't buy concert ticket or a t-shirt.
If we just wait a bit and *don't* give the music industry a legally-ensured revenue stream, they'll gov out of business and stop bothering us. The only problem here is RIAA members having enough money for lawyers - and this proposal just makes that problem worse.
Really? Do you have a reference? Usually Stallman doesn't support obviously evil ideas.
Wait a second... you're trying to make *my* tax dollars and *my* tuition go to random third parties?
Please stop. Seriously.
I'd much rather they they try (and fail) to sue my fellow UMass students than be paying them protection money.
Evaluating experimental branches of FOSS projects like that doesn't make a lot of sense. Someone's doing this because they think it's a good idea. Either they're right and they make something great that lots of people use, or they're wrong and they learn something. Like any research, it's awfully hard to tell if it's going to pan out until someone tries it.
Think of it as abstracting away servers, sort of like the "cloud computing" concept but from a different angle. At minimum, it gives you automatic load balancing between mirrors.
I'm not sure if this particular implementation is the greatest thing since sliced bread, but there are still a ton of areas where just adding distribution + pgp signatures will make the world a better place.
If consumer accounts are symmetric, then you don't have the general problem that was being complained about in this thread to begin with. Many people are stuck with drastically asymmetric connections as the only consumer-level internet accounts available (think 10Mbps down / 1Mbps up).
Is that for a symmetric link, or do you just get a standard asymmetric account with a couple IPs and a different TOS?
Blech. Then you have to deal with the PHB *and* the mess. I'm not sure if I'd be up to dealing with that for only 1.5x standard pay, personally.
Oh no, not a less than optimal query!
What's the TCO increase of that happening? How likely is it to be a problem? If it is, how hard is it to fix?
I love it when they do that. It takes bad programmers off the market, which is good for everyone else.