Saturday, December 13, 2008
Defeated
This is the gas valve from a Yugoslavian SKS I J.B.Welded into the gas block. When I got tired of banging my head against my desk trying to make my code run fast, I went into the living room and banged a hammer against a punch [and against my fingers] to remove this reluctant part so I could replace it.
Strangely, the difficulty was not that the J.B.Weld refused to give; I achieved small motion early on. Rather, the simple matter of non-zero volume wedging the part against the gas block walls made extracting it difficult.
Advice: attempting to join parts that were intended to be separate limits your options in the future.
Advice for those who ignored first bit of advice: buy a good selection of punches now because you'll need them. Drill a small pit in the part you're trying to separate, then use the correctly sized punch so you don't damage the surrounding material. Avoid stressing things like barrels by properly supporting the job with wooden blocks or substitute.
Native Client and Alchemy: Software as a Service?
Not so long ago, Google announced Native Client which describes a way in which a browser may execute native instructions in secure sandbox. The natively executing code would run at full speed, and the sandbox would provide a platform-independent layer of abstraction so applications targeting whatever framework was distributed with Native Client The Product (tm) could run on Mac, Linux, or Windows. The paper linked from the "NaCl" page describes the security measures taken to ensure natively executing code can do nothing harmful. Presumably, just running a NaCl browser on a Linux, Windows, or Mac system as a user with minimal privileges to the file system and other resources is already sufficiently secure, but the sandbox protects the browser process as well.
Previously, Adobe announced Alchemy leveraging the Low-Level Virtual Machine bundled with the Flash player as a way to run C++ applications at near native speed with the safety of executing in a virtual machine and dynamic compilation framework. LLVM has the added benefit of being a mature project with fairly robust and well-designed development tools and runtime features.
The commonly cited application for these frameworks is "to run Quake in a browser!" While interesting in its own right, a conversation with Uniquely Joe sparked the idea that perhaps this offers a new business model for software development. Instead of buying shrink-wrapped software in a box, or downloading a torrent from your favorite pirate search engine, you simply log into your software account provided by Adobe, Google, Microsoft, or other, and use the applications you've purchased a service plan for. This benefits you because you don't have to worry about maintaining all of these software installations on the several computers you may work from, software upgrades are more seamless [perhaps less expensive for each subsequent version but now there are many more versions though only your checking account really notices], and perhaps there is a security benefit too if most of your applications run in some sort of sandbox.
This benefits software publishers because distribution costs diminish as there are no shrink-wrap boxes to produce, revenues are more constant due to the service-oriented usage model, you can push advertisements to your users and probably achieve better product integration, and you can curtail piracy since presumably you could build in a cryptographic certificate to prevent execution of your application except where authorized by your license server. With everything running in a sandbox with a uniform abstraction layer on all architectures, testing and support costs should also diminish. As we learned in CS 8803, dynamic compilation frameworks are able to perform many optimizations at runtime that enable an application to [eventually] achieve high performance tuned to the actual system on which it is executed. 'Application + dynamic optimizer' is clearly parallelizable so additional processor cores should reduce the impact of dynamic translation overheads.
Will consumers like it? While some won't even notice a difference, many might be attracted for the reasons previously listed. If Adobe can count on users having LLVM installed, or users willing to install it, it may take this route exclusively. How many people would be willing to eschew Adobe's impressive productivity suite in favor of the disjoint FOSS projects out there?
Comments welcome.
Previously, Adobe announced Alchemy leveraging the Low-Level Virtual Machine bundled with the Flash player as a way to run C++ applications at near native speed with the safety of executing in a virtual machine and dynamic compilation framework. LLVM has the added benefit of being a mature project with fairly robust and well-designed development tools and runtime features.
The commonly cited application for these frameworks is "to run Quake in a browser!" While interesting in its own right, a conversation with Uniquely Joe sparked the idea that perhaps this offers a new business model for software development. Instead of buying shrink-wrapped software in a box, or downloading a torrent from your favorite pirate search engine, you simply log into your software account provided by Adobe, Google, Microsoft, or other, and use the applications you've purchased a service plan for. This benefits you because you don't have to worry about maintaining all of these software installations on the several computers you may work from, software upgrades are more seamless [perhaps less expensive for each subsequent version but now there are many more versions though only your checking account really notices], and perhaps there is a security benefit too if most of your applications run in some sort of sandbox.
This benefits software publishers because distribution costs diminish as there are no shrink-wrap boxes to produce, revenues are more constant due to the service-oriented usage model, you can push advertisements to your users and probably achieve better product integration, and you can curtail piracy since presumably you could build in a cryptographic certificate to prevent execution of your application except where authorized by your license server. With everything running in a sandbox with a uniform abstraction layer on all architectures, testing and support costs should also diminish. As we learned in CS 8803, dynamic compilation frameworks are able to perform many optimizations at runtime that enable an application to [eventually] achieve high performance tuned to the actual system on which it is executed. 'Application + dynamic optimizer' is clearly parallelizable so additional processor cores should reduce the impact of dynamic translation overheads.
Will consumers like it? While some won't even notice a difference, many might be attracted for the reasons previously listed. If Adobe can count on users having LLVM installed, or users willing to install it, it may take this route exclusively. How many people would be willing to eschew Adobe's impressive productivity suite in favor of the disjoint FOSS projects out there?
Comments welcome.
Thursday, December 11, 2008
GPU QR
My GPU QR algorithm achieves a 10.8x speedup over the native MATLAB QR for large matrices. This is faster than I have seen anyone report by far.
I'm working on an Intel MKL testbed application, as that's probably the fastest QR available for x86 and is the ultimate reference implementation.
I'm working on an Intel MKL testbed application, as that's probably the fastest QR available for x86 and is the ultimate reference implementation.
Thursday, December 4, 2008
Organization of Knowledge
I clicked through to this page on Wikipedia. Clearly, pages like this are useful. I'm pretty sure any good PhD student, by the time they're ready to propose, should be able to sit down at Rocky Mountain, drink several pints, and rattle off something similar for their field.
Subscribe to:
Posts (Atom)