- Pitz

I come from the land of beefy workstations. When I first began animating and training cel animators to use digital tools, workstations cost about the same as animators and trainers. It's a different, thankfully cheaper, world these days. I can now proudly say I am worth more than the machine I work and play on.

A lot of innovations have gotten us to this point. In some cases, the technology at the top has trickled down to more inexpensive parts, in other cases, mass-market ideas have moved the entire industry upwards.I was skeptical of Integrated, mass-market solutions, I still am. If I'm going to create my own animation on Softimage|XSI or Maya, or play the latest video game at full res with all the graphic bells and whistles turned on at a smooth frame rate -- I'm going to shell out some decent money for a high-end graphics card. No question.

But what about the other 90-odd percent of graphics-dependent applications out there? What about the games that don't require all those ray-traced, HD-everything bells and whistles to be enjoyed? And what about the photo-editors, the word processors, and even a lot of the consumer video-editors? As a consumer, does it really make sense to pay extra for something that might just be onboard for free? As a developer, does it make sense not to open your application up to the widest possible audience?

The Graphics Developers Community is officially live! Along with making available all the developer information I can find inside Intel's walls, I'll be scouring the web for interesting graphics news and info and I'll post as much of that info as I can on the site as well.

Have a read! I look forward to your comments!

All the best,

- Pitz

Tom's Hardware -- Bruce Gain -- Are Intel Integrated Graphics Good Enough for Gaming?

http://www.tomshardware.com/2005/09/15/are_intel/

Softpedia -- Alexandru Pancescu - Intel Integrated Graphics Receive a Performance Boost

http://news.softpedia.com/news/Intel-Integrated-Graphics-Receive-a-Performance-Boost-63105.shtml

Steve Pitzel, Graphics Community Manager, ISN

- Pitz

Their biggest hurdle, they say, is the fact that modern software isn't ready.  Not only applications, but operating systems as well. If we can't scale well to dual or quad processors, what's the point of even moving to 16, let alone 80. I wonder about this argument though. It seems to me that certain applications are already very well suited to massively parallel operation -- think of grid computing. Various projects (SETI@Home, Folding@Home, the just announced OpenMacGrid, and many others) allow a huge number of computers to crunch portions of datasets. Each is handed a chunk of data, then the results are fed back to the central server. This model sounds ideal for the high-core scenario.  No node is dependent on another. It's idle until work is assigned, it does its own thing, then it sends back the end result. One big thing is that this model is designed assuming high-latency. Smaller chunks of data aren't worth the round-trip. It's also not intended for any kind of realtime consumption. Some changes to these base assumptions would be required, but it seems like the multithreaded/core outlook isn't a bleak as it's made out to be.

Server rendering farms for graphics are a smaller-scale grid application. Each machine in the cluster could just as easily be one of the cores in one of these new systems. I agree that for the common application, no one knows what to do with the level of parallelism.  Large dataset analysis and multi-user server systems should see great benefit. When designed in early, most applications can benefit from parallel processing. It's true that synchronization can be a challenge at first, but it all just makes sense once you've worked with it longer. I'll be anxious to see how things progress in the next few years.

Link to Intel squeezes 1.8 TFlops out of one processor | TG Daily

Link to Intel shows off 80-core processor | ZDNet

Arian Kulp
akulp@3leaf.com

BTW - if you haven't seen Tim Mattson's avatar (Nanook Tuarog) - it's worth the price of admission - fits perfectly with his presentation.  Right now he's going over the future of many core architecture - memory sandwiched with the processors - it's amazing to see how quickly science fiction could become technological fact.

Wow.

It wasn't difficult to see his point. Walk by the nVidia or ATI booths and you were instantly immersed in the imagery, music, and fury of games. You saw animators, modelers, and texture painters at work, willowy heroines or grisly creatures springing to life before your very eyes. Those things that didn't outright explode onscreen shot arrows, swung a sword - growled at you at the very least.

In short, in other booths at GDC you saw games -- games the way we know them. The way games are meant to be. You saw graphics. You saw art. And you watched it being created.

At the Intel booth... you saw a space so sterile it looked like a clean-room starter kit. You saw demonstrations of... optimized code. There were a few desktop machines set up where people could at least play games -- or game, I should say -- it was all the same game. You know the one.

The only thing missing was elevator music.

Yes, our young animator was there -- along with one of the venerable gold standards of Character Animation, Softimage, but both were relegated to the one dim corner in that achingly white booth. And even with that poor placement -- his corner was busy.

Not so much everywhere else in the booth. The crowd at GDC is, after all, "kind of young."

Folks, code is good. I love the crazy way my Half-Life2 dune buggy careens all over the beach and dumps me half the time. I could pick up empty oil barrels with my anti-grav gun and throw 'em at bad guys for hours.

But, man, sometimes... I just want to walk around and look at the world those creators have given me. The textures, the buildings, the people...

The art.

