Back in my high school days, i was into distributed computing. It was the era when computers pretty much consumed the same amount of power even if they were idle. I’ve chosen to dedicate my CPU cycles to SETI@home (yeah i was a big fan of Contact). First through the dedicated installer, later through BOINC. My contribution was pretty average but around 2007 i’ve noticed that some users spiked and started to produce pretty awesome numbers.

It was the year when NVIDIA launched their first CUDA enabled GPU which meant that you could use your card for more than gaming. The CPU is a general purpose processing unit and i’ts really good at doing anything. As you know when you are good at a lot of things you cannot be great at anything. The GPU on the other hand does the same type of mathematical computations over and over again. Practically each pixel in a game is rendered in the same way. So in short the GPU is optimized architecturally to carry out a lot of parallel tasks.

In my Mandelbrot set generator last time you saw that we do the same mathematical calculations for each pixel in the image. Since you know i love performance optimizations, let’s try to use CUDA to offload these intensive computations onto our GPU.

I like to write puzzle solvers, they refreshes my thinking. You probably learned in your algorithm classes that in these cases you can resort to backtracking. While backtracking is surely a solution in many theoretical cases, it can rarely be utilized in real life applications since the performance impact is huge.

Sudoku is one of those kind of puzzles which seem trivial to solve with a backtracking but lets think about it. There are 81 positions, each position can have 9 different values, generating through the space of potential solutions and validating each and every step could take ages.

Let’s instead of backtracking, track the possible values that each cell can have. This is how humans solve it and it will bring us very far in the solution. Here are the data structures i propose.

I am fascinated about the Mandelbrot set, since I first saw a video about it at my university. It is so elegant, so beautiful but the cherry on the cake it is that it’s infinitely complex. Throughout my years I implemented the rendering many times. Every time somebody says Math is boring, I flip out my phone to prove them wrong with some images. You can read a lot more about it here.

In WPF there are three main ways to do rendering.

1. Control composition: You assemble your hierarchy of UI elements (from XAML or code) and you let the engine take care of layouting and rendering for you. Great if you want a lot of user interaction.
2. Drawing Context:  You use primitives like Lines, Rectangles, Pens and Brushes and you do most of the positioning yourself. It is the basically the GDI rendering from WinForms and involves overriding the OnPaint() method. Great choice when you want to create from scratch a control like a chart.
3. Image generation: You define the color of each pixel on a surface. This is how game engines do rendering. Great choice when you want to create Heat Maps or Image manipulation

I created a simple WPF application that renders the Mandelbrot Set into a WriteableBitmap.

A few days ago a dear friend of mine asked me to take a look at their website. According to them the guy who was administrating it didn’t had much security knowledge so they got hacked. I needed to assess the damage and tell them if it can be recovered or not. My first thought was that “great another university student after which I need to clean up shit” but the story got really interesting for me. The site was hosted on WordPress, exactly like my blog. I instantly got interested since I had the impression that there is not much you can fuck up in it. I’m new to WordPress so my incentive was to learn how can one you end up hacked and more important how can you restore your work.

Initial assessment

I opened the page in chrome and the dev tools to check network activity. The site was loading some shady javascript in the form of <script src=’[shady source]’ type=’text/javascript’></script> and its initial load took more than 40 seconds.

Great, some hacker sprayed every page with bullshit, no wonder the site loads slowly. So it was clear we need to do some cleanup. I requested access to their admin page and after I logged in I started to look around weird stuff. The option that everybody can registered was checked and there were two users registered with shady names so I deleted them. The site wasn’t big so I pulled up my sleeves and wanted to go mopping up but even the editor was slow (40 seconds slow).

I’ve checked page revisions and it was clear when the malicious parts were added in, but I didn’t had the possibility to revert to a backup since they were editing it after the slowdown (which later you will understand why).

In part 1 we talked about how you can attach a value to a poker hand in order to compare it versus other hands. While to code there runs quite fast 2.6 mill hands in 1200 ms, we can do better.

Imagine a bit that you are writing your own poker server, which needs to execute this calculation many times a day, or that you write a poker bot which not only needs to calculate the current hand strength, but also make predictions on how your hand evolves (usually after the strength, you calculate the percentage of the hands you win now, and you also do this calculation for each upcoming phase in order to see whether your hands has a high chance to improve or worsen).

Performance as a requirement is in trade-off with storage, usually when you want to increase performance you need to sacrifice storage, or if you want to reduce the used storage you probably end up doing more CPU work.

In our poker hand evaluator we can quickly notice that the value of the hands never change and since there are only 2.6 mill of them, it will be easy to move them to the memory. We need to find a way to assign a unique value for each hand to construct a lookup table. This is called hashing. I wrote the following class.