Intel® Secure Key, was previously code-named Bull Mountain Technology. It is the Intel name for the Intel® 64 and IA-32 Architectures instruction RDRAND and its underlying Digital Random Number Generator (DRNG) hardware implementation. Among other things, the DRNG using the RDRAND instruction is useful for generating high-quality keys for cryptographic protocols.

Because this technology recently launched (May 2012) with the Intel(r) 3rd Generation Core processors (code-named Ivy Bridge) the Bull Mountain Software Implementation Guide has been renamed to the Intel(r) Digital Random Number Generator Software Implementation Guide.

This technology is documented and described in the Intel(r) Digital Random Number Generator Software Implementation Guide. It is intended to provide a complete source of technical information on the RDRAND Instruction usage, including code examples.  Here is a recap of what this guide covers:

• Random Number Generator (RNG) Basics and Introduction to the DRNG. This guide describes the nature of an RNG and its pseudo- (PRNG) and true- (TRNG) implementation variants, including modern cascade construction RNGs. We then present the DRNG's position within this broader taxonomy.
• A technical overview of the DRNG, including its component architecture, robustness features, manner of access, performance, and power requirements.
• RDRAND Instruction usage, providing reference information on the RDRAND instruction and code examples showing its use. This includes RDRAND platform support verification and suggestions on DRNG-based libraries.

This Software Implementation Guide is designed to serve a variety of readers. Software Developers who already understand the nature of RNGs may skip the first 3 sections and simply refer to the RDRAND instruction reference and code examples.

Here is the link for the  Intel® Digital Random Number Generator (DRNG) Software Implementation Guide.

Questions?  Please visit our forum and start a discussion.

I recently attended a symposium, co-sponsored by TACC and Intel, at the Texas Advanced Computing Center (TACC) in Austin where the programming of two many-core devices were discussed. One was a research chip designed to push some limits and allow interesting research on a device that lacks many things a product would require. The research chip is known as Intel’s Single-Chip Cloud Computer (SCC). The other many-core device was, a prototype of our new Intel Many Integrated Core (MIC) Architecture, the Knights Ferry co-processor. The deadline for papers precluded inclusion of results from pre-production Knights Corner co-processors which will be the first Intel MIC co-processor products. There was a lot of whispering in the hallways about the excitement of starting work with Knights Corner co-processors.

The papers, and the half day tutorial, at the “TACC-Intel Highly Parallel Computing Symposium” all had strong elements relating to familiar parallel programming challenges: scaling and vectorization. This is because both devices are built on Intel Pentium processor cores hooked together with their design for a connection fabric on the same piece of silicon.

Simply put, they are both SMP on-a-chip (symmetric multi-processors) devices, with somewhat different design goals.

At Intel, we have been convinced that putting a familiar generally programmable SMP on-a-chip is a good idea. It has a familiarity in programmability which proves to have many benefits. SCC was built for research into many facets of highly parallel devices. Knights Corner is designed for production usage and is optimized for power and highly parallel workloads. Knights Corner is well suited for HPC applications that already run on SMP systems. Presenter after presenter who talked about using the prototype Knight Ferry mentioned how applications “just worked."

I like to say, “Programming is hard, and so is parallel programming.” It follows that making an SMP or an SMP on-a-chip get maximum performance may not quite be rocket science, but it is no walk in the park. So, there was plenty of room for the papers to discuss the challenges of tuning for any SMP system.

What was really striking was how optimizations for Knights Ferry co-processors were applicable to SMP systems in general. Several authors commented on how their work to get better scaling or better vectorization for Knights Ferry also improved the performance of the same code compiled to run on an Intel Xeon processor based SMP system.  This performance-reuse is very significant, and one presenter exclaimed “Time spent optimizing for MIC is time well spent because it optimizes your code for non-MIC processors at the same time.”

All the papers and presentations (including my keynote) are available on-line now at http://www.tacc.utexas.edu/ti-hpcs12/program

