Check out the AMD Developer Inside Track video for a snapshot of three of our partners from this panel and myself answering the question of how to start taking advantage of multi-core processors.

After these events I often get asked the same how-to-get-started question, but with more detail. Someone will say, "Okay, but let me tell you about this..." - so we talk it over. The questions I ask usually include at least some of the following:

• Who do you work for?
• What field are you in?
• What are you trying to do?
• Where is your code spending the most time now?
• What are your primary bottlenecks (CPU, I/O, Memory)?
• Do you need to scale up, or scale out?
• Are you trying to reduce response time?
• Are you trying to increase throughput?
• Where and how big is your data?
• What are your data dependencies?
• Are you using a managed runtime environment?
• What tools are you using?
• Are you open to using other tools?
• Will you be able to rewrite code?
• Who have you talked to in researching your problem?
• Do you have an n-tier infrastructure?
• What hardware are you using right now?
• What are your hardware upgrade plans?

These questions help decompose the problem and also provide a high-level view.  I find these discussions often touch on a mix of abstract principles combined with some specific practical advice. Below, I have some basic getting-started suggestions which I've mapped to the above questions, along with my perspectives on how they bear on the problem. For simplicity's sake, I've decided to map a question once to a single suggestion, though it may really have multiple applications.

 In conclusion, I want to emphasize that after carefully stating your problem and doing some initial analysis, that you try new implementations with caution.  Measure with appropriate precision, and make sure your measurements are repeatable.  Only then can you be sure that your work is worthwhile. Finally, take a look at the AMD Developer Central for parallelization articles, our CPU analysis tool CodeAnalyst, and our performance libraries. 

Be sure to check out the first AMD Developer Inside Track video featuring three of AMD's software tools partners giving their perspectives on taking advantage of multi-cores.

-Tracy Carver, Software Developer and Evangelist, AMD

The first installment of the AMD Developer Inside Track is available now.  This one features a panel of our software developer tools partners from Allinea, Pervasive and Rogue Wave talking about taking advantage of multi-core processing.  I was able to pull them aside after the CommunityOne West 2009 Multicore Panel sponsored by AMD.  Check out the video, Tracy Carver's blog, and the slides that were presented. 

Next month we will be talking with Michael Houston about OpenCL.  And we have a multitude of topics planned for the rest of the year.  If you have a topic in mind, let us know by making a comment on this blog post, or on our forums. 

-Sharon Troia, Sr. Developer Relations Engineer

ps.  If you are experience any viewing problems, please let me know.  We will be adding some different formats, lower resolution versions to  download, as well as the transcripts over the next two weeks.

• Power Management: AMD worked closely with Microsoft to support a new AMD product-specific power management driver in Windows 7. This in-box driver supports older processors as well as the latest generation AMD Opteron^TM processor and AMD Phenom^TM II processor. In addition to the power management driver, AMD collaborated with Microsoft to fine tune default power policy parameters that control power state transitions to help optimize for power and performance. And since this driver is "in-box", there's no need to download.
• Virtualization: AMD provided code to Microsoft and worked with the Hypervisor teams to help ensure that Hyper-V R2 and Windows Virtual PC in Windows 7 utilize Rapid Virtualization Indexing (aka nested paging tables) for improved performance of VM guests. All of the third-generation AMD Opteron processors, AMD Phenom processors, and AMD Phenom II processors support Rapid Virtualization Indexing. In addition, most of AMD's shipping processors (other than AMD Sempron^TM processors) include AMD-V^TM technology and thus support Windows XP Mode for Windows 7.
• Stability & Performance: Current and upcoming reference platforms containing multi-core processors from AMD were loaned to Microsoft's labs to vet out potential incompatibilities with Windows 7 and Windows Server 2008 R2.
• Graphics: AMD has been working hard to support DirectX® 11, so there are plans to make native DirectX 11 hardware from AMD in its ATI Radeon^TM GPUs available when Windows 7 is released.
• GPU Compute: DirectX 11 Compute Shader (CS) is a new API in Windows 7 that helps enable rich applications through the use of compute on the GPU (General Purpose GPU or GPGPU). Rich experiences such as drag-and-drop media transcoding, physics, and AI are a few areas that DirectX 11 CS can help enable.

For more information on AMD and Microsoft technical collaboration visit the Windows Zone on developer.amd.com.  For more information on what AMD is doing overall with Microsoft for end users, check out the Microsoft & AMD corporate site, or see the AMD video on Microsoft's Ready. Set. 7 site.

