Related articles

• Today’s Apple PCs work well with Windows PCs. Samba networking is built-in, allowing you to share files with Windows PCs. The aftermarket combo of MacFUSE and NTFS-3G also brings read and write access to NTFS drives (although there is no way to chkdsk an NTFS formatted drive in OS X). One of the strengths of Linux and Windows over OS X is the wide variety of software that’s available. What makes the Apple sandbox so viable is that the internal set of software is robust enough to stand on its own. A lot has been said about the iLife suite, but one great example of Apple software is Time Machine. Time Machine brings EMC/Dantz Retrospect-like functionality for single-user PCs. All you have to do is specify where you want your backups stored. With the current version of OS X, you can specify an external HFS+ formatted drive or an AFS shared store. If you’re using an AFS shared store, Time Machine will store the file in a single file (“sparsebundle”). If you’re using a local external drive, Time Machine will store the files individually. For the initial backup, Time Machine makes a complete duplicate of your computer ignoring caches and temporary files. After the initial backup, Time Machine makes incremental backups updating only the changed files. Time Machine saves the hourly backups for a 24 hour period, daily backups for the past month, and weekly backups for everything older than a month. This allows you to recover from a complete failure of your hard drive with, at worst, a one hour backup. More important, this protects users from user error. If I accidentally hit save instead of save as… and overwrite an important original file, it will be possible to skip back and restore a file from a specific point in time. What’s nice about Time Machine is that it works well and encourages regular users to regularly backup their data. The integration into the operating system is seamless and it feels like a built-in-feature as opposed to “bundled 3rd party software.” In the current version of OS X, no compression is used. Snow Leopard (OS X 10.6) will be adding HFS+ compression capabilities that will increase the number of files that can be stored. NTFS has had compression for ages.

• Tell me about CUDA, the "architecture," versus the "CUDA for C" compiler.CUDA is the name of Nvidia’s parallel computing hardware architecture. Nvidia provides a complete toolkit for programming the CUDA architecture that includes the compiler, debugger, profiler, libraries, and other information developers need to deliver production-quality products that use the CUDA architecture. The CUDA architecture also supports standard languages (C with CUDA extensions and Fortran with CUDA extensions) and APIs for GPU computing, such as OpenCL and DirectX Compute. This diagram may help: With OpenCL, you gain the advantage of cross-platform support, but lose automated tools, such as memory management, that are found with CUDA. It seems that as a scientist, you'd want to decrease your startup development costs, but at the same time, you'd want support for multiple platforms. What's the best way to reconcile this challenge? There are certainly compromises that have to be made to provide a cross vendor/platform solution. Nvidia has worked from the beginning with Apple and the OpenCL working group to make sure OpenCL provides a great driver-level API layer for GPU computing, especially for Nvidia hardware. Furthermore, we will certainly provide extensions to further enable Nvidia GPU’s with OpenCL. Nvidia is also constantly improving our C compiler and development environment for Nvidia GPUs. We have a few simple extensions to C in order to enable our GPUs. If Fortran is more your preference, there is a Fortran compiler also available. With the introduction of Microsoft’s Windows 7 this fall, users and developers will have access to the DirectCompute API, which shares many concepts with our C extensions. Nvidia seeded a DirectCompute driver to key developers last December. These are the added advantages to choosing Nvidia hardware; we support all major languages and API’s. Your work with GPUs started in the GeForce 5 era, and we're now several generations later. Obviously, the newer stuff is faster, but what new capabilities have been introduced over this time period (i.e. IEEE-754 compliance)? What can we do now that we couldn't do before? Early programmable GPUs were basic floating point-only programmable processors. No integer or bit operations, no general access to GPU memory, no communication between neighboring processors. The first main innovation was to provide the hardware needed for supporting C, which includes full pointer support and native data types. Another key innovation was the addition of dedicated, on-chip shared memory, which allows processors to intercommunicate and share results, greatly improving the efficiency of the algorithms. In addition, it offered programmers a place to temporarily store and process data close to the processor, rather than going all the way out to off-chip DRAMs. Shared memory improved our signal processing library by 20x over a similar OpenGL implementation. Finally the addition of double-precision floating point hardware also signified a key step toward GPUs as a true high performance computing product, enabling applications that required extended precision numerics. It should also be noted that memory speed and on-board memory size improvements (up to 4GB per processor and 16GB for our Tesla 1U server) has increased the scale of problems an Nvidia GPU can tackle. What about the compiler? What kind of optimizations and innovations have been added over time? Very early on, we recognized that we needed to build a world-class compiler solution. GPU computing programs tend to be much larger, more complex, and benefit from more complex optimization. Our competition (the CPU) had almost 40 years to get it right. Our C compiler is based on technologies from the Edison Design Group, who has been making C compilers for 20 years, and the Open64 compiler core, which was originally designed for the Itanium processor. Our compiler technology, combined with the world-class compiler team we’ve assembled, is a key part of Nvidia’s success. Currently, most GPUs are very fast with single precision math, but less quick with double precision math. Will GPUs still provide "better than CPU" cost/performance if it weren't for the economies of scale? That is, could you make a special double precision-optimized GPU while still keeping costs low? As the market for GPU computing clearly continues to grow, I think you will see more areas invested in double precision arithmetic. Our double precision hardware released last year was only the starting point for what I imagine will be a growing investment in GPU computing from both the industry and Nvidia. What is your impression of Intel's Larabee? AMD's Stream Architecture? Cell? Zii? My view of Larabee is that it is a great validation of what the GPU has achieved and an acceptance of the limitations the CPU. Where CPUs have tried to take a legacy sequential programming model and squeeze out every last bit of parallelism, GPUs were created for 3D rendering, an embarrassingly parallel application. Massive parallelism is a part of the GPU’s core programming model.  In the end, it is the accessibility and productivity of a programming model that will take an architecture from a novelty to a success. We are all competing against a mountain of legacy code. We’ve focused on making Nvidia GPUs extremely easy to obtain orders of magnitude speedups with a familiar and simple programming model.