Here are some notes from a few of the talks:

Dr. Robert Harkness, gave an engaging talk entitled “Experiences with ENZO on the Intel Many Integrated Core Architecture.” I enjoyed his comment that “we always programming for the future” because they “never have enough compute power.” He looked at multiple programming models, but had the best results using the “dusty” MPI based program that he had running on an SMP before Knights Ferry. He did his work on MPICH 1.2.7p1 because Intel did not supply an MPI with the Knights Ferry systems. He said it was obsolete but very easy to build and use. He reported that one person (not a dedicated programmer) was able to build everything (a quarter million lines of code) in a single week without any application source code modifications at all. The week, it seems, was spent hunting down libraries and recompiling them including MPICH. His results scaled very well.

His conclusions (from slide 30 of his presentation) were: “Intel MIC is the best way forward for large-scale codes which cannot use the existing GPGPU model (even with directives).”

A talk by Theron Voran, with the National Center of Atmospheric Research, looked at using Knights Ferry for Climate Science. He started by saying "We have large bodies of code laying around. We don't want to rewrite in new languages for restrictive architectures." He had several good introduction slides including a comparison of accelerators vs. multicore and many-core devices.

Here the challenges of vectorization offered opportunities for future work. Compiler hints, loop restructuring and relate activities should enhance performance on Xeon-based and MIC-based SMP systems, as well as work on improving scalability on more and more cores. Even with these challenges, the authors noted “Relative ease in porting codes” (recompiling) and the belief that computational capabilities of MIC will be worthwhile.

Ryan Hulguin, with the University of Tennessee, looked at CFD solvers on Knights Ferry. He looked at two methods, one based on Euler equations (for inviscid fluid flows) and another based on the BGK model Boltzmann equation (for rarefied gas flows). Performance results showed OpenMP to be effective on Knights Ferry, and that the SMP programming challenges of vectorization and having good concurrency held true on Knights Ferry as well.

A talk on Dense Linear Algebra Factorization, from David Hudak at the Ohio Supercomputing Center, talked about Heterogeneous Programming Challenges. David is a Wolverine working in a Buckeye world. My heart goes out to him. I really enjoyed his separation of short-term issues that distract us from the real long-term challenges that will stay with us.

The talk compared a QR factorization implemented in OpenMP with a Cilk Plus implementation. Both performed well. The authors emphasized that guidance to Vectorize and use lots of tasks, proved to work.

I’ve written more than I set out to write, so I’ll stop here. The SCC related papers were very interesting as well, ranging from Tim Mattson’s overview of the program to papers showing research results from investigations using SCC. The other MIC related papers are all worthy as well, including an excellent paper on early experiences with MVAPICH2 doing Intra-MIC MPI communication. Amazing things you can do on an SMP on-a-chip… it runs a real Linux after all!

It is very common for demos to start with an ‘ssh’ (shell) to one of the Knights Ferry processors… and then running the application natively from the command line. SMP on-a-chip, indeed.  Too bad I can’t convince Intel to name it that.  Even if I did, it would probably be chipSMP™ model 8650plus XS. Nevermind, Knights Corner is fine by me.

The papers and talks can be at http://www.tacc.utexas.edu/ti-hpcs12/program

In support of the recent announcement of the 3^rd Generation Intel® Core™ Processors, Intel has released the Intel® SDK for OpenCL* Applications 2012. For the first time, OpenCL* developers using Intel® architecture can utilize compute resources across both Intel® Processors and Intel® HD Graphics Driver 4000/2500

From a person who, for the last couple of years has closely followed the emergence of the OpenCL standard, this announcement was something worth waiting for.  Less than a year ago, on this blog, I posted the news that the Intel® OpenCL SDK 1.1 gold  was released,  This was the first production OpenCL implementation from Intel targeting Intel® processors on Windows* OS. This current announcement is special, the Intel SDK for OpenCL Applications 2012 now supports not only the CPU but also the Intel HD Graphics 4000/2500 for Windows* 7 users.  We’ve come a long way in a year.

