And yet…I do.

I haven’t been doing any challenges on HackerRank in a while due to lack of free time. But I still login from time to time when I get an email alert about new comments in the challenge discussions. When I logged in tonight I discovered that one Shehan Jayalath had taken my B8 solution from Saving Humanity (By Vectorizing The ALU), stripped the header, and posted it in the challenge discussion as if it was his own. Sure enough, when I looked him up on the Leaderboard he had also submitted my solution verbatim to get a free 100 points.

And companies wonder why they struggle to find programmers who can actually program.

Shehan Jayalath’s post to the discussion forum can be found here. My reply can be found here. And if you’re logged into HackerRank you can see that Jayalath used my solution for free points here.

Now, I’m not naive. I am aware that plenty of people copy/paste their way to points and awards on HackerRank. (If you’re a prospective employer looking at anything from HackerRank on a candidate’s resume, you should be aware of this too.) And I knew when I made my blog post that the solutions would be copy/pasted into HackerRank for free points. Some people go there to learn, some people go there to build fake points and awards. It is what it is.

But if you’re going to post another person’s solution in the Discussion tab, have the decency to attribute it to them.

And if you’re reading anything I have to say about HackerRank challenges I hope you have the self respect to use my posts and code in order to learn and not to cheat. If you like my approach, try re-writing it yourself without having mine open as a reference. See what you can improve. Earn the points. Don’t just copy/paste.

And do not ever publicly claim anyone else’s work as your own, on HackerRank or any where else.

Oh!! Mankind is in trouble again. This time, it’s a deadly disease spreading at a rate never seen before. The need of the hour is to set up efficient virus detectors. You are the lead at Central Hospital and you need to find a fast and reliable way to detect the footprints of the virus DNA in that of the patient.

The HackerRank challenge Save Humanity can be summarized as follows:

• You are given two strings of lowercase letters a-z. We’ll call them dnaP and dnaV.
• You have to return the starting index (0-based) of every occurrence of dnaV in dnaP.
• dnaV matches a substring in dnaP if all characters match, or if all characters but one match.

This challenge is ranked as expert with a 100 point award. As of the day this post was published only 12.94% of submissions have succeeded, and the Discussion tab is filled with the laments of those who timeout on the most difficult test files.

I coded a solution in less than 15 minutes. (Cue the anger and wrath of anyone who is stuck on this challenge.)

To be fair, I did not initially code an optimal solution. I guessed when I read the challenge that an optimal solution would involve something like a z-algorithm, a suffix array, or some form of tree. But I had a hunch there was an easier way to get 100 points.

First Draft

With this class of challenge it’s a sure bet that a brute force solution will timeout. Since the brute force approach is trivial to code I went ahead and tried it to verify that I wasn’t missing anything about the problem, and so that I could use my hackos to purchase test files.

It timed out on 5 of the test files but succeeded on the others. I bought the files, ran some tests on my MBP, and confirmed my hunch.

Go Big or Go Home, Brutus

The obvious brute force solution is to compare each character in dnaV to each character in dnaP and stop if there’s more than one mismatch. This of course has to be done repeatedly starting at each character index in dnaP. It’s the repeat comparisons that drive the processing time up, and an optimal solution would find a way to eliminate as many repeat comparisons as possible.

But there’s another problem with the brute force solution: it’s comparing one character at a time on a 64-bit processor which can compare 8 characters at a time using the ALU. Situations like this are why I freaking love C. I took my solution and modified it as follows:

• Cast the char pointers dnaP and dnaV to long long pointers.
• Compare the character arrays as arrays of long long, essentially vectorizing the ALU.
• If there’s a mismatch, drop down into a loop which examines the 8 characters at that position to count the mismatches.

In C these were trivial modifications to make and they brought the worst time down to 1.17s for test file 7, passing the challenge with time to spare. We’ll call this the B8 solution (brute force 8-byte compares) and the original solution B1 (brute force 1-byte compares).

