On 5 March 2011 04:59, Reinier Zwitserloot <[email protected]> wrote:
> A notion struck me earlier today: I used to agree in principle on the party > line espoused by just about every advocate of scala, clojure, and adding > functional features to java, and even people like Brian Goetz, that the > future is multicore and, and this is the one I might not agree with anymore: > That apps need to take advantage of it. > > Do they? What are we talking about here? Let's take a hypothetical box with > 64 cores. A bunch of these will be dedicated to running system-level > maintainance jobs; the kernel will want one or two to manage processes and > streamline disk caches and the like. Your music player and chat programs and > such will gladly take 4ish. Also, you always lose some efficiency n the > process of going multicore, so as a purely practical matter, highly > efficient parallelizing "in the small" (i.e. using ParallelArray) will net > you maybe, at best, a 40x speedup. > > This isn't actually relevant for the vast majority of computer apps. Take > for example regexp application: A thompson/NFA regexp engine will easily run > anywhere from 500 to 100000000000000000000000x faster for a complex regexp > with a lot of backtracking vs. a more naive implementation, and for simple > regexps it just doesn't matter because they finish in nanoseconds anyway, > parallelized or not. 40x is either irrelevant (because its so fast you > barely notice), or its irrelevant (because due to algorithmic complexity > this app isn't finishing no matter how nicely its parallelized). Sure, 40x > in the abstract is nothing to sneeze at, but it's not nearly as important as > it initially sounds, or at least, that's what I thought of earlier today. > > Secondly, even without extensive "in the small" parallellization (which in > java is annoying, because you really need closures and possibly language > primitives to do parallelized foreaches and such), you can very easily > parallelize in the large, especially in cases where speed is actually going > to be relevant: > > - Web Servers can easily parallelize requests, especially if the framework > is programmed with this in mind. For example, with appropriately configured > transactions on an MVCC database such as postgres, using the > 'RetryException' mechanic, hundreds of threads can happily write and read to > the same part of the same table without too many issues. This is already > happening today. > > - Something like eclipse or netbeans can easily parallelize the 'Parse > ASTs' phases. Eclipse in fact already first splits a source file up into > parts (for example, 1 method declaration is one part), and will then parse > each part separately. Parallelizing this requires nothing more than perhaps > some help with a queue from java.util.concurrent. ParallelArray, closures, > or other multi-core "in the small" language tooling isn't required at all to > implement such a thing. Perhaps a message bus so that one part can continue > to read in source files from disk and publish them as message blobs on the > bus for another thread to pick these up and run with them without the need > for any new language features. > > - Encoding/Decoding media or encryption algorithms will always remain a > highly niche job where the rocket science nature of parallelizing just isn't > a problem. > > > Am I missing something or have we been vastly overestimating the impact the > 'multi core future' will have on programming language design? > > What I think you're missing is an order of magnitude or two. 64 cores is current technology for server-class hardware, or for a single desktop GPU. Moore's law continues to successfully predict a doubling of transistors every 18 months, which (if those doubled transistors become doubled cores, as seems likely) equates to 1000-core machines being the standard within a decade. 64 is a rather small number by this reckoning. 1000 cores is substantially different from current paradigms, which are still largely biased towards 4-8 core setups and don't typically target the GPU for general purpose calculation. It's a model that's becoming outdated at an exponential rate. If anything, I'm underestimating here. That 1000 cores is for CPUs alone. More likely we'll see more, smaller cores - closer to GPU designs - due to the improved power efficiency of such a design. Assuming a total CPU+GPU count doubling every 18 months and starting from current counts, we're looking at closer to 5000 cores within a decade. For parallelism of this order, you absolutely want to do it in the small if you're to have even the remotest hope of effectively utilising all that hardware. And that means closures, parallel collections, immutability, actors, continuation passing, and a great many other higher-level concurrency primitives that Java (the language) seems increasingly unable to add effectively. -- > 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.