OpenCL on the 3^rd Generation Intel® Core Processor Family extends Intel’s line of tools and APIs on Intel platforms and adds interoperability with other graphics APIs like DirectX*, OpenGL* and Intel® Media SDK, directly on the Intel HD Graphics device.

So what else is new in this release?

• A Single OpenCL* platform enables shared context for OpenCL applications running on both the CPU and Intel HD Graphics 4000/2500. The OpenCL platform with both CPU and HD Graphics devices is available seamlessly on the Intel® HD Graphics Drivers.
• Interoperability with the Intel Media SDK with no memory copy overhead
• Improved performance for OpenCL applications running on Intel® Xeon® Processors and Intel® Core™ Processors. This CPU support is also available for Linux* OS developers.
• Intel® SDK for OpenCL* applications development tools includes an offline compiler and a step-by-step OpenCL Kernel debugger (for CPU) integrated in Microsoft Visual Studio* 2010 integrated development environment.
• 10 OpenCL code samples, three of them new, are now available for independent download.

The list above is just a sample of what is available with this new SDK. I recommend you read the product brief or watch the introduction video to get started with this new SDK.

Download the SDK for free at www.intel.com/software/opencl and begin optimizing your applications for the 3^rdGeneration Intel® Core™ Processors today.

Don’t forget to follow us on Twitter at @IntelOpenCL

I used to feel the same way...albeit with a latent desire to learn it as I wish I knew Latin. Then one day I found myself out of options on my SIMD code generation project. The compilers were great, but making progress was like building a ship in the bottle. I was playing a game I know you've played too: "Let's Guess What the Compiler Will Do"!

I got tired of that game and bit the bullet. I did ASM dumps and tried to understand them. At first it appeared to me as a chaotic mess...like stars to someone who's never learned the constellations. As time went on though I found Orion! And Ursa Major too! Sideribus apparuit! That is, the patterns jumped out and became easy. Before I knew it, diving into ASM became part of my routine.

I want to share my know-how with you. Each post I'll give you a program and take apart the ASM that we care about using the Intel® C++ Compiler for Linux*. I guess I'll expect you to have a basic understanding of ASM, registers and the like...though I won't expect much. Stay tuned!

Where the main focus area used to be - Video Encoding:
The most compute-intensive part of a video encoder is usually Motion Estimation (ME) where blocks from the
current frame are checked against blocks from the previous frame to find the best match. Many metrics can
be used to define the best match. The most common is the L1 metric: the sum of absolute differences. Due to
the nature of ME, loads of the blocks from the previous frame are unaligned whereas loads of the blocks from
the current frame are aligned. Unaligned loads suffer two penalties:
• cost of handling the unaligned access
• impact of the cache line splits
The NetBurst microarchitecture does not support a uop to load 128-bit unaligned data. For that reason, 128-bit
unaligned load instructions, such as movups and movdqu, are emulated with microcode, using two 64-
bit loads whose results are merged to form the 128-bit result. In addition to the cost of the emulation, unaligned
loads are penalized by the cost of handling cache line splits if the access crosses a 64-byte boundary.
SSE3 adds lddqu to solve the cache line split problem on 128-bit unaligned loads. The instruction works by
loading a 32-byte block aligned on a 16-byte boundary, extracting the 16 bytes corresponding to the unaligned
access. Because the instruction loads more bytes than requested, some usage restrictions apply. Lddqu should
be avoided on Uncached (UC) and Write-Combining (USWC) memory regions. Also, by its implementation,
lddqu should be avoided in situations where store-load forwarding is expected. In load-only situations, and with
memory regions that are not UC or USWC, lddqu can advantageously replace movdqu/movups/movupd.
The code below shows an example of using the new instruction. Both code sequences are similar except that
the load unaligned (movdqu) is replaced by the new unaligned load (lddqu). With the assumption that 25%
of the unaligned loads are across a cache line, the new instruction can improve the performance of ME by up to
30%. MPEG-4 encoders have demonstrated speedups greater than 10%.