-Robin Maffeo, Microsoft Alliance Manager

Performance Profiling Without the Overhead

Here at AMD, we know that in order to improve program performance, you have to be able to measure it. AMD's Lightweight Profiling feature (LWP) is designed to make performance measurement even easier and with negligible overhead. In this post, I'll give you an overview of LWP and tell you why we think it's an exciting next step in the area of performance tuning.

First, a little history. Late in 2007, AMD announced Lightweight Profiling as a proposed extension to the AMD64 architecture that would allow an application to gather performance statistics about itself with low overhead. We posted the preliminary specification and asked for feedback from the developer community. Much to our delight, many of you responded with comments, criticisms, and suggestions on the proposal. We've read all of your feedback, and last week we posted the current version of the LWP specification. The announcement and the link to the spec are here. Thanks to all of you who helped us out.

What came before...

It's important to be able to measure the details of a program's performance in order to find ways to speed it up. Until now, there have been just two ways to do this. The first is via instrumentation, i.e., adding code to the program to watch the clock, or the cycle counter, or just to count the number of times an instruction or loop is executed. Instrumentation can be added by the programmer or by a compiler. Unfortunately, it seriously perturbs the application, and the instrumented code usually doesn't have the same characteristics as the original code, especially when dealing with the data and instruction caches. Also, instrumentation can't observe the hardware caches, so it can't gather data about cache behavior.

The second traditional method of monitoring performance is to use the hardware performance counters. These count hardware events and generate an interrupt after a programmed number of events have happened. The counters can report on events that are too hard to instrument (like counting each x86 instruction) or are not visible to software (like cache misses). These counters are used by the AMD CodeAnalyst Performance Analyzer and provide deep insight into application and system performance. However, each time a data sample is gathered, the processor must take an interrupt to a kernel-mode driver, and that takes hundreds or thousands of cycles. The driver, by simply executing, changes the contents of the data cache and the instruction cache and may perturb the application's performance. The counters can only be configured, started, and stopped from kernel mode, so an application must call a driver or the operating system to control them. Finally, some systems do not context-switch the performance counters when changing threads or processes, and on those systems, performance monitoring can only be done globally by a single user at a time.

Introducing LWP

After reading about current technology, you might think that an ideal performance monitor should:

• Operate entirely in user mode
• Cause little or no perturbation of the application
• Be controlled separately for each thread
• Have low overhead to allow for higher sampling rates

And that describes LWP!

Lightweight Profiling adds a set of user-controlled counters to the AMD64 architecture. They can monitor multiple events simultaneously. An application thread starts profiling by providing the address of an LWP control block (LWPCB) as the operand to the new LLWPCB instruction. The contents of the LWPCB specify which events to count and how often to count them. It also points to a ring buffer in the application's memory into which the hardware will store event records. That's it.

Once started, LWP counts the specified events. When an event counter underflows, it stores an event record at the head of the ring buffer and resets the counter. (If requested, LWP randomizes the bottom bits of the new counter value to prevent "beating" against constant length loops.) LWP stores the record without interrupting the flow of the program, so the only perturbation to the program's performance is writing the record (usually affecting only a single data cache line) and a few cycles to perform the write. The record contains the event type, the address of the instruction that caused the underflow, and other information about the event. All event types share one ring buffer and can be sorted out by the event type field in the record.

Of course, eventually the buffer will fill up. What then? Well, a program has two options for emptying the ring buffer. First, it can simply poll the buffer and remove event records from the tail of the ring. When software rewrites the tail pointer, the LWP hardware knows it can reuse the newly emptied region of the ring buffer. Since the buffer is in user memory, the program can even share the memory with another process, and that second process can be responsible for draining the buffer. Second, the application can specify that it wants LWP to generate an interrupt when the ring buffer is filled past a certain threshold. For instance, it can configure a buffer to hold 10,000 event records and tell LWP to interrupt whenever there are more than 9,000 records in the buffer. The interrupt does indeed perturb the program, but it does so 1/9000th as often as the traditional performance counters would. Better still, since the buffer is in user memory, the application can catch the interrupt and do whatever it wants with the data. It can store it to disk for later analysis, or it can process it immediately and even try to fix performance problems as they are happening.

In addition, LWP is a per-thread feature. Each thread on the system can be monitoring different events at different rates without interference. If a thread is not using LWP, there is no impact on its performance even if other threads have LWP active.