I'm a recovering animator. Maybe that's the problem. When it comes to animation, art drives the technology. Something has to be programmed a certain way ONLY because it has to LOOK a certain way.

The art IS the game.

Sometimes I think we lose sight of that here. What do you think?

Hardware Evolution

Throughout the history of modern computing, enterprise application developers have been able to rely on new hardware to deliver significant performance improvements while actually reducing costs at the same time. Unfortunately, increasing difficulty with heat and power consumption along with the limits imposed by quantum physics has made this progression increasingly less feasible.

There is good news. Hardware vendors recognized this several years ago, and have introduced multi-core hardware architectures as a strategy for continuing to increase computing power without having to make ever smaller circuits.

Sounds Good, So What's the Dilemma?

The "dilemma" is this: a large percentage of mission-critical enterprise applications will not "automagically" run faster on multi-core servers. In fact, many will actually run slower.

There are two main reasons for this:

1. The clock speed for each "core" in the processor is slower than previous generations. This is done primarily to manage power consumption and heat dissipation. For example, a processor with a single core from a few years ago that ran at 3.0 Ghz is being replaced with a dual or quad-core processor with each core running in the neighborhood of 2.6 Ghz. More total processing power, but each one is a bit slower.

1. Most enterprise applications are not programmed to be multi-threaded. A single-threaded application cannot take advantage of the additional cores in the multi-core processor without sacrificing ordered processing. The result is idle processing time on the additional cores. Multi-threaded software should do better, but many people are finding that their multi-threaded code behaves differently in a multi-core environment than it did on a single core, so even these should be tested.

Won't my application server or operating system take care of this for me?

One of the key considerations here is the order of processing. A single threaded application that needs to ensure that A happens before B cannot run multiple instances concurrently on multiple cores and still ensure a particular order.

Application servers and operating systems are generally multi-threaded themselves, but unfortunately their multi-threaded nature does not necessarily extend to the applications that run on them. The app server and OS don't know what the proper order is for your particular business logic unless you write code to tell them. In fact, they are designed to simply process any thread as soon as possible, potentially disastrous in a business application. SMP (symmetric multiprocessing) has similar limitations.

So we are back to the same problem -- how to run multiple instances concurrently on multiple cores and still ensure a particular order.

Intel's 45nm announcement

Intel recently announced that they will have chips in the near future with 45nm features, a significant advance from the 60-65nm that is prevalent today. The company has also made it clear that this is not reducing the need for multi-core.

Around the same time as this announcement, Intel announced that they have an 80 core processor in the works. Power and heat will have to be addressed for a processor with 80 cores to come to market. So 45nm may mean some increase in clock speeds for future processors, but its primary use will be enablement of a higher number of cores.

Concurrent Computing

There is no easy solution, but there are several options, and they all involve bringing concurrency to your software. Concurrent computing (or parallel programming, as many refer to it) is likely to be a very hot topic in the coming years, so it's a good idea to start preparing now.

Since multi-core servers already make up most of the new servers shipments, concurrent computing in the enterprise will quickly become a way of life. So we need to put some thought into two things: how to make existing applications run concurrently, and how to build new systems for concurrency.

More people are talking now than any time in recent memory about how to do multi-threaded software development as the primary answer to concurrency. However, instead of writing our application code to be multi-threaded, we should consider how to abstract threading out of application code. Multi-threaded code is difficult to write and difficult to test, which is why many people have avoided it in the first place.

At Rogue Wave Software we have been working for several years in the area of "Software Pipelines". Software Pipelines* is an approach that can be used to abstract the threading model out of the application code. As software developers, you would not mix your UI code with your business logic, and for good reasons. A similar principle should apply for programming for concurrency -- the threading model should not be driven from within the application logic.

There are several important benefits to this approach. Removing threading from application code means:· The application developer doesn't have to own the threading model· Existing applications can move into a concurrent environment with much less effort· Makes it easier to scale to additional computing resources without modifying the application· If done right, the application can continually be tuned for performance without modifying application code

This approach does not allow the application developer to wash their hands entirely of concurrency. Application code needs to be written to be thread-aware, but does not need to have threads written into it. For more information on Software Pipelines, you can read this white paper (you have to log in to webservices.org to download it).

Consider how to abstract your threading model from your application logic, and you may find a smoother (concurrent) path ahead.

* Software Pipelines is a general term, not owned or trademarked by Rogue Wave or anyone as far as I'm aware. It also does not require the use of any of our technology. Software Pipelines borrows conceptually from hardware pipelines and also from fluid dynamics, which has interesting parallels to software systems.

Researchers at MIT are developing a framework that abstracts some of the details of parallel programming. They want to help mainstream developers move to parallel programming more quickly and still be efficient.

Their focus is preventing complete system failure when different applications or tasks run on separate cores. Systems fail in these scenarios because one application accesses some shared memory and when another application tries to access the same shared memory, the whole system can freeze and eventually shut down.

