Joshua Marinacci's Blog

UltraSparc T2 launch: [keanu] Whoa! [/keanu]

I know this isn't really Java related, but I just got an email that Sun's UltraSparc T2 launched today. Even though I'm not a hardware guy and I've forgotten most of my CompE classes from college, I'm still interested in the changing state of the art chip design.

It simply amazes me how things have changed in the decade since I was in school. The priority has shifted from single threaded speed to slower but massively multi-threaded CPU cores. Case in point, the new T2 has 8 cores in a single chip, with 8 simultaneous threads per core; (not to mention dedicated floating point and crypto units that I have no idea how to use). That's incredible! When I was in school the idea of getting to code for a dual CPU system was considered exotic. Now I could haul out my old Java applet raytracer and render 64 lines at a time! Yes kids, my first official Java program was a very slow sphere-only raytracer applet on my 486 33mhz SX! If only I'd had Hotspot then. :)

Even more of a change, the focus in CPU design has gone from pure performance to performance per watt. I didn't realize this until recently but, thanks to changes in both the CPU and energy industries, it can cost more to power your server for a year or two than to buy the server in the first place. That really changes how people thing about building out data centers. Air conditioning is more expensive that your hardware. Perhaps we should all build our datacenters in Greenland.

So here's a more Java related question to my readers. Now that a 64 thread machine is available (and probably cheaper than you'd think), and many laptops have multiple cores now (as nowcrash becomes reality more each day). So here's my question: if you had a massively multi-threaded CPU what sort of client applications would you write? I know that most (all?) of these new T2s will go into massive app-servers or Ebay-like search engines, but I'm a client guy and I care about client stuff. What sort of really cool desktop apps could we do with massive multi-threaded CPUs?

Comments

• First off I'd get NetBeans to run at a reasonable pace. You might not want a T2 per developer, but a shared T2 would be great at coping with bursty demand.

  Posted by: tackline on August 07, 2007 at 10:57 AM

• Think gaming

  Posted by: davidvc on August 07, 2007 at 11:57 AM

• davidvc quite true. any examples? like giving a thread to every object in a world?

  Posted by: joshy on August 07, 2007 at 01:04 PM

• Since I live in IDEs and web browsers, changing those to take advantage of the extra threads would directly benefit me the most. With that said, the JRE itself uses several threads. I bet there are many ways that the interaction of those threads could be changed to better take advantage of lots of cores.

  Posted by: coxcu on August 08, 2007 at 07:04 AM

• Besides the usual background stuff, like printing, repaginating, preloading/calculating things you know you'll need soon etc., exploring multicore in the client is very hard because most work is single-thread by nature, driven by a single-threaded human user.

  There are a few clients that explore threads somewhat because they manage a very complex set of automatic jobs; for example look at the Eclipse IDE - bring up its Progress window, go to its Preferences and tick "Show sleeping and system operations" (option available in 3.2+). Now perform some simple task, like saving an update Java file - preferably in a complex workspace with lots of inter-dependent JavaEE projects - and you'll see a huge mess of jobs executing: automatic recompilation, resource cache cleanup, validation, GUI decoration, update of version control info, period workspace save, additional "builders" for plugins like Checkstyle (if you have them), auto redeploy and other fancy things. Many of these tasks are enqueued due to dependencies, but in a dual-core machine I can see total CPU utilization peak way above 50%, which means there's at least a good deal parallelism. In fact I'm forced to use RAD7 - which is even bigger, and runs extra stupid things that I don't know how to disable like a 'migration builder' that is useless because I don't need any compatibility with older RADs... but I digress. The point is that if your GUI app is big like a mainframe OS and needs its own job management framework (I wouldn't be surprise if there is a JCL interpreter inside RAD7!), you can explore multiple cores. But of course, there's only a very few GUI apps as big as that.

  For GUIs, I think the most promising avenue is lightweight parallelization, e.g. transorming each 'for' loop (where each iteration is independent of the others) into multithreaded execution. This requires runtime and library support, and perhaps OS and language support. Thread management must be very lightweight, otherwise only a few loops (or other operations) can be parallelized. Java SE 7 will have a fork-join framework that implements this atop the existing java.util.concurrent features, like executors and ultra-efficient synchronizers. But you'll have to change your code - if we're lucky with closures, but if the closure naysayers win, code will be a mess (imagine every parallelizable loop polluted with inner classes...), but at least your stuff will run faster on multicore systems. There are other attempts too, Intel is pushing new C/C++ compiler and libraries for automatic vectorization, so HotSpot could eventually do the same automatically, without any user code changes. (But I wouldn't bet that "eventually" means "this decade": this is hard stuff even for static compilers.) The underlying JavaSE libraries, native runtime, and of course the OS, will be increasingly smarter, so we'll keep calling the same heavy-weight APIs to draw text, read files and such, and these calls will induce some multicore activity. For example, multithreaded rendering engines are a recent important trend. Fancy vectorial toolkits like Quartz and WPF (and perhaps Java counterparts - SVG, JavaFX, etc) can benefit immensely from multiple cores. Higher-level languages, like Groovy and JavaFX, need even more runtime effort for additional optimization, so this adds to the already big pile of runtime work (JIT, GC, etc) that can mostly run in "other" cores. If a common desktop PC, ten years in the future, is a 64-thread monster like Niagara2, users will perceive a JavaFX app to be as fast as a "native" pure-Java app, even if the system needs to dedicate two or three cores full-time to profile, analyze and optimize code... perhaps employ more advanced techniques like transactional memory (which allows to parallelize like mad, lock-free, even abuse of speculative execution)... who cares, if the machine will still have dozens of unused threads? [/sci-fi mode]

  Posted by: opinali on August 09, 2007 at 08:51 AM

• I think we need to think outside the box a bit more. I realize that we like to just extrapolate what we are familiar with (a massively parallel IDE, for example), but I think we need to reach a bit higher. What's something that would be difficult or impossible to do in a single core processor? Something crazy. How about realtime raytracing? Or live video stream processing on multiple streams. Or a molecule simulation where you can directly interact with the molecules and it recalculates everything. Let's think big!

  
  opinali You've got some good ideas in here. I believe that the hotspot team is working on more support for parallelization and vectorization. The comment on FX seems wrong, though. You said "If a common desktop PC, ten years in the future, is a 64-thread monster like Niagara2, users will perceive a JavaFX app to be as fast as a "native" pure-Java app". Soon there will be a JavaFX Script compiler that will turn the script straight into bytecode, thus an FX app *will be* a native Java app. :)

  Posted by: joshy on August 09, 2007 at 10:12 AM

• I would want to run Folding@Home 24/7, so that this project can benefit the most.
  

  Posted by: materthron on August 10, 2007 at 10:57 AM

This work is licensed under a Creative Commons License.