We have not yet posted any Windows builds, although there are links for them on the download page.

The ACML team is working diligently to produce final builds for Windows 64-bit and 32-bit.  We want to make sure that they are right and resolve a few issues that developers have commented on.   The 64-bit builds are passing all of our testing, and now we are working on the final packaging.  We hope to post them by the end of this week. 
————————-
This response is provided for informational purposes only, is provided “AS IS” and does not obligate AMD to provide any of the services, technology, or programs described.

The main point Randy makes is that you should use CPUID to identify what features you need in the processor to support your optimized code path, example: vectorized code such as SSE, rather than basing your code path on what processor you have.

A typical example of what not to do is to use CPUID to get the vendor ID string, and then base your optimized code path on that.  There are a few problems with this approach:

1. It is possible that not all of the vendor’s legacy processors support the optimized code you are writing, and thus might break compatibility on older processors
2. It is possible that you will be leaving out another vendor’s processors even though those processors actually support the features needed to take advantage of the optimized code path

Another thing to be careful of is using CPUID for parallel programming.  In this video, Randy demonstrates how to find the processor core count, however if you are looking for actual topology information (i.e. cache hierarchy), then you’ll be better off using the operating system methods.  For example, in Windows you can use the API call GetLogicalProcessorInformation to find NUMA and multi-core information.  Check out our older “Barcelona” blog for more information on that.

Hopefully this is not news to those seasoned software optimization gurus, but questions arise from time to time on the forums, so this is for the rest of us.  I hope this helps you to understand more about how to make sure your optimized code paths are being used whenever possible.

Do you use CPUID?  If so how?  Was this video and blog helpful to you?

-Sharon Troia, Sr. Developer Relations Engineer

Related Links:

• View ADIT Episode 6: Using CPUID
• CPUID Specification
• CPUID Intrinsic (MSDN)

————————-

The information presented in this document is for informational purposes only and may contain technical inaccuracies, omissions and typographical errors. Links to third party sites are for convenience only, and no endorsement is implied.

This video features Mike Vermeulen – manager of the AMD Open64 development team talking about the origins of Open64.  It has come a long way since we launched the beta compiler suite in the summer of 2009, see Roy’s blog, but it existed long before we started working with it as Mike reveals.

Roy Ju, Architect on the Open64 team, speaks about one of the unique features recently added called multi-core scalability optimizations (-mso).  He explains how it works, and why it might not be in most compilers.  Then he talks about the Open64 community in general and how you might be able to participate if you are interested.

Michael Lai, software engineer on the Open64 team, steps through several optimization flags, such as O2 and O3 optimizations and what is included with each.  He also talks about interprocedural analysis, or IPA, and how it can be used to help get better cache utilization.

If you are into high performance parallel workloads you won’t want to miss this episode of the AMD Developer Inside Track on Open64. 

-Sharon Troia, Sr. Developer Relations Engineer

Related links:

• AMD x86 Open64 Compiler Suite Downloads
• X86 Open64 User’s Guide
• Open64 Quick Reference Guide to Optimization Flags
• X86 Open64 Installation Prerequisites and Guidelines

The information presented in this blogis for informational purposes only and may contain technical inaccuracies, omissions and typographical errors, and may not represent AMD

The Booth

 We scaled back on our sponsorship this year to two small exhibitor booths side by side, expecting a smaller than average PDC.  It turned out that there were 1,000 more people than last year to make 6,000 total!  It’s a good thing we didn’t scale back the demos.  Our booth was packed to capacity with a laptop, a fully loaded desktop, a fully loaded server, and even a sneak peak at an engineering reference design of a server/workstation system featuring a 12-core processor, code-named “Magny-Cours”.

The Demos

Desktop: 3.2 GHz AMD Phenom^TM II X4 with an ATI Radeon 5870 with Eyefinity and DX®11

This demo was driving 3 displays which appear to Windows® 7 as a single desktop (AMD’s ATI  EyeFinity Technology).  We demonstrated DX 11 and hardware features such as hardware tessellation, ambient occlusion, and DirectCompute using software from the DX11 SDK as well as upcoming software titles (Dirt 2, Aliens vs. Predator), and the Unigine “Heaven” DX11 benchmark.  Check out the Vision Launch Recap video for footage of these demos and interviews with the game developers using DX11.