• Alan: So things like “sandboxing” are designed to prevent unforeseen vulnerabilities from being transformed into large exploits. Dino: Yes, as the name suggests, “sandboxing” is meant to contain the spill in the event of a compromise. Sandboxes don’t actually prevent exploits, however. They more prevent those exploits from taking other actions on the system. For example, Google’s Chrome has a very restrictive sandbox for Web rendering processes. And while this won’t prevent an exploit from executing arbitrary code, it will prevent that executing code from harming your system. Alan: You've really been able to adapt your knowledge from PowerPC era to the Intel-Mac era. With the upcoming Snow Leopard, Apple will be implementing features such as ASLR, code signing for kernel extensions, full NX bit support, and sandboxing for many of the main applications. These are all features currently supported by Vista. How is this going to help secure the Mac? How does "sandboxing" really work when Chrome's first exploit allowed remote applications to be launched from Java, and IE8 was recently exploited at this year's CanSecWest? Dino: I haven't looked at Snow Leopard yet due to the pre-release NDA, but I am glad to hear that they will be implementing those features.   Alan: You know actually, as you were saying that, I just realized that I don’t think it’s actually 100% confirmed yet. It’s really just the blogsphere right now. But let’s assume that this is what Snow Leopard will add. How is that going to change things? Dino: I hope their implementations are sound and I will definitely be buying and installing Snow Leopard on all of my systems from Day One. All of these security features hamper attacks at multiple stages. ASLR and NX make it much more difficult for an exploit to inject or re-purpose code in an application. The sandboxing limits the actions that an application can perform so that even if it does begin running attacker-supplied code, the actions that the attacker may perform will be constrained. Finally, kernel extension code signing prevents attackers from installing new software into the core of the operating system. Attackers often install rootkits into the kernel in order to conceal their attacks and maintain access to compromised systems. There is a difference between operating system-level and browser-level sandboxing. Chrome is the only Web browser to implement browser-based sandboxing. This is a highly smart move on their part and the main reason that Chrome was not compromised at Pwn2Own this year. The limitation of Chrome's sandbox model, however, is that it cannot sandbox Web browser plugins such as Flash and Java. These plugins need full access to the system, so the sandboxing system used for Web content renderers cannot be used. The Web content rendering processes are highly limited and cannot touch the file system at all. Breaking out of the Chrome renderer process sandbox would be an impressive feat in itself.