Browsed by
Category: Programming

Programming for the Larrabee/Xeon Phi

Programming for the Larrabee/Xeon Phi

Back in the day, I worked on this little project called Larrabee – which later turned into the Intel Xeon Phi coprocessor. It was an ambitious and exciting platform. It consisted of a ton of 512 bit wide instructions to operate like a lot of streaming GPU architectures, yet was fully general purpose x86.

It turned out that getting performance out of this hardware was difficult. In order to get the full potential of the hardware, you simply had to utilize the vector units. Without that, it is like writing a single threaded app on a 8 core system. Single SIMD lane operation just wasn’t going to cut it as was written about in 2017 International Journal of Parallel Programming article:

“Our results show that, although the Xeon Phi delivers a relatively good speedup in comparison with a shared-memory architecture in terms of scalability, the relatively low computing power of its computational units when specific vectorization and SIMD instructions are not fully exploited makes this first generation of Xeon Phi architectures not competitive”

Using the Xeon Phi Platform to Run Speculatively Parallelized Codes

The paper, and the host of others linked on the page as references, are a good read and gives some hints why fixed-function GPUs have an advantage when it comes to raw streaming throughput. Hint: cache and data flow behavior is as, if not more, important as utilizing vectorization in such architectures.

ASCII render shader

ASCII render shader

Acerola created a graphics to text shader. He talks about a number of interesting techniques beyond just ASCII lookups such as: edge detection, depth color falloff, blooming and tone mapping, color tones, color quantization, and other filters, etc.
Definitely worth a watch and you can check out a good amount of his code on his github repro.

Blue-screen Windows on purpose

Blue-screen Windows on purpose

I wrote awhile back on how to crash Linux/cause a Linux kernel panic in order to test how your program can handle a crash – but can you cause a Windows blue-screen programmatically?

Raymond Chen of the New Old Thing describes a variety of methods to crash Windows purposefully. He also cautions against ad-hoc methods like killing winlogin.

Methods you can use to cause a Windows Blue-screen:

  1. Windows allows you to configure a specific keyboard combination to cause a crash. You set some registry keys and then can crash a system by holding right CTRL then pressing scroll lock key twice. You can also customize the key sequence via registering custom keyboard scan codes. If you have a kernel debugger attached it will trigger the kernel debugger after the crash dump is written.
  2. The best way to trigger an artificial kernel crash is to use NotMyFault, which is part of the Microsoft Windows SysInternals tools.
Demo scenes are not dead

Demo scenes are not dead

Massive in the 90’s, Demoscenes are not dead. Revision 2024 demo party just took place March 29th to April 1st in Saarbrücken Germany.

There was music, seminars, videos, livestreams, a 5k run, and of course – amazing code demos. This included some competing 256-byte demos here. One of the best was a post-apocalyptic black-and-white city created with just 256 bytes of Gopher code running on DOS.

Admitting your mistakes

Admitting your mistakes

Speaking at QCon back in 2009, Tony Hoare admitted to probably one of the biggest mistakes of his career – one that every programmer knows all too well. The invention of NULL because ‘it was so easy to implement’.

I call it my billion-dollar mistake. It was the invention of the null reference in 1965.

At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.

Reading 50 year old rope core memory

Reading 50 year old rope core memory

Mike Steward decided to recover the original Apollo guidance computer programs that landed man on the Moon in the 1960’s. Unfortunately some of them seem to have been lost to history.

It turns out, chunks of the original hardware still exist – such as the rope core memory which contained the programs. The next question is, how do you read these programs off 50 year old rope core memory hardware? This video below tells you how he did it!

He even wrote a web app that simulates how core memory works. We do a decent job recording history’s events, but I think it’s extremely cool that this kind of historical technical information is not being lost to the ages.

You can also check out the many other videos about the Apollo guidance computer in the other parts of his videos – or a previous article which has a super-awesome description of how Apollo computers work by Robert Wills.

Perfect code vs perfect products

Perfect code vs perfect products

For one-shot things like games – focus on the experience above all else.

Update 2024/01: More proof that technical limits have little impact for making great games. Slay the Spire’s graphical glitches were there because the author only had two $70 monitors that were so bad he literally didn’t see the issues.