Check out these PDC sessions and Keynotes that were powered by the ATI Radeon 5870

• Day #2 Keynote (~ highlighted started at minute29)
• Modern 3D Graphics Using Windows 7 and Direct3D 11 Hardware
• DirectX11 Direct Compute

Server: HP DL785 G6, packed with 48 cores and 128 GB of memory

HP’s DL785 G6 is an 8 socket server platform that has a total of 48 cores, using AMD’s six core “Istanbul” processor.  At PDC we were using an image processing application that was built using the Parallel Patterns Library and the Concurrency Runtime (ConcRT).  ConcRT and PPL will ship in Visual Studio® 2010.  The application manipulates a number of 60 Megapixel images by converting them from RAW (Bayer) format into RGB, and applies a number of corrections such as gamma, luminance, and anti-aliasing to arrive at the final image.  Using ConcRT, developers were able to rapidly incorporate task-based programming into their application, which helps them to scale and fully utilize all the CPU cores, regardless if there were four cores in the system or 48.

Check out these PDC sessions that talk about many core and refer to or used the AMD system:

• C++ Forever: Interactive Applications in the age of Manycore (The demo in this session was running on our system in our booth)
• Lighting up Windows Server 2008 R2 Using ConcRT on UMS (48-core was used)

Server/Workstation: 12-core processor code named “Magny-Cours”

We were able to show a sneak-peek of our upcoming “Magny-Cours” 12-core processor that will be available in Q1 of next year.  This system was running a parallel version of a Raytracing application built in C#, using the Task Parallel Library (TPL) in .NET 4.0, and illustrated the benefits of parallel managed code development both from a developer productivity and scaling perspective.

 http://developer.amd.com/blog_assets/PDCServersSmall.jpg

Laptop: AMD Turion^TM 2 Ultra running AMD CodeAnalyst Performance Analyzer

Our latest “Tigris” platform increases performance as well as battery life and was shown running our CodeAnalyst Performance tool, a free download to AMD Dev Central members is available at http://developer.amd.com/codeanalyst.  CodeAnalyst is a great tool for drilling down into performance problems in your code, whether it is native C/C++ or managed.  On AMD processors, in addition to being a time based sampling profiler, it can also be used to sample processor events (such as L2 cache misses) to help you optimize your application on the underlying hardware.

The Summary

Visual Studio® 2010 along with Microsoft’s ConcRT, parallel patterns libraries and task parallel libraries can really help get better scaling out of many core systems and you can use AMD CodeAnalyst within the Visual Studio IDE to help pin point hotspots in your code.  The latest ATI Radeon graphics can, not only get you 3 (or more) monitors use, but also take advantage of the latest DirectX APIs and the features like DirectCompute that go along with that.   The future will bring even more cores on a single die so these parallel programming tools are growing even more important.   

Happy Holidays Everyone!!

AMD Developer Outreach

PS.  Congrats to the 3 winners of the daily drawing for the ATI Radeon HD 5870!  Thanks to everyone who took the time to fill out the survey card and scan your badge!! 

The information presented in this blog is for informational purposes only and may contain technical inaccuracies, omissions and typographical errors, and may not represent AMD

Later in the day I attended an OpenMP Birds-of-a-Feather. They discussed the roadmap for OpenMP versions. The 3.1 version is imminent. Among the features discussed was better CPU affinity. This got my attention. One of the keys to repeatably good performance for large multithreaded ACML tasks is ensuring good task CPU affinity. ACML uses OpenMP to provide parallel operation for many of the BLAS, LAPACK, and FFT routines. When ACML is called with a large enough problem, it will run in a OpenMP parallel section to divide the problem among available CPU cores. Thread affinity is needed to keep threads running always on the same core to maximize cache reuse and minimize remote memory accesses. The numactl API and command are not sufficient. Numactl will restrict a group of threads to a set of processors, but does not prevent migration of tasks between the specified nodes and cores.