Now some code snippet,

Motion Estimator without SSE3:
movdqa xmm0, <current>
movdqu xmm1, <previous>
psadbw xmm0, xmm1
paddw xmm2, xmm0

Motion Estimator with SSE3:
movdqa xmm0, <current>
lddqu xmm1, <previous>
psadbw xmm0, xmm1
paddw xmm2, xmm0

from http://download.intel.com/technology/itj/2004/volume08issue01/art01_microarchitecture/vol8iss1_art01.pdf

A bit later there happened to be some follow ups, where most noticeable:
http://software.intel.com/en-us/forums/showthread.php?t=56271
and
http://x264dev.multimedia.cx/archives/8

so, in summary: starting from Intel Core 2 brand ( Core microarchitecture , from mid 2006, Merom CPU and higher) up to the future: lddqu does the same thing as movdqu

In the other words:
if CPU supports Supplemental Streaming SIMD Extensions 3 (SSSE3) -> lddqu does the same thing as movdqu,
If CPU doesn’t support SSSE3 but supports SSE3 -> go for lddqu
(and note that story about memory types )

And the last point – from the patenting point of view, be aware about patent number: 6721866
http://www.google.com/patents/US6721866
as approach been used is actually protected.

Ultrabooks, on the other side, as been a cutting edge are incline to use even more advanced technology feature, called Quick Sync Video or QSV which is to allows for all related to video decode and encode activities be offloaded from the main CPU to the integrated graphics, meaning be faster or power smarter. 

About development in this area - just note a key link for now : http://software.intel.com/en-us/articles/vcsource-tools-media-sdk/ 

PS: FYI one and good place for “all Intel’s microarchitectures” view: http://en.wikipedia.org/wiki/List_of_Intel_CPU_microarchitectures

So what things does she like most about it? The below is in her words.

1) She loves the design, how sleek it is, and the brushed metal appearance.
2) Loves the small form factor – fits in most of her handbags.
3) Loves the Keyboard. Likes the spacing between the keys & the way they feel.
4) Setup was seamless, found all her ‘piles of different devices’. “Right out of the box everything worked”.
5) Liked the fact she didn’t have to download a bunch of updates. Was up and running quickly.
6) The Solid State drive. (I asked her how she knew about that) – ‘because she read up on it’.
7) Boots up super-fast.
8) Likes the attention to detail.
9) Out of box experience was great. Wasn’t like unpacking something from just a bunch of cardboard.
10) Likes the Case it came with, it’s like an envelope case.
11) Loves the battery life.

Ok… so I realize this is a sample of one; but I’m struck at how quickly she rattled off all the above features without even thinking about it. So… about ten minutes later I asked her – ‘So what do you like about the iPad 2’? (Note: It took her about three times the length of time to list the following things)

1) Touch screen.
2) Size of the Form Factor.
3) Convenience that it offers in being able to multi-task.
4) Can play games on it.
5) Good for reading stuff.
6) Quickly checking email.

That’s where it ended… and then about three minutes later she says … ‘well, now with my Ultrabook, the iPad has now pretty much been relegated to being a kitchen gadget’.
Interesting….
So then I flipped the bit and asked her – ‘Is there anything you don’t like about your Ultrabook?’ – Answer: “not yet”. IMO that's pretty cool.

Ok - so now onto some gratuitous pics of most of these devices. (Note: I didn’t include my Alienware M11x this time around). In the foreground – bottom to top: iPad 2, Asus Ultrabook, HP dv6, and then the Dell M1530

In this next pic.. I’m comparing the thickness of the Dell to the Asus Ultrabook.

In this following pic I’m comparing the thickness of the Ultrabook (on the bottom) as compared to the iPad 2

