Yes, each individual transaction is light, but you would need millions of users accessing the software every hour to start building up any useful amount of information.
This has been proposed. Sadly it's pretty difficult to tell the difference between a driver and a passenger... unless it was RFID based and there was active RFID in your own car that switched off your phone and nobody else's. Problem is, the Bluetooth hands-free option is pretty popular in car showrooms.
Taking multiple photographs from the same (or nearly the same) points at different times of day would also help get the colours and light reflectance right, I would have thought.
Apps are 10000% more memory hungry than websites. I have been knocked sideways by the memory requirements of many trivial little apps. What sort of overpowered runtimes are they using bundled with there apps? It's utterly ridiculous.
Where's the money in it? You need vast amounts of data to be useful (like several hundred users per supermarket) and somebody's going to have to pay for the server infrastructure. Anything you do to get money out of the supermarkets is going to compromise the integrity of the product.
But once you unbundle the medium from its dedicated app, you lose brand awareness. None of the providers want to commoditise their channel, as where would the money be coming from if nobody realised they were using your services? Remember that many companies are running "freemium" services -- Skype, for example, who are trying to get enough income from Skype Credit to cover the running of the basic service. This was also why they were so slow to offer free video conferencing -- it was originally a premium/professional service that they made cash on. They must have been tracking the curves on the fall-off of their commercial clients and judging when it was finally worth opening it up to everyone to avoid losing market share to Google etc.
Even edible berries and flowers can be dangerously close to toxic ones. The interesting idea is that the app's errors might be different from a human's, but errors are errors, and death is fatal.
Memory bus speed is increasing, and therefore the cost of cache misses is decreasing. One way or another, that still leaves us with cache misses as a bottleneck. The question is not a straightforward one of "memory bus speeds are increasing so who gives two hoots" -- there is a very subtle equation needed to determine what cache size is optimal with what bus speed, and for which task.
You're quite right -- browsing is I/O bound, and the fact that Firefox refuses to render many pages mid-load is a design decision, and nothing to do with either serial-vs-parallel or concurrency. The place where Firefox still stutters on concurrency is where an object in one page crashes all the pages with objects of the same time. The main selling point of the original Google Chrome was threading Javascript, Flash et al so that no one page would kill the browser.
My personal view is that the problem comes from looking at a program with a single paradigm. I'd love to see FP as a subsystem, where control code is on the outside in procedural style and all the heavy work is buried in strict functions. At the moment, trying to code in that style is overcomplicated, and in the end usually results in coding in a language that doesn't guarantee immutability and you end up having to hunt down phantom mutation bugs, which kind of defeats the purpose of the exercise.
Functional programming makes the conceptual load easier, but it's not a magic bullet. The algorithmic problems are still there, because sometimes you need to update the database.
OK, functional programming isn't a good paradigm for database implementation, but DBMSes are typically a prewritten blackbox. Given that most mutability in large systems is best done as a database anyway, and then the DBMS will handle the lion's share of the resource locking anyway.
Not true, because if the processes are IO bound (and most are), most of the processes will be waiting anyway. But Linus's argument hangs on a more fundamental problem: memory bandwidth. If all the cores are sitting waiting because the data isn't in the cache and the other cores are already trying to use the memory bus, then you'll end up with more unused cycles than if you ran timesliced threads on a single core. The correct answer to this one cannot be made by reasoning and logic from first principles, but only by looking at raw empirical data. I daresay Linus has more of that than most of us here.
Cache misses are a problem, but caching is subject to the law of diminishing returns -- it takes an exponential growth in cache size to get a linear reduction in cache misses. Has Torvalds run the numbers and determined where the crossover point of the two lines is? Even then, the best solution depends very heavily on the task in question. General purpose computing has always been a compromise.
If there's a hard break in the ebook (ie new chapters start on new pages), you can divide-and-conquer at page breaks and number as x+1, x+2,... x+n and then substitute for x when the previous calculation finishes. The GP's problem isn't that he's waiting for page numbers, but that he's waiting to see his book. It's the reader software that's waiting for the page numbers before it allows him to see the current page. From the user's perspective, having the page visible immediately with "page ?? of ??" at the bottom for the next few minutes is infinitely preferable to waiting a few minutes to get everything at once.
Of course, this doesn't need parallelisation -- it could just as easily be done in a single core:
1. Search back from current page to previous hard break.
2. Repaginate x+n until next hard break found
3. Render to screen as "page ?? of ??"
4. Repaginate from beginning of text to start of current segment.
5. Update screen to show (for example) "page 8123 of ??".
6. Repaginate remainder of document.
7. Update total page number, eg "page 8123 of 10424".
That iBooks doesn't do this is a result of design, and mostly based on assumptions of book length. The GP's call for parallelisation is wasted, as if they see such cases as his to be rare enough as to be negligible, they most likely wouldn't bother parallelising the code on a more parallel computer anyway.
Immutability gets rid of problems of atomicity. Functional Programming is therefore a viable paradigm for parallel computing. Even if Scala is a bad example in terms of implementation, Odersky was right in deciding that scalability worked better with immutability-by-default. Mutability is there if you need it, but it's a conscious choice, which forces you to think carefully about it.
You need a number of bit flips to solve a problem. Energy is related to the number of bits flipped. If you use twice the bits at half the speed, the energy requirements will be the same. By splitting the workload over multiple cores you have more overhead, so more energy is required.
Energy is related to the number of bits flipped... true. But there are also other factors in the equation. A more efficient processor uses less energy to flip a bit. Slower processors are generally more efficient.
Now, the GP poster told us he's a researcher working on parallelism and efficiency. What is your qualification that allows you to dismiss his expertise and assume that he's writing crap software to test out his theories?
Slashdot Mirror
Yes, each individual transaction is light, but you would need millions of users accessing the software every hour to start building up any useful amount of information.
Indeed, and WordLens isn't a good example of MT, but an excellent example of OCR. If only the engine was available as an OCR tool.
This has been proposed. Sadly it's pretty difficult to tell the difference between a driver and a passenger... unless it was RFID based and there was active RFID in your own car that switched off your phone and nobody else's. Problem is, the Bluetooth hands-free option is pretty popular in car showrooms.
Taking multiple photographs from the same (or nearly the same) points at different times of day would also help get the colours and light reflectance right, I would have thought.
I personally make the same distinction as I did in the 80s -- app -> application -> serious software. IE all user-space software that isn't a game.
Apps are 10000% more memory hungry than websites. I have been knocked sideways by the memory requirements of many trivial little apps. What sort of overpowered runtimes are they using bundled with there apps? It's utterly ridiculous.
Where's the money in it? You need vast amounts of data to be useful (like several hundred users per supermarket) and somebody's going to have to pay for the server infrastructure. Anything you do to get money out of the supermarkets is going to compromise the integrity of the product.
A pretty good recreation of desktop functionality, then...?
iPython used to compile native apps. Apple told them to stop it, or get kicked off the App Store.
But once you unbundle the medium from its dedicated app, you lose brand awareness. None of the providers want to commoditise their channel, as where would the money be coming from if nobody realised they were using your services? Remember that many companies are running "freemium" services -- Skype, for example, who are trying to get enough income from Skype Credit to cover the running of the basic service. This was also why they were so slow to offer free video conferencing -- it was originally a premium/professional service that they made cash on. They must have been tracking the curves on the fall-off of their commercial clients and judging when it was finally worth opening it up to everyone to avoid losing market share to Google etc.
Even edible berries and flowers can be dangerously close to toxic ones. The interesting idea is that the app's errors might be different from a human's, but errors are errors, and death is fatal.
Memory bus speed is increasing, and therefore the cost of cache misses is decreasing. One way or another, that still leaves us with cache misses as a bottleneck. The question is not a straightforward one of "memory bus speeds are increasing so who gives two hoots" -- there is a very subtle equation needed to determine what cache size is optimal with what bus speed, and for which task.
You're quite right -- browsing is I/O bound, and the fact that Firefox refuses to render many pages mid-load is a design decision, and nothing to do with either serial-vs-parallel or concurrency. The place where Firefox still stutters on concurrency is where an object in one page crashes all the pages with objects of the same time. The main selling point of the original Google Chrome was threading Javascript, Flash et al so that no one page would kill the browser.
My personal view is that the problem comes from looking at a program with a single paradigm. I'd love to see FP as a subsystem, where control code is on the outside in procedural style and all the heavy work is buried in strict functions. At the moment, trying to code in that style is overcomplicated, and in the end usually results in coding in a language that doesn't guarantee immutability and you end up having to hunt down phantom mutation bugs, which kind of defeats the purpose of the exercise.
Functional programming makes the conceptual load easier, but it's not a magic bullet. The algorithmic problems are still there, because sometimes you need to update the database.
OK, functional programming isn't a good paradigm for database implementation, but DBMSes are typically a prewritten blackbox. Given that most mutability in large systems is best done as a database anyway, and then the DBMS will handle the lion's share of the resource locking anyway.
Perhaps not, but should someone get fired because people think a word they used is related to a racial epitaph, when it isn't?
No.
Not true, because if the processes are IO bound (and most are), most of the processes will be waiting anyway. But Linus's argument hangs on a more fundamental problem: memory bandwidth. If all the cores are sitting waiting because the data isn't in the cache and the other cores are already trying to use the memory bus, then you'll end up with more unused cycles than if you ran timesliced threads on a single core. The correct answer to this one cannot be made by reasoning and logic from first principles, but only by looking at raw empirical data. I daresay Linus has more of that than most of us here.
Cache misses are a problem, but caching is subject to the law of diminishing returns -- it takes an exponential growth in cache size to get a linear reduction in cache misses. Has Torvalds run the numbers and determined where the crossover point of the two lines is? Even then, the best solution depends very heavily on the task in question. General purpose computing has always been a compromise.
Of course, this doesn't need parallelisation -- it could just as easily be done in a single core:
1. Search back from current page to previous hard break.
2. Repaginate x+n until next hard break found
3. Render to screen as "page ?? of ??"
4. Repaginate from beginning of text to start of current segment.
5. Update screen to show (for example) "page 8123 of ??".
6. Repaginate remainder of document. 7. Update total page number, eg "page 8123 of 10424".
That iBooks doesn't do this is a result of design, and mostly based on assumptions of book length. The GP's call for parallelisation is wasted, as if they see such cases as his to be rare enough as to be negligible, they most likely wouldn't bother parallelising the code on a more parallel computer anyway.
And of course, every HTML document is a tree, and any tree can be parallelised.
Immutability gets rid of problems of atomicity. Functional Programming is therefore a viable paradigm for parallel computing. Even if Scala is a bad example in terms of implementation, Odersky was right in deciding that scalability worked better with immutability-by-default. Mutability is there if you need it, but it's a conscious choice, which forces you to think carefully about it.
On the other hand, if most people think your word means something different, it's not worth using that word.
Git isn't a performance system, though. The timescales it works on are completely different from those of desktop computing.
Well, embedded images, flash animations, iframes etc can all be handled in parallel. They're certainly threadable.
You need a number of bit flips to solve a problem. Energy is related to the number of bits flipped. If you use twice the bits at half the speed, the energy requirements will be the same. By splitting the workload over multiple cores you have more overhead, so more energy is required.
Energy is related to the number of bits flipped... true. But there are also other factors in the equation. A more efficient processor uses less energy to flip a bit. Slower processors are generally more efficient.
Now, the GP poster told us he's a researcher working on parallelism and efficiency. What is your qualification that allows you to dismiss his expertise and assume that he's writing crap software to test out his theories?