Fortunately, all of the OpenMP capable compilers used by ACML have implementation specific ways to lock tasks to cores. The downside is that each compiler has a different set of environment variables to control this. It sounds like OpenMP 3.1 will standardize this. It may be a while before the compilers catch up and implement this new feature, so in the meantime, check the documentation for each compiler to determine the best way to enforce affinity.

The AMD booth was conveniently located near PGI, Cray, and Oak Ridge.

The information presented in this blogis for informational purposes only and may contain technical inaccuracies, omissions and typographical errors, and may not represent AMD

For the first time at an super computing show, I have no booth demo so aside from the usual meetings, I’m free to actually attend technical sessions. There are way too many sessions for one person to attend, difficult decisions must be made. My priorities are learning more about how real applications are using sparse solvers and what kind of performance is being reported, finding FFT applications that we can use for benchmarking and rounding out our feature set, exploring how MATLAB users are calling ACML, and looking at how GPUs are being adopted in the HPC market.

The opening keynote by Justin Rattner was kind of interesting. His talk was about 3D internet and ways to catalyze exponential growth for high performance computing. He talked abou OpenSim and one of his demos was a realtime talk with a University of Utah researcher who was represented locally by a sim’d avatar inhabiting a world populated by sim’d ferns which were the subject of his research, all rendered in realtime. The fern simulations were interacting with many aspects of the environment, which was also simulated. It’s easy to see how you could create complex simulation worlds that require huge amounts of computing power. Oh, and there’s a bunch of software needed also.

One of the technical sessions looked like just what I was looking for on sparse solvers. The big take away for me is that the primary task most people are using as a metric is as simple as solving Ax=b, where A is large and sparse. There are many ways to solve the problem, and the techniques used are very much dependent on the nature of the sparse system. The example problems used in the presentations are drawn from a variety of problem areas, and have matrix sizes on the order of 1 million squared, with about a hundred million non-zero elements.