Having solved the challenge I wanted to explore the solution further to see if I could make it faster than the editorial solution on the longer test files (3-9).

Saving Humanity with the Vector Processor

The obvious next step in improving the brute force approach is to compare more than 8 bytes per iteration. SSE2 has instructions which can compare 16 bytes at a time. Initially I tried to both compare the values and get a count of mismatches all using SSE2 instructions. However, this proved to be slower than simply performing the compare and counting the mismatches normally if the SSE2 result indicated any mismatches at all. The B16 solution is therefore the same as the B8 solution, it just compares 16-bytes at a time.

Test file 7 is again the worst case and the B16 solution is able to process it in 0.68 seconds. That’s roughly 1.7x faster than using the ALU.

Later extensions to x86-64 vector processing added support for 256-bit operations (AVX2) and 512-bit operations (AVX-512). Unfortunately my MBP processor does not support AVX-512. It does support AVX2, but using 256-bit loads and compares slowed down all test files except 8 and 9, which saw a very slight performance gain. I suspect this has something to do with the algorithm’s inherent lack of alignment on 32-byte boundaries.

Beating the Editorial Solution

I won’t go into detail on the editorial solution here since HackerRank hides the editorial until you either get your points or forfeit those points in order to see the solution. Suffice it to say that the editorial solution involves the use of a suffix array.

The editorial solution is 3-4x faster than the B16 solution on files 3-7. But on test files 8 and 9 B16 is nearly 21x faster. Even brute force using single byte compares is faster than the editorial here by a factor of 3x. What’s going on?

Test files 3-7 involve very long repetitions of the letter ‘a’ with a few other characters interspersed in the text to form a pattern. Test files 8 and 9 involve long repetitions of the alphabet with a few other characters interspersed. The brute force solutions have to repeatedly compare a large percentage of the bytes in test files 3-7. But on test files 8 and 9, 25 out of every 26 comparisons end on the 2nd byte being compared. Here the brute force solutions aren’t comparing nearly as many bytes as the editorial solution which has to sort the suffix array for it to be useful.

To deal with the high character repetition in some of the test files I made the following modifications to the B16 solution. We’ll call this version B16R.

• Allocate an array of integers for both dnaP and dnaV.
• Scan the strings from end to beginning counting repeat characters and storing the counts in the arrays.
• Now at any given character position we can look at the corresponding integer arrays and see how many times the character will repeat in both dnaP and dnaV.
• The string matching loop can use this information to jump ahead any time it finds a suitable repetition.

Mission Accomplished

All tests: MacBook Pro Retina 15-inch Mid 2015 • 2.8 GHz i7 • Xcode 10B61 • Max Optimization • Loop Unrolling

B16R is roughly 3-5x faster than the editorial solution on files 3-7, and each of the test files completes in under 1/10th of a second. None of the long test files complete in under 1/10 of a second with the editorial solution, and two of them take a half second.

These changes did double the run times on test files 8 and 9. If this were a real world scenario with larger data sets it would be worth keeping track of repetition frequency while building the array for dnaV. At that point the code could decide whether or not to bother looking for repetitions in the search.

Is There An Even Better Way?

String matching is a well researched area of computer science. This web site lists the major algorithms along with their strengths, weaknesses, and sample implementations in C. Most programmers will never need to implement one of these algorithms and will simply rely on library calls whenever they need to search a haystack for a needle of text. It’s still educational to look over the various approaches to a common problem and to understand how each one tried to improve performance.

Time permitting I hope to explore a few of these algorithms, and how well they handle this particular challenge, in a later blog post.

Source Files

• Solution B1
• Solution B8
• Solution B16
• Solution B16R

But sometimes…sometimes it can be very rewarding.

The Challenge

The ACM ICPC Team challenge starts off with two numbers. N is the number of people at a conference, and M is the number of topics that the people can know about. The input then consists of N strings with M characters in each string. Each character is a 0 or a 1. The idea is that there’s a line for each person and a character position for each topic. 1 means the person is well versed in the topic, and 0 means they are not. The goal is to find the maximum number of topics any two person team is well versed in, and the count of teams that hit the max.

