On 5 March 2011 18:22, Reinier Zwitserloot <[email protected]> wrote:
> ... but that's exactly the cognitive dissonance I'm talking about. > Fine-grained parallellism doesn't appear, to me, to be capable of giving you > more than a roughly 10x to 60x speedup for the very long foreseeable future, > and that's being extremely generous here (and I'm comparing to taking the > opportunity to parallelize in-the-large where-ever the opportunity arises, > not a strict 'use only one core and the rest might as well not exist' > model). > > Using non-algorithmic optimizations such as reducing object creation > (obviously refer to your profiler report, any object creation that hotspot > escape analysis can eliminate or which don't cause a measurable performance > hit shouldn't be touched) can do something on the scale of 2x to 40x. > > Clearly the same order of magnitude. Both require massive changes to your > code layout, both require a lot of knowledge on finicky topics, and both > strongly prefer the use of profilers and other tooling to ensure you're > actually making progress, speed-wise, because its very easy to get either an > optimization wrong (because your code gets hotspotted into something you > didn't expect), or a parallelized operation wrong (because you're > accidentally causing a long long someplace by accident, both impossible to > test without proper profiling). With a lot of work we can probably reduce > the rate at which programmers screw up the performance benefits of > parallelizing their code, but performance is difficult to unit test, no > matter how focussed-on-multicore your language and libraries are. (neither > java nor scala is ready for multi-core right now. For example, java has no > closures, and scala still has the fundamentally impossible to parallelize > foldLeft and foldRight defined as operators out-of-the-box - that's the kind > of work I'm talking about). > So you define a language as being unsuitable for concurrent use so long as it has even a single method, defined *anywhere* in any standard library, that works in an imperative manner. By that logic. SQL is highly parallel until such point as you add cursors - at which point it becomes unready for concurrency - whether you even use the cursors or not... I beg to differ. Just as with SQL cursors, folds aren't really idiomatic Scala, though they tend to be used heavily by a certain subset of Scala programmers, particularly those who came to the language with a lot of Haskell experience. As of Scala 2.9 (ready for imminent release), idiomatic use will be parallel collections that have a great many declarative operations which aren't folds. I'd also argue that even fold operations *can* be made parallel in some circumstances - by rewriting the AST - so long as the inputs to that fold are known to be defined in terms of `zero` and `append` for some monoid. Admittedly, these are advanced terms, but nobody ever claimed that language/compiler design was easy, and the whole point of tricks like AST rewriting is to hide such complexity from language users. This kind of rewriting is exactly the sort of thing that virtualised Scala is aiming to achieve with its recent European grant. > The similarities seem rather obvious when its put that way. So, why is one > (non-algorithmic optimizing) so bad that its equated to being "the root of > all evil" in a rather famous quite, whereas the other is almost universally > espoused as what a proper programmer at the pinnacle of his craft is working > on? > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- Kevin Wright gtalk / msn : [email protected] <[email protected]>mail: [email protected] vibe / skype: kev.lee.wright quora: http://www.quora.com/Kevin-Wright twitter: @thecoda "My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger" ~ Dijkstra -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