The set of data found at the Matrix Market (http://math.nist.gov/MatrixMarket/) features much smaller matrices, so some searching will be necessary to find appropriate large problem examples suitable for todays faster computers.

It’s a bit humbling that I’m stumbling into an area of computing that’s been well known for the last 20 years. Many of the people who have worked on sparse solver applications over the years are here at the show.

The information presented in this blogis for informational purposes only and may contain technical inaccuracies, omissions and typographical errors, and may not represent AMD

AMD’s Operating System Research Center plays a central role in the EU-funded VELOX project, which targets an integrated approach to transactional memory (TM) on multi and many-core computers. I will shed some light on this role in the next section after a short introduction into transactional memory.

Transactional memory

The transactional-memory programming paradigm is one promising approach for better and easier leveraging the trend to more parallelism in hardware. In the future, in order to benefit from hardware developments, software will have to utilize the increase in hardware parallelism. Simply relying on increases in single-thread performance will not bring large improvements anymore.

There exists a range of approaches to leverage this hardware parallelism, all of which have different restrictions:

• For example, traditional lock-based approaches either do not scale well to a large number of cores, if coarse-grained locking is used, or
• They are hard to get right and are complex if fine-grained locking is used.
• Lock-free approaches may provide good performance for specific cases but are also very tricky to implement correctly.

Transactional memory may come as a solution here because the programming model is easier to grasp: Atomic blocks are marked in the source code and are mapped to transactional-memory primitives by a compiler. For lock-based approaches, single, distinct locks have to be designated for specific resources to obtain parallism. Although with TM only a single primitive is used for marking atomic blocks, it may still provide good scalability as only dynamic conflicts have to be handled. For example, if two threads use a single lock for protecting an atomic block of code, only one threads can ever enter this block at once, independently of what is done inside the block. If this block of code is used for transferring funds from one account to another, no such transfers can run in parallel. With fine-grained locking, a lock for each account could be used required, which is more complex to use and may actually lead to a deadlock. With TM, any number of threads can enter this block and a conflict occurs only if the same memory regions are touched. For the account example, this means that conflicts only occur if two threads try to modify the same accounts at the same time, otherwise, everything can run in parallel.

The following example demonstrates the simple syntax for protection a block of code with a transaction:

__tm_atomic {
res = transfer_funds(src_account, dest_account);
account_update_stat++;
}

Compare this to the complexity of a fine-grained locking example:

lock(src_account.lock);
lock(dest_account.lock);
lock(stats_lock);
res = transfer_funds(src_account, dest_account);
account_update_stat++;
unlock(src_account.lock);
unlock(dest_account.lock);
unlock(stats_lock);

Software transactional memory (STM), up to now is not ready for widespread deployment. Its overhead simply is too high for many applications due to the additional bookkeeping involved. We saw an order-of-magnitude slowdown for single microbenchmarks in our measurements compared to a lock-free implementation. Even with perfect scalability around ten cores would be required to match the performance of traditional approaches on a single core.

Although a hardware-transactional-memory solution would be very desirable as the costly bookkeeping could be relocated to dedicated silicon, hardware-transactional memory is not available for current industry architectures. Full-blown support is very complex to realize as it would have to interact with many processor parts and would be very resource hungry to implement.

Therefore, special hardware support for speeding up critical paths in STM proposals and support for hybrid software-hardware solutions, as targeted with ASF, is a key motivation for AMD to participate in VELOX.

Our Role in VELOX

In VELOX we fulfill two roles: First, we provide partners with support for verifying implementation proposals regarding their feasibilty from an industry point-of-view. Second, we verify our own hardware-transactional-memory proposal – AMD’s ASF.

We recently released version 2.1 of the ASF Specification. Feel free to comment on it, we are interested in your feedback!

In the previous entry of our blog series on ASF, Stephan described how we use PTLsim for prototyping and evaluating ASF. To this end, we also extend PTLsim’s memory module to better correspond to contemporary AMD multicore systems.

PTLsim’s Memory Module

Up to now, PTLsim’s memory model is restricted to a single, inclusive cache hierarchy. This limits the simulation accuracy for current AMD multicore systems, which connect single processors with HyperTransport links.

To overcome this limitation we are working on extending PTLsim’s memory model.

• We therefore first establish an interface between the core model and the memory hierarchy and refactor PTLsim to solely access memory through this interface.
  Up to now, PTLsim’s access to memory locations is somewhat scattered throughout the code and the cache classes are tightly integrated with the rest of the code.
  For the interface design itself, we were inspired by the requests in M5’s memory model and by the Ruby memory module in GEMS.
• If this process is completed, other, more versatile memory modules can be used together with PTLsim’s core, such as the module that is currently being developed at VELOX partner Chalmers University of Technology. Alternatively, the refactored memory module in PTLsim can be developed further and can be extended to more accurately model a HyperTransport-connected NUMA system.

Starting point for the memory module structure in original PTLsim. The parts of the cache hierarchy (that will comprise the memory module) are tightly integrated with the rest of PTLsim.

Architecture after introducing the memory-module interface and using it to fully encapsulate accesses to the memory module (the cache hierarchy).

Now the memory module can be replaced with another one, implementing the same interface

Outlook

I am currently in the process of updating the established interface inside PTLsim to the new packet-oriented version. Once this is done, we plan to release this version to Velox partners and will help integrate the first external memory module with PTLsim. Further on, PTLsim will be part of an integrated Velox demonstrator. Already our current collaboration with Velox partners is giving us valuable feedback regarding the ASF specification and the implementation in PTLsim. By further working on the memory module, we will be able to do better, more in-depth evaluations of ASF and will be able to estimate how ASF could be best used in tomorrow’s software.

About me

I joined AMD’s OSRC group in Dresden in October 2008 to work on ASF and, in the context of VELOX, to extend PTLsim.

Before that, I was a PhD student at Technische Universität Dresden, with interests in runtime monitoring for real-time systems, microkernel-based systems, and other operating system topics, such as disk scheduling and file systems.

Martin Pohlack, Senior Software Engineer
AMD Operating System Research Center, Dresden

The information presented in this blogis for informational purposes only and may contain technical inaccuracies, omissions and typographical errors, and may not represent AMD

Ben, what have we created with OpenCL and what does it do?

Ben: Sure, with OpenCL we created a C-based interface for programming a range of parallel processors. Developers write OpenCL Kernels, sub-routines which developers seek to accelerate or offload, and embed these in their applications. OpenCL includes a runtime component which allows these OpenCL Kernels to be compiled at runtime for either a CPU or GPU. AMD has contributed to the development of the OpenCL specification and written the implementation x86 processors and GPU’s – a runtime environment which compiles the code near runtime, then schedules and executes the code at runtime.

What are the benefits of being able to compile an application for a CPU or a GPU?

Ben: Developers can write one piece of code and easily support a variety of compute devices in the platform – CPUs and GPUs, from multiple vendors. Code can be load-balanced between CPU and GPU depending on the capabilities in the final platform. For example, we expect that some applications or parts of applications will run faster on the CPU than the GPU, other applications perform better on the GPU. Finally, the OpenCL CPU implementation levertages the CPU hardware debug features to provide excellent debug capabilities, using familiar debug environments, at a full CPU speeds.

When exactly during runtime is the Kernel compiled?

Ben: There are specific commands within the body of your application which you call to compile the Kernel, and direct it to be compiled for the CPU or GPU. At that point, the Kernel code is translated into a binary. The binary later executes natively when the Kernel is called. The code is not interpreted in the hot spot of the loop, it’s not like Java in that regard.

So the code within a Kernel looks like C but can be compiled to execute on the GPU?

Ben: Exactly. Because a GPU looks and functions differently than a CPU, however, you have to think differently when you write the Kernel for GPU, because at that point, you are executing your code directly on the GPU. There are constraints imposed on Kernel code to accommodate the specialized functionality of the GPU. Kernels are based on C99 with extensions provided by OpenCL-C for vectors and address spaces.

Give me some examples of the special ways in which the C code within a Kernel is different from the standard code in the body of the application?

Ben: To understand writing a Kernel it is important to understand that the code is actually executing on a GPU, despite the fact that the functions you are performing are syntactically the same as other C code. A GPU has a small fast cache (local memory) and larger main GPU memory (global memory). You move data in blocks, and complete as much of the task on that block as possible before moving the block out and moving the next block in. With a GPU we have a lot of compute bandwidth relative to memory bandwidth making it advantageous to do as much as you can to data within the cache. With OpenCL the blocking process does not necessarily get easier, but you can control it from C code.

How do we move data from main memory to the GPU memory for use by a Kernel function?

Ben: A Kernel cannot move memory from main memory, that is done in your application code. So there are standard functions to copy memory into GPU memory from the application, and pointers to this memory can then be passed to a Kernel function. The Kernel function can then copy memory into the fast cache or “local” memory.

This sounds a bit complicated, but I have to remind myself, this is all standard C code, and we are discussing the optimization that makes something run fast on the GPU, and the memory management tools that are available, now within standard C through the OpenCL library, to do that.

Ben: That’s Right. The magic is that a Kernel is C code which is amazingly compiled by the runtime component of OpenCL to run on a GPU or CPU with some extra tools to ensure it can take full advantage of the extremely high compute to memory bandwidth capability of the fast, parallel math engine of the GPU.

So as time goes on, we anticipate that people will write and optimize many useful Kernels which will simplify the development of complex applications?

Ben: Yes. It is relatively straight-forward to port applications written for other GPGPU languages like Brook+ and CUDA to OpenCL. This is a huge step forward from proprietary GPU code, you now have a standard way to get at GPU code and memory from C in a platform independent way.

With ATI Stream technology and the standardization of the programming model with OpenCL for GPU almost any aspiring GPGPU developer can download the tools necessary to get started and develop platform-independent software fueled by the power of the evolved GPU. I have collected resources below to get you started, enjoy blazing the trail of a new frontier in computing!

For more information, watch as AMD’s Mike Houston discusses OpenCL and what the future has in store for software applications that use it.

If you are ready to get started with OpenCL, you can begin with AMD’s OpenCL resource page here.  

Simon has regular posts on the AMD At Home blog and you can check out The Digital Nexus series here.

The information presented in this blogis for informational purposes only and may contain technical inaccuracies, omissions and typographical errors, and may not represent AMD

In this month’s episode of the AMD Developer Inside Track I interview Mike Houston, GPG System Architect.  He talks about what OpenCL is, what the transition to this new language will be like and he gets into what applications could benefit from OpenCL, as well as what the future has in store for software applications that use it.   

One of the advantages of OpenCL is its advanced queuing system which is great for game development. It is also designed to work very well with various graphics APIs such as OpenGL, DirectX 9 and DirectX 10. 

Game developers aren’t the only ones who can take advantage of OpenCL though.  According to Michael, it is going to be very useful for applications such as media encoding, virus scanning, and physics to name a few.  It makes a lot of sense for AMD to move to a ubiquitous computing language that runs on platforms everywhere.  The next few years will be an interesting time for GPGPU technology as several hardware and software vendors get on board. 

ATI Stream technology is gaining significant momentum.  Some cool and unexpected examples of ATI Stream technology in action are:

• Folding@home: http://folding.stanford.edu/
• Milkyway@home: http://milkyway.cs.rpi.edu/milkyway/

An example of gaming technology and OpenCL:

• Havoc demo: http://www.engadget.com/2009/03/27/havok-and-amd-show-off-opencl-with-pretty-pretty-dresses/

Watch the AMD Developer Inside Track, Episode 2 for the full story.

 -Sharon Troia, AMD Developer Outreach

The information presented in this blogis for informational purposes only and may contain technical inaccuracies, omissions and typographical errors, and may not represent AMD

Developing libraries can be difficult, fun and interesting; an equally difficult task is testing the library and distributing it, so that other developers can use the library in their projects.  The big advantage of using libraries to accomplish certain functionalities is that libraries are already tested and optimized for various platforms.  For the libraries optimized for particular platforms, there needs to be a dispatch mechanism to select the best optimized path depending on the processor.  I have found that the build system from the Framewave library provides a good solution to accomplish this.

 Derived from the AMD Performance Library, Framewave is a free of charge, open-source collection of popular image and signal processing routines designed to accelerate application development, debugging, multi-threading and optimization on x86-class processor platforms. This library has three paths of optimized code:  a reference code (c code) path, an SSE2 code path, and an SSE3 and F10H code path. One reason I found it interesting is because it is open-source; I can go through the code, understand it, and modify it as per my requirements, plus it has a single source bundle for four operating systems (Linux®, Mac, Windows®, and Solaris operating systems).

 Framewave has a different implementation for each of the paths, and the Framewave build system takes care of combining them together and exposing a single signature. To achieve this, Framewave has a custom build system based on the SCons build tool (http://www.scons.org). The advantage of using SCons is that it uses the Python scripting language for its configuration files.

 Framewave has a single source bundle that is termed platform independent and is compiled using a single build system across all the platforms. The tool sets supported are GCC, MSVC, and Sun CC. This build system allows me to build 32/64-bit shared/static libraries with the ability to build either a debug or release version.

 This build system picks up the file and compiles it n times, n being the number of optimized paths, producing n object files. These n object files are linked together to the stub function which is exported as the actual function. To understand the build system more, refer to the architecture description here: http://framewave.sourceforge.net/DesignDoc/FramewaveBuildSystem-Architecture.htm

 Producing one DLL file and having only one signature exported for each function is a better option than having multiple DLL files for each of the optimized code paths and then loading the particular DLL depending on the processor. The advantage of having one single large DLL file for the library is that I end up adding only one file to the n files present in my in project.

 Overall this build system offers a unique way to bundle software that has different implementations for each processor.

 I’d like to hear what you think.  Is this build system useful in your own work?  What do you like about it, what do you dislike about it?

 Watch out for my next post on Using SCons for building the build system.

The information presented in this blogis for informational purposes only and may contain technical inaccuracies, omissions and typographical errors, and may not represent AMD