When I read the challenge my mind ran straight to a specific solution, and I never even considered another approach. After I submitted my solution and got the points I read both the editorial and the discussion. And I was rather surprised at what I found.

You Can Do Better Than O(n^3)

The editorial states that this is a brute force problem with O(n^3) complexity. The C++ code example uses three nested loops to compare every character of every pair of strings, each string stored in a vector.

The PHP example takes advantage of the fact that you can bitwise OR two strings to eliminate a loop. But internally there’s still a character by character operation to produce a new string, followed by another character comparison of the result to count the 1’s. So this solution merely hides the O(n^3) complexity behind language functions.

And finally the Python example converts the strings to integers and does a bitwise OR, but then converts the result back to a string to count the 1’s. The Python code actually touches on an important point, but the potential speed gain gets lost in Python itself.

Surprised by the inefficiency of these solutions I clicked over to the discussions tab.

Nobody Saw It?

I skimmed the comments going back two years. Aside from the normal “why doesn’t my code work?” posts, there were numerous complaints about timeouts. And numerous code postings that squeaked in under the finish line, but took similar approaches to the editorial: O(n^3) value comparisons or counting 1’s in a string which was the result of a bitwise OR.

There were a handful of more creative approaches involving Java’s BitSet (slow) or a 2D array of integers (not bad, but still).

Right before giving up on loading more comments I came across another C solution which was comparable to mine in its approach and speed. But for all the interest expressed in the discussion about faster ways to solve the puzzle, nobody paid much attention to the post or the reason why it was insanely fast.

I was shocked by this point because when I wrote my solution I didn’t think of it as being unique or special. I assumed the editorial samples would include a similar approach, along with many of the user submissions.

Let The CPU Do Its Job

The challenge input is simply a collection of bits represented as human readable characters in the 8-bit ASCII set. Yet almost no one reduced the data to a form that naturally fits the CPU.

The help section mentioned bitwise OR as did people in the discussion trying to help those with code that was timing out. But the majority were using bitwise OR on the individual ASCII characters from the string. In some cases literally, one character pair at a time. Others applied bitwise OR to multiple characters in a single operation, but they were still using 8-bits in memory to represent a single bit of the problem.

By analogy, if you compare two topic characters from the string at a time you are only using 1 lane of a 64 lane highway. If you bitwise OR 8 of the topic characters at a time you’re doing better, but still only using 8 lanes of a 64 lane highway.

The solution I wrote?

• calloc a properly sized block of memory based on the inputs.
• Use strtoul to convert the base 2 strings, in chunks determined by sizeof, to unsigned long ints placed into the memory block. Each 0 and 1 character becomes a single bit in memory. On 64-bit CPUs unsigned longs are 8 bytes and can store 64 topic flags.
• Loop through the two person teams in O(n^2).

The key differences?

• The CPU is performing bitwise OR operations at its natural word size on a data structure with no waste. For a 64-bit system that means the topics of a two person team are merged with a single instruction for every 64 topics. It also means the code which replaces the innermost loop in the brute force approach performs with a fraction of the loop overhead.
• The data describing each person’s topics is compressed by a factor of 8 meaning the CPU has less data to move and less chance of a cache miss.
• With a fairly simple algorithm you can reduce the act of counting the bits to a handful of instructions for the CPU. And in Xcode at least, __builtin_popcountl implements an even faster algorithm for you.

The end result? On test case 7 with 500 people and 500 topics the editorial Python solution took 0.881728 seconds, as tested on my MacBook Pro. The editorial C++ solution took 0.401785 with the same Xcode compiler settings as my solution.

My solution? 0.002911 seconds. 138x faster than the C++ sample. And 303x faster than the Python sample.

Sometimes it pays to be close to the machine.