Currently, developers must put safeguards in place to prevent these system crashes, but at MIT, they are trying to develop a more transactional way of accessing this shared memory. They want to make sure multiple applications can access shared memory without any deadlocks and verify that when an application makes a change to the memory, the memory is still viable for the next transaction.

Major players in the industry like Microsoft, AMD, and Intel are investing a lot of money into making parallel programming easier. This seems like the right path to me. Abstraction is an integral part of Object Oriented programming. I hope a number of different APIs come from these corporations in the near future. Multi-core processors are here to stay. In fact, they will continue to grow. Intel and AMD plan on releasing the first consumer-oriented quad core processor in 2007 putting more pressure on developers to write software to take advantage of this hardware.

Microsoft supports OpenMP in C++ and C# in Visual Studio 2005. This is a good first step, but I think having another application building block release from Microsoft would propel parallel programming into the mainstream.

Making parallel programming easier is the most logical path if wide-spread adoption is the goal. Industry developers do not have a lot of time typically to spend on research and development. Even though they may take time to research alternative ways to develop software, large-scale implementation changes can be too vast and time consuming to be useful. Hopefully by increasing the amount of abstraction, changing to a parallel programming might not be such a huge leap.

Michael Cassens
mcassens@3leaf.com

Later, as a software developer at Intel, I had a similar feeling: how cool would it be if Apple used Intel microprocessors and ran the Mac OS! My developer friends and I wished and waited, but we figured it would never really happen. Then, we were caught by surprise: Paul Otellini took over as CEO at Intel and soon announced that Apple was actually going to use Intel processors.

By that time, I had been using Microsoft Windows on Intel platforms exclusively for over a decade and was quite familiar with the hassles of running Windows. I hadn't used an Apple computer in 20 years -- an Apple IIe with a 1 MHz processor, external floppy drive, and nifty green monochrome display that gave off an eerie glow.

Since the announcement of Apple's plans to use Intel processors, I have periodically tried out their computers, planning to eventually make the switch. The day has finally arrived. Last week I acquired a new Core 2 Duo-based MacBook Pro for work. After using it for a week, I feel like I could easily become an evangelist for these systems. They have a lot to offer a Windows developer. I have especially enjoyed having things just work instead of wasting time debugging problems. For example, the first time I plugged the MacBook into my Cinema Display, the new display was detected correctly and I automatically had a desktop that spanned the built-in display and the external Cinema Display. I popped in a DVD (Cream's concert at the Albert Hall). The DVD came up full screen on the Cinema Display and automatically began playing. Pleasant surprises like these have shown me how, on the Windows platform, I had become trained to expect things NOT to work.

I've also installed Parallels on the new MacBook (a virtualization product that allows one to run Windows in a virtual machine hosted on the Mac OS). This product takes advantage of the hardware virtualization support in the Core 2 Duo processor. The Parallels installation was also brain dead simple and allowed me to create a Windows Vista virtual machine by simply entering the license key, putting the Vista DVD in the drive, and clicking OK. This is how things should work.

Thanks to the horsepower of the Core 2 Duo and its VT support, I now have what I think is a near ideal situation: the elegance of the Mac user interface, the power of the underlying Mach/BSD operating system, and the ability to run Windows and Linux in virtual machines when needed. In fact, I will likely create a catalog of virtual machines, ready to run, so that I can develop and test software on different operating systems.

If you are a software developer and are not into virtualization yet, you should be. Multi-core processors combined with hardware virtualization allow you to do some amazing things (in fact, Sean Campbell and I gathered about a hundred ideas and wrote a book for Intel Press exclusively on virtualization usage models. We cover software development scenarios, software testing, marketing and sales, and more. Check out the Intel Press site for more information). While the Giants and A's series didn't turn out so well, the Intel/Apple combination was worth the wait. If you're a Windows developer considering a switch, go ahead. You won't be disappointed.

Michael Jeronimo

You may have written your application without regard for how to most effectively use multiple threads of execution. In the past, this was an acceptable strategy as the app could ride the increase in clock frequency in successive processor generations to achieve increases in performance. Those days are gone. The performance increase afforded by multi-core processors comes at a cost and so far, it is the developer's burden to bear. Multi-core processors require an explicit awareness on the part of the developer to make full use of the available processing power. The developer knows the application and the user and needs to figure out how to best partition the application to achieve performance and responsiveness. If you can adapt, your application will scale in performance as the number of processor cores continues to increase (by the way, Intel recently demonstrated a prototype of an 80-way processor that they say will be available within five years). If you don't, your application won't compare favorably to those that do.

There are many parallel programming models such as OpenMP, POSIX threads, and so on that allow a developer to incorporate multiple threads into a program, and threading tools to help analyze programs. I encourage you, if you haven't already, to take the threading bull by the horns: learn and use the available tools and APIs. Also, here at Aeshen, our developers are creating interesting sample programs that demonstrate different facets of multi-threaded programming. If you have topics you'd like covered in these samples, let us know. We'd like to learn about your technical challenges and how we can better educate developers on multi-threaded programming.

Michael Jeronimo