Some LWP Details

The LWP events are a small subset of the events available in the traditional performance counters. They include Instructions Retired, Branches Retired, and DCache Misses. The Branches Retired event can be filtered by whether the branch is direct or indirect, conditional or unconditional, or other criteria. It captures the target address of the branch, a useful value when looking at indirect branches. The DCache miss event can be filtered by cache level to capture only "expensive" cache misses.

One exciting feature of LWP is the ability to insert events into the ring buffer under program control. There are two new instructions to do this:

• LWPINS inserts a record into the ring buffer containing data taken from the arguments to the instruction. A program can use LWPINS to insert a marker to indicate an important event, such as loading or unloading a shared library, that influences the way addresses should be interpreted in subsequent event records.
• LWPVAL uses an event counter and decrements the counter each time it is executed, much the way the hardware event counters work. When the counter underflows, it inserts a record into the ring buffer containing data from its arguments. A program uses LWPVAL to implement a technique called value profiling. For instance, it can profile the divisor of a commonly executed DIV instruction and if the data show that the divisor is frequently the same number, it can rewrite the instruction to test for that value and execute an optimized code sequence. Similarly, it can profile the target of a hot indirect branch and generate better code if one way of the branch is dominant.

Who will use LWP?

LWP can be used in many different application environments. These include:

• Managed Runtime Environment: Managed Runtimes (MRTEs) are programming environments such as Java and the Microsoft® .NET Framework. These environments have the ability to generate AMD x86 or x64 code for routines coded in a high level managed language (such as Java or C#), and they can do that on the fly as a program is running. The MRTE can enable LWP and periodically look for performance problems. If (when!) it finds them, it can generate better code for the hot spots and improve the program's overall performance. LWP is lightweight enough that it can run continuously.
• Dynamic Optimizer: A Dynamic Optimizer is a program that monitors an application and attempts to improve its performance by modifying it as it runs. In this case, the target application is compiled to native code from a traditional language like C or C++. The Dynamic Optimizer can gather performance data without affecting the flow of control in the application.
• Compiler Feedback: Most modern compilers have an option to build an instrumented program which the developer runs to gather information on the program's performance. Unfortunately, the added instrumentation (and the fact that optimization levels are often cranked down in a feedback compilation) perturbs the program so much that what's being measured is substantially different from the "real" program. With LWP, the compiler can gather statistics on the program execution without changes, and it can insert LWPVAL instructions to profile interesting areas without adding a large block of instrumentation code and without clobbering any registers. If the application runs without turning on LWP, the LWPVAL instructions act as NOPs and only take a few cycles.

Conclusion

We're very excited about Lightweight Profiling, and I hope this note has piqued your interest. You can read the full specification at the LWP page on Developer Central. There's also an email link you can use to send us your comments and suggestions.

P.S.

My colleagues suggested that I make this more "bloggy" by adding references to "traditional performance values" and "herbal performance enhancers". This postscript is dedicated to them.

Anton Chernoff is a Senior Fellow and architect at AMD. His postings are his own opinions and may not represent AMD's positions, strategies or opinions.

The release of a new version of Sun Studio is always an exciting moment for Sun Studio enthusiasts. Sun Studio 12 came out pretty much two years ago, and a lot has changed in that time.

One particular trend has been that multicore processors have become mainstream. One way of illustrating that is to look at the number of threads per chip for all the submitted SPEC® CPU2006 integer speed results*. The following chart shows the cumulative number of submitted results since the benchmark came out in 2006 until the middle of June 2009 broken down by the number of threads that the chip could support.

Two years ago, when Sun Studio 12 came out, chips that could support two threads were starting to become common. Now we're looking at that being a minimal thread count, and we're starting to see the ramp up of threads that can support more than 4 threads - the latest AMD processors support six threads per chip. In tandem with the growth in thread count, we're seeing much more interest in developing applications that can use this core count. Sun is fortunate that with Solaris and Sun Studio, we have a very comprehensive, and long standing, investment in multiprocessor technology:. from virtualisation, through Zones, to scalability to huge core counts.

Sun Studio has always been on the leading edge of developing parallel applications. There are two ways of leveraging multiple cores, either through libraries provided with the compiler or through the parallisation of your application. For those people using the Performance Library, this is now optimised to take advantage of the latest AMD Quad-core and Six-core processors.

The easiest way of producing parallel code is using automatic parallelisation. Sun was the first company to submit automatically parallelised results for SPEC® CPU2000. Automatic parallelisation is a great technology. It takes some of the work of making parallel codes away from the developer, and places it firmly into the category of "just another compiler flag".

However, the compiler can't do this for all codes, which is why Sun was also one of the first companies to support the OpenMP 3.0 specification.

The OpenMP 3.0 specification is a very important step in making parallel programming easier. The 2.5 specification that was supported by Sun Studio 12 allows developers to identify loops that can be performed in parallel, and different sections of code that can be run simultaneously. The big improvement in the 3.0 specification is the support for Tasks. A task is a unit of work that one thread can request another thread to do. The developer defines the tasks in the source code, but the executed tasks and their order is dynamically determined at runtime. This massively increases the range of applications that can be parallelised using OpenMP.

Of course, writing parallel applications becomes much harder without the tools to support this. Sun Studio 12 Update 1 includes these tools. The Debugger for diagnosing bugs in parallel applications, the Performance Analyzer for determining the activity of all the threads in an application, and the Thread Analyzer for identifying data races in parallel applications. The Performance Analyzer has been enhanced to support hardware counters in the latest AMD processors. The hardware performance counters are an optimal way of determining exactly what the processor is doing during the run of your application.

Performance is often one of the motivating factors for any compiler upgrade. In a compiler suite performance comes from two sources: enabling the developer to identify opportunities to improve performance, and the ability of the compiler to produce good code for the processor. The performance analyzer is able to profile all kinds of parallel applications including those parallelised with OpenMP directives as well as distributed MPI applications. This enables you to quickly determine where, at a source code level, the application is spending its time, and to drill down into that source to understand the performance at the level of hardware events.

The goal for the Sun Studio compiler has always been to produce code that runs as fast as possible on all SPARC and x86 processors. Sun has worked closely with AMD to ensure that the compiler is aware of the best practices for producing code for the latest AMD processors. Sun Studio 12 Update 1 includes this support and continues the long track record of delivering superior performance on AMD processors.

As well as providing support for all processors, Sun Studio is also supported on a number of platforms: Solaris, OpenSolaris, and Linux (for x86). Perhaps most importantly Sun Studio 12 Update 1 is free of charge to download and use.

* SPEC and the benchmark names SPECfp and SPECint are registered trademarks of the Standard Performance Evaluation Corporation.  Benchmark results stated above reflect results posted on www.spec.org as of 15 June 2009.

Darryl Gove is a Senior Staff Engineer in the compiler team at Sun Microsystems. He works on the optimisation and tuning of applications and benchmarks. He is the author of the books "Solaris Application Programming" and "The Developers Edge," and maintains a blog at http://blogs.sun.com/d/. His postings are his own opinions and may not represent AMD's positions, strategies or opinions. Links to third party sites are provided for convenience and unless explicitly stated, AMD is not responsible for the contents of such linked sites and no endorsement is implied.

Like other compilers, Open64 optimizes applications aggressively in many dimensions, but what is different is that Open64 employs innovative techniques that stem from an understanding of the underlying hardware architecture, such as laying out data structures in space and cache efficient manners and deploying aggressive forms of loop-nest optimizations to promote locality. The biggest area this helps is with multi-core scalability, a measure of throughput performance of running multiple applications simultaneously on multiple cores, where a memory sub-system is often stressed.

While the Open64 compiler suite was created to optimize software development for all x86-based architectures, it utilizes many features that take particular advantage of AMD’s technology. One such example is enabling the use of 2MB huge pages for programs built with Open64 to help reduce TLB misses. Another important feature is enhanced code generation and instruction scheduling to take advantage of core pipeline hardware features.  Also, software data prefetching is better tuned to work with the hardware prefetcher and DRAM prefetcher to effectively hide memory latencies. This latest release also offers preview features of OpenMP and automatic parallelization to map program parallelism to multiple cores.

Here’s the full list of new features in x86 Open64 4.2.2 that AMD added (also detailed in the release notes):

·         Support for 2 MB huge pages.

·         Improved loop fusion and loop unrolling.

·         Improved head/tail duplication, if-merging, scalar replacement and constant folding optimizations.

·         Improved interprocedural alias analysis.

·         Improved partial inlining and inlining of virtual functions.

·         More aggressive re-layout optimization for structure members.

·         Improved instruction selection and instruction scheduling.

·         Improved tuning of library functions.

What this compiler suite really enables is highly optimized performance when running multiple applications at the same time, which is pretty much the norm for real-world workloads.  In the spirit of open source projects, we’d like your feedback on how to improve this compiler suite.  If you would like to suggest features for future releases, leave us a comment.  While we can’t promise that the features will be added, we certainly take your feedback under serious consideration.

Roy Ju

AMD Fellow

We'd appreciate hearing what you think about the new "Istanbul" processors, so leave us a comment!

First, the why. When we proposed the SSE5 extensions back in mid-2007, it brought some important innovations to the SIMD side of the x86 architecture:

• a non-destructive three-operand capability, and a four-operand capability to support some very powerful new operations;
• a set of powerful permute and conditional move instructions for data movement, plus Fused Multiply/Add (FMA) instructions for high-performance floating point;
• a variety of other new operations to address various holes in the SSE instruction set: shift/rotate, integer compares, integer multiply/accumulate, and half-precision floating point support.

In April of 2008, Intel published its AVX/FMA proposal, which incorporated several of SSE5's innovations - in particular the three- and four-operand capabilities, the Fused Multiply/Add instructions, and some of the permute instructions - except in a somewhat different form. This proposal also added some new capabilities with a new instruction format: doubling the width of SIMD FP operations, applying the non-destructive three-operand capability to most legacy SSE instructions, and greatly expanding the potential opcode space for future extensions.

With this duplication of functionality between SSE5 and AVX/FMA, and AVX's additional features, we felt the right thing to do was to support AVX. In our minds, a more unified instruction set is clearly what's best for developers and the x86 software industry. With our acceptance of AVX, a key aspect of this instruction set unification is the stability of the specification. Since we don't control the definition of AVX, all we can say for sure is that we expect our initial products to be compatible with version 5 of the specification (the most recent one, as of this writing, published in January of 2009), except for the FMA instructions, which we expect will be compatible with version 3 (published in August of 2008).

Why the FMA difference?  This was not something we did lightly.  In December of 2008, Intel made significant changes to the FMA definition, which we found we could not accommodate without unacceptable risk to our product schedules.  Yet we did not want to deprive customers of the significant performance benefits of FMA. So we decided to stick with the earlier definition, renaming it FMA4 (for four-operand FMA - Intel's newer definition uses what we believe to be a less capable three-operand, destructive-destination format).  It will have a different CPUID feature flag from Intel's FMA extension.  At some future point, we will likely adopt Intel's newer FMA definition as well, coexisting with FMA4.  But as you might imagine, we may wait until we're sure the specification is stable.

The fact remains that AVX does not incorporate all of SSE5's features.  Since SSE5 was based on months of discussions with ISVs on what sort of capabilities they felt were needed, and had been positively reviewed by the industry when we first put out the specification, we decided to follow through with development of these additional features.  To do so most effectively, we redefined them in the AVX framework, resulting in the XOP extension.

So, what's in XOP? 

Well, quite a lot, really.  First of all, the instruction formatting was changed to leverage the capabilities that the AVX VEX prefix brings, using a new VEX-like three-byte prefix sequence called (interestingly enough) the XOP prefix.  This provides three- and four-operand non-destructive destination encoding, an expansive new opcode space, and extension of SIMD floating point operations to 256 bits.  The SSE5 operations that are retained by the XOP extension are:

• Horizontal integer add/subtract: Signed or unsigned add, or signed subtract, of adjacent byte, word, or dword elements in the source vector to word, dword or qword elements of the destination vector. 128-bit.
• Integer multiply/accumulate: Multiplies elements of two input vectors, adding the results to a third input vector. 128-bit.
• Shift/rotate with per-element counts: These use a vector of shift counts, allowing each element of the source vector to be shifted or rotated by a different amount. There is also a rotate instruction with an immediate-byte single count applied to all elements. 128-bit.
• Integer compare: Signed and unsigned comparison of byte, word, dword and qword elements, with predicate (mask) generation as in the various SSE compare instructions. The particular comparison to perform is specified in an immediate byte. 128-bit.
• Byte permute: A powerful operation which copies bytes from two 16-byte input vectors to a 16-byte destination vector, optionally performing a selected transformation on each, under the control of a third input vector. 128-bit.
• Bit-wise conditional move: Selects each bit of the destination vector from either of two input vectors, per a third input vector. 128- and 256-bit.
• Fraction extract: Extract the mantissa from floating point operands. Scalar and 128- or 256-bit vector, single and double precision.
• Half-precision convert: These convert between half-precision and single-precision formats while loading or storing a four- or eight-element vector. They provide dynamic control of rounding and denormalized operand handling.  These particular instructions form a separate extension called CVT16, with a distinct CPUID feature flag.

Along with the FMA4 instructions, these support a wide variety of numeric-intensive, multimedia, and cryptographic applications, and allow some new cases of automatic vectorization by compilers.  Speaking of compilers, plans are afoot to support these in intrinsic form in various compilers, and they may be used automatically in code generation in some cases.

A version of the AMD64 SimNow! simulator with support for these extensions is planned for availability in very short order.

I hope I've given you a good taste of these new features. For all the details on the XOP and FMA4 extensions, you can find the specification here. And, I encourage you to read the blog of our CMO, Nigel Dessau, for an executive perspective on driving innovation into the x86 instruction set. We believe we've struck the right balance between innovation and standardization. Feel free to comment or ask questions - we're always happy to hear from you. As you can see below, we've already heard from ten of our technology partners on the subject.

Dave Christie is a Fellow and senior architect at AMD. His postings are his own opinions and may not represent AMD's positions, strategies or opinions. Links to third party sites are provided for convenience and unless explicitly stated, AMD is not responsible for the contents of such linked sites and no endorsement is implied.

Partner Support Quotes

Absoft

"The addition of AVX support by AMD is a great move as it enables superior performance potential across AMD's x86 family of processors," said Wood Lotz, Absoft CEO. "AMD's use of AVX can also simplify development of high performance compilers and tools for companies like Absoft, and enable customers across a wide variety of industries to build faster applications."

Acumem

"Acumem fully supports AMD's adoption and enhancement of the AVX instructions and will follow this standard as it becomes available in the market. As an ISV for performance tools we clearly see potential for performance improvements with these new additions" said Mats Nilsson, VP Software Engineering at Acumem.

Axceleon

"Axceleon applauds AMDs efforts to support both specifications, AVX and SSE5,  in their XOP specification proposal. The further enhancements in FMA4 which accelerate floating point algorithms are very important to Axceleon's HPC customers and will be welcomed across the board" said Mike Duffy, CEO of Axceleon.

Bibble Labs

"We at Bibble Labs are constantly looking for performance improvements, and as such we are investigating AVX because of the possible performance advantage it might bring. We also appreciate that AMD is taking an active role to ensure the instruction sets converge and not create separate, conflicting instruction sets," said Jeff Stephens, Vice President of Product Development, Bibble Labs.

Cakewalk

"We commend AMD for taking  an active role in open standards, by unifying the x86 instruction set and merging SSE5 into the AVX specification. This can help improve compatibility and simplify the work for developers implementing this. We look forward to investigating AVX for potential advantages it may bring  to our real-time applications and plug-ins," said Noel Borthwick, Chief Technology Officer, Cakewalk.

Nero

"We are pleased that AMD has decided to adopt the AVX instruction set extension instead of offering a variant," said Simone Hoefer, General Manager, Technology at Nero AG. "This will help reduce implementation complexity and multiple code-paths. We are confident that the SIMD (SSE/SSE2) optimizations already implemented will scale nicely to 256-bit/AVX, allowing us to truly embrace this new development."

Smith Micro Software

"Having to choose acceleration solutions that work well on both AMD and Intel CPU platforms, Smith Micro welcomes convergence of the x86 instruction set. AMD supporting AVX is desirable from Smith Micro's point of view," said Uli Klumpp, director of engineering, Smith Micro Software, Inc. "The AVX instruction set extensions are looking promising for further optimizing our computationally most demanding software, DCC and data compression products such as Poser and StuffIt."

Sonic Solutions

"AMD's adoption of AVX will help Sonic unify some of its engineering efforts and reduce development costs," said Jim Roth, Chief Technical Officer, Sonic Solutions. "We welcome this initiative and the proposed enhancements to the x86 processor architecture, which we will leverage to increase the responsiveness and performance of our digital media applications."

Sony Creative Software

"We are pleased that AMD has decided to adopt the AVX instruction set extension instead of offering a variant," said John Freeborg, Vice President of Engineering for Sony Creative Software. "We also appreciate that AMD is taking an active role to ensure these converge and do not create separate, conflicting instruction sets."

Overclocking is the action of running your computer components (like CPU, GPU) at a higher speed than specified (and designed) by the manufacturers. Some reasons why users choose to overclock are to save money and increase performance. However, running the system at a higher speed increases power consumption, which leads to more heat, noise, and potential stability issues. 

In a professional setting, overclocking can be risky.  (That's why we issue warnings, like the one below.)  A minor error could seriously affect system performance and delay project schedules.  But, if you are a hobbyist / tweaker / gamer willing to take the risk and want to extract every last drop from the CPU/GPU, then overclocking is probably a topic you are very interested in. To achieve overclocking on AMD systems, we recommend AMD OverDrive^TM , a state-of-the-art system management tool that includes overclocking capabilities. 

Patrick Moorhead, AMD's VP of Advanced Marketing, has also written several blogs on this topic:

http://blogs.amd.com/patmoorhead/tag/overclock/ 

Also watch this,

The Proving Grounds on Youtube in HD: http://links.amd.com/PROVINGGROUNDS

The Proving Grounds on Youtube in Standard Definition: http://links.amd.com/SDPROVINGGROUNDS

We hope this information helps. So which pill would you take: the red or the blue?  Do you still intend to overclock your system and, if so, is it your work system or your home system? 

***WARNING*** AMD and ATI processors are intended to be operated only within their associated specifications and factory settings. Operating your AMD or ATI processor outside of specification or in excess of factory settings including, but not limited to, overclocking may damage your processor and/or lead to other problems including, but not limited to, damage to your system components (including your motherboard and components thereon (e.g. memory)), system instabilities (e.g. data loss and corrupted images), shortened processor, system component and/or system life and in extreme cases, total system failure. AMD does not provide support or service for issues or damages related to use of an AMD or ATI processor outside of processor specifications or in excess of factory settings. You also may not receive support or service from your system manufacturer.
DAMAGES CAUSED BY USE OF YOUR AMD OR ATI PROCESSOR OUTSIDE OF SPECIFICATION OR IN EXCESS OF FACTORY SETTINGS ARE NOT COVERED UNDER YOUR AMD PRODUCT WARRANTY AND MAY NOT BE COVERED BY YOUR SYSTEM MANUFACTURER'S WARRANTY.

We hope you now know  

• Why AMD cares about Java
• What contributions we've made to the Java community
• Some useful tips for improving the performance of your Java application
• How AMD works with many software partners to optimize their applications

As promised during my talk, here are the links to the Framewave and SSEPlus open source library projects.  Check them out, and contribute your own enhancements to the libraries or let us know what enhancements you'd like to see.

If you missed our session, here are some useful resources

• AMD Java Zone
• AMD Family 10h Software Optimization Guide
• Performance analysis tools
• AMD Libraries (ACML, String library) and AMD-optimized partner libraries

We hope our recommendations for coding best practices were useful. We also hope that you have upgraded to JDK 1.6 to get the latest enhancements we've contributed.

We sincerely look forward to meeting you all again next year (and to the spicy hyderabadi biryani!!).

Were you there?  Drop us a comment to let us know!

-JK

The SANS Institute (an organization where the name derives from SysAdmin, Audit, Networking, and Security) has published the 2009 CWE/SANS Top 25 Most Dangerous Programming Errors. 

The Common Weakness Enumeration (CWE) list at http://cwe.mitre.org/ is a community-created living dictionary of software weaknesses -- that is, *types* of weaknesses. This dictionary and Top 25 list involved experts from the computer industry, academia, the SANS Institute, the non-profit MITRE Corporation, the NSA, and the Department of Homeland Security. The goal of their initiative is to establish standards for assessment and verification of security vulnerabilities in software and the security tools that mitigate those weaknesses.  Simply put, they just want to make computer security measurable. 

Currently the CWE lists 755 total weaknesses (note a few are deprecated duplicates). They leveraged previous work from the deep CVE (Common Vulnerabilities and Exposures) list at http://cve.mitre.org/cve/index.html , which is a large dictionary of specific publicly known vulnerabilities (these generally look like "Buffer overflow in Bar 5.0 in Foo OS 3"). The CVE lists over 3000 confirmed specific vulnerabilities and tens of thousands more candidate vulnerabilities.  So, the CWE lists types of vulnerabilities, and you could say these are abstractions of specific entries from the CVE (as well as a variety of other sources).

So, bubbling to the top of the CWE is their Top 25 Most Dangerous Programming Errors. These are noteworthy errors that can lead to hacked systems, data theft, and system inoperability. Importantly, security exploits rooted to these errors can be easy to code.  Each error is in one of three categories, and these examples will be familiar to some:

1. Insecure Interaction Between Components.  Examples are Failure to Preserve SQL Query Structure (aka 'SQL Injection') and Cleartext Transmission of Sensitive Information.

2. Category: Risky Resource Management. Examples are Failure to Control Generation of Code (aka 'Code Injection') and Failure to Constrain Operations within the Bounds of a Memory Buffer.

3. Category: Porous Defenses. Examples are Hard-Coded Password and Client-Side Enforcement of Server-Side Security.

The SANS Institute believes this Top 25 list will enable buyers (for example state and US government) to buy safer software, where vendors will need to certify by checking for these errors.  Universities can also teach secure coding by a set standard, and software developers and their employers will have greater assurance regarding security vulnerabilities in their software projects.  This gets to the root of cyber-security problems at the source, in software development.

What should you take away from this list? Here are some higher level takeaways and implications:

1. If you develop software, educate yourself on these vulnerabilities and the programming techniques to help mitigate them.  Developers should make a reasonable effort to design security in from the beginning of their projects. A large number of programmers today work on web serving applications, like e-commerce, which requires identity management, secure transactions, and secure record-keeping.  For consumer confidence, security’s clearly going to be a significant concern -- more so than performance or scalability.  And remember that secure programming skills are a desired requirement in many job postings.

2. If you don’t develop software directly, educate yourself at least at a high level on these vulnerabilities anyway.  You don’t need to be paranoid, but some realistic awareness is healthy.  Think about how you manage your confidential data on your computers, whether the data is personal or professional.  A good way to get started here is to take a look at the SANS Top-20 Security Risks at http://www.sans.org/top20/. This covers diverse risks applicable to everyone, like unsecured flash drives, web browser vulnerabilities, denial-of-service attacks due to instant messaging, and so forth.

3. For the IT manager crafting an IT infrastructure, the challenge is even broader, with considerations such as risk assessment, vulnerability assessments, and regulatory compliance.  All these can be looked at through the lens of the SANS Top 25 Most Dangerous Programming Errors.   Remember the goal behind the CWE effort is to make software security measurable, and the Top 25 List is a focal point for that goal.

We'd appreciate hearing what you think about the new "Shanghai" processors, so leave us a comment!

Here’s a sneak peak of some cool things we are planning to demo:

• How to simplify testing environments by using virtualization to do processor scaling tests
• How to find hotspots and do thread analysis on your code using the AMD CodeAnalyst™ performance analyzer from within the Visual Studio IDE
• How to help get performance improvement through program  parallelization using the Microsoft® Concurrency Runtime
• How AMD and Microsoft have worked together to provide developers with a comprehensive cloud computing platform and development environment

We also plan to have sessions in our booth’s Speed Zone Theater including:

• Software Optimization, Part I: Memory
  • Making the best use of system memory.  Arrays vs. linked lists, NUMA, and using the AMD CodeAnalyst performance analyzer.
• Software Optimization, Part II: Cache
  • Making the best use of data cache.  Data packing, prefetching, non-temporal data, and using the AMD CodeAnalyst performance analyzer.
• Virtualization
  • An overview of how developers can use virtualization in their development environments.
• Intro to AMD Developer Central
  • A look at the tools and other resources that we offer on developer.amd.com.

Oh, and in the spirit of this being a show focusing on the future, I should mention that we will be running some of these demos on our soon-to-be released processors! 

Finally, we have some awesome gifts lined up for you (while supplies last).  People who attend our Speed Zone Theater sessions will get a t-shirt and if you come see each of our demos you’ll get a 2GB USB drive loaded with developer tools and optimization guidance. Hope to see you there!

What other topics do you want us to talk about?  Software visible features of our processors?  Roadmaps?  Parallel Programming?  Just take a moment to set me know by leaving your comments to this blog, I’ll do my best to get it added to our list of sessions.

Sharon Troia, AMD Developer Central

The AMD Developer Central staff is considering a facelift for the developer.amd.com Web site, and we want to make sure it meets your needs. That's why we're previewing some concepts, with an opportunity for you to vote on them. Your feedback will help us to decide on a final design and layout scheme that will be easier to use and more pleasing to the eye.

Check out the concepts below, and then take five minutes to vote on your favorites.

» Click here to take the survey

Thanks for participating!