In this final pic I’m comparing the iPad 2 (I had to put the case back on it in order to prop it up), the Ultrabook, and then the HP dv6

For those concerned about the dimension of weight. The Dell XPS for example weighs 5.9lbs (2.6 kg), the Ultrabook comes in at 2.9lbs (1.3 kg). This weight factor alone is one of the biggest selling points for me. The best part is that I’m seeing little to no tradeoffs yet with regards to overall performance. These devices are packing a pretty serious punch.

So – in a nutshell I’m having some serious PC Laptop envy right now. I might wait a few more months though. For those that have been following the Ultrabook category – we should also start seeing the Ultrabooks that also integrate ‘touch’ – and convert into being either a Laptop and or a Tablet when you want it. At any rate, I’m very sold on the concept, and yes, I’m keeping a very close eye on ensuring that all the games we PC Gamers love to play – play well on these! Stay tuned!

If you've ever dual booted a system before, the procedure for doing it for Windows 8 is not all that different. In summary, all you need to do is create a new partition for Windows 8, install it on that partition, and then edit your new boot menu if you want to keep Windows 7 as the default OS.

Step One: Download and burn the Windows 8 Consumer Preview

• Assuming that you downloaded the Consumer preview ISO image from the link above, you can use the “ Microsoft Windows 7 USB/DVD Download Tool to either burn the ISO image to a DVD disc or a USB drive. The tool is free, and very small, and installation instructions are available in the site itself and are very simple. Of course if you prefer to use other burning software like ImgBurn, you can do that too.

Step Two: Create a New Partition

• Before you start, make sure to make a backup of your data and files. We will be creating new partitions and installing a new OS, so anything could go wrong, and you don't want to lose your everything. For paranoid people like me, I like taking "bare metal" backups of my systems with a wonderful open source and free tool called Redo Backup. A bare metal backup takes a complete image of your hard drive, with all of its partitions. That way, I am able to restore my entire system the way it was exactly if needed. Going into more details about backups however is another topic.

• When you're ready, from within Windows 7, we will create some space for Windows 8 by using Windows' Disk Management. Click on the Start Menu and right click on "Computer", then click "Manage", and in the window that appears, click on "Disk Management" in the left sidebar.

• Find your system hard disk in the graphical list that appears in the bottom pane. Right-click on it and then click "Shrink Volume". 20 GBs is a reasonable size that is not too small and not too big for the new Windows 8 partition, so shrink it down so you have at least 20GB of space left on the end of the drive, and click OK. Of course if you think you need more than 20 GB (if you are going to do intensive development and/or testing), or less than 20GB (if you don’t have enough space on your Windows 7 partition), then please feel free to choose a different size.

• Then, click on the "Unallocated" block of that drive that appears and click "New Simple Volume". Click Next on the next few windows until you reach the "Format Partition" window. Here, give it a volume label you'll recognize (like "Windows 8") and click Next. It should format the drive for you. Now you're all set to install Windows 8.

Step Three: Install Windows 8

• Now reboot your system, and go into your BIOS settings (for most systems, you need to press F2 or DEL). Now make sure your computer is set to boot from CD or USB as a first priority (depending on what medium you have decided to use earlier). This may be different from system to system though. Now reboot.

• Now you should boot into the Windows 8 installer. It looks very similar to the Windows 7 installer, so it should be familiar. Pick your language and hit "Install Now”.

• Enter the Product Key available on the Windows 8 Consumer Preview download page.

• Now choose "Custom" when asked what type of install you'd like to perform. Then find the new partition you created on the list of drives shown. Make sure it's the right one, because remember, you are about to write over whatever is on it.

• Hit "Next" and let the installer do its thing. When you're done, your computer should reboot into Windows 8. It'll probably reboot one more time after it does, then you will see the Windows 8 Start screen.

Step Four: Make Windows 7 the Default OS Again