An Outside Perspective on the PSN Fiasco

I asked a non-technical friend of mine, who has been unable to play online with his PS3 recently due to the PSN outage, what he thought about practically all of his personal information being compromised due to an intrusion and questionable security. His perspective is not what I was expecting.

I'm just saying, they've been the target of hackers already, it just takes a couple members of Anonymous doing their own thing to get back in I imagine. If a hacker wants something, they usually wind up getting it somehow or other unless it's tucked in the Pentagon or some shit, or so it seems anymore. The 3DS was built to be unhackable and someone broke it in 48 hours. Nothing about any console maker told me they're the best bastions of defense. So no, it doesn't concern me one damn bit, because I've never considered anything I've ever had secure in the first place.

I have no idea what proper security is because I have no idea how that happens. I kinda cross my fingers that paypal isn't absolute shit. It's just not a good thing to put high hopes in when every console manufacturer has been trying to prevent hacking and piracy since such things became even remotely a problem, and have never succeeded. Thus, why expect any better from their servers. It's also worth noting I live in a very old-fashioned part of the country, not like OLD SOUTH or anything, but enough so that nobody here has faith in security online, at all, and a lot of people still won't order anything online because they don't trust the sites to protect their information or not just outright steal it for themselves.

It makes it so when things like this happen, I don't go having a little hissy over it and scolding Sony, boo hoo. Anonymous hacked the same network and a week later this happened. Nobody should be surprised, not this much, anyway. There wasn't even much time to address the issue without it going down like this anyway, seeing as now they've taken down everything to rebuild the whole mess because it's becoming a problem, obviously, but Sony fanboys will whine their brains out if the server is down at all, and Microsoft fanboys will continue to gloat that Live is better and use it as a sort of facial shit-rub. There is a lot of stigma against taking the network down, for any reason, due to the competition and entitlement of their fanbase and others, but honestly I'd have preferred this be the result after the Anonymous attack, even if everyone would've just bitched then too.

So there, I'm not the happiest with this, but I'm not freaking out or anything, because it doesn't surprise me one bit, it's just inconvinient for Portal and... well, the guy I wanted to play that with isn't getting it anytime soon so co-op's going to be me being an idiot with someone who's done it 90 times by the time I get it working no matter what, so it kinda sucks anyway.

-Sam Boyd

Naturally, he carries some misconceptions. Anonymous did not hack the network, it took it down with a DDoS attack. But, he didn't even panic then even though he assumed it had been hacked and his credentials potentially stolen. He never panicked during any of this because he has never had any reason to believe that anything he is using is secure, although he hopes that PayPal has good enough security to keep him reasonably protected.

I see people in Hacker News lashing out at the video game fanboys as being clueless and only caring about being able to play their games, but the truth of the matter is that, in the perspective of a consumer, online security just flat out sucks. Its rarely implemented properly and even when it is it often fails eventually at some point, which of course everyone hears about. Sony happens to really suck at security, but its just another hacking incident to most of the PSN users. They simply never assumed that the network was secure in the first place. Even if they wanted to switch to say, Xbox Live, they can't, because Sony has a monopoly on the games offered on the PS3. The fact that Sony still has a very large chunk of the market isn't necessarily because consumers are stupid (although some of them clearly are), but because it has a monopoly on game selection. You can teach someone about why good security is important, but it won't matter until they have an alternative platform on which to play their games.

So the real problem here is that, from an economic perspective, games should not be limited to a single console, because it creates a monopoly and prevents proper competition. If you want to blame something for this, blame the monopoly, not the customers. The real lesson here is not that Sony is terrible at security, but that we have allowed a dangerous monopoly to form. In a proper competitive environment, Sony would lose an absurd chunk of its customers after an incident like this. You can complain that the company is evil and the customers are stupid, but at the end of the day, its just economics.

Console vs PC War Makes No Sense

I'm a software engineer. Specifically, my specialty is writing all the code that makes games work. Every time I see someone say "I'm a console gamer" or "I'm a PC gamer" I want to punch them in the face.

THERE IS NO DIFFERENCE BETWEEN A CONSOLE AND A PC.

Let me explain why in cold, hard facts. From a development perspective, consoles are unique from PCs in that they usually have specialized controllers, and all the hardware is perfectly consistent between players, and they usually have fairly powerful hardware specifically designed to benefit games. When one is developing for a PC, on the other hand, you have to account for a keyboard, mouse, joystick, multiple USB controllers, 10 year old graphics hardware, graphics hardware that hasn't even come out yet, the internet, multiple CPU architectures, 3 versions of directX, plus openGL, and at least 3 different operating systems.

The simple fact is that, from a purely developmental perspective, a PROPERLY DESIGNED ENGINE can treat a console as simply another platform, with its own operating system, CPU architecture, and graphics API, since a proper engine will need to be able to account for multiple OSes, architectures, and APIs in a normal PC market anyway. Not only that, but unless you are a mentally retarded programmer, it should be cake to put in architecture specific optimizations for each console, even ones with significant pipeline differences.

A lot of programmers, for some reason, don't think this is possible. I think that's hilarious. Let's take a PS3 Cell Processor versus a Pentium 4 versus an i7 quad-core. Since modern consumer PCs can reach up to 12 separate logical cores, if your modern graphics engine doesn't have a job queue for parallelized tasks, you are an idiot. Furthermore, since a job queue can utilize functors and accept pretty just any generic function if properly done, its interface can be totally abstracted out of the engine. Consequently, on a pentium 4, the job queue can probably just be configured to immediately process everything on a single thread, or whatever is appropriate. Then, for the Cell and quad-cores, its just a matter how many cores are available. Since the data structure is completely abstract, not only can you optimize for the core-count, but you can optimize down to assembly-level code for optimal performance for both the PS3 cell processor and the quadcore. This holds even if they have vastly different resource requirements, because your data structure should be aware of those limitations anyway. The most you'll have to do is tweak your effects to balance the load on each platform, which you should be doing anyway. Hence, a single engine can support all consoles and PC platforms with little, if any performance loss. As an extension of this, the next time I hear derogatory comments on the line of "its just a PC port" or "its just a console port" I'm going to murder a kitten, because that's just lazy programming, god fucking damn it.

So, technically speaking, a console is just a pre-configured, standardized PC. Consequently anyone who says consoles have better hardware is being a complete ass-backwards moron. However, some people seem to think that certain pre-configured PCs are better then other pre-configured PCs. The only valid argument here is one that compared the economic cost of each individual component, which rarely happens. Instead they usually get into fighting matches about game selection, online components, and comparing graphics hardware power, which to me seems only slightly less childish then comparing penis sizes.

First, as I have just explained, any properly programmed PC game should be able to run on just about any console, no matter what, or they are lazy programmers. None of this has anything to do with the console itself, and everything to do with either bad programmers or braindead middle management. So if you guys want to be like "MY MIDDLE MANAGEMENT IS BETTER THEN YOUR MIDDLE MANAGEMENT" then, um, you do that. The online component is even dumber, because it really comes down to, where are your friends? If you value an online component, its because it lets you play with your friends. If none of your friends have a PS3, then its online component is going to suck total balls no matter how awesome everyone says it is. Criticizing someone for getting a console because they're friends have it so they can play online together is like telling someone they're stupid because they bought the same game their friends did so they can play together.

What's really funny is that you can actually argue that a console's unique control system, like the Wii, or the Kinect, could have a significant impact on a game since it would have to structure its gameplay based on a controller that is, for the most part, not widely available on PCs (although both of those controllers can and will work with a PC). The irony here is that both of these systems get trash-talked by the hardcore gamers as being even less hardcore then a normal controller! So the only valid argument for consoles is being used by hardcore console gamers to deride casual players, which is just comical.

The only other thing I can fathom these gamers arguing over is that console gamers are more hardcore then PC gamers.

This is what I hear: "I'm a better person then you because I spend more money on games!"

Wow. Lets just all start persecuting each other over our religions now, because why the fuck not, it seems those insane gamers have all but done this already. Seriously, if I, as a game developer, make a game for a PC, the only reason its not going to end up on a console is because the distributors are being assholes, and that does not give anyone a right to say that its not a game for "hardcore" gamers simply because some fucker with a business suit decided it would threaten their moneymaking monopoly.

So, if you ever do say that, I will find you.

Future Predictions

In the past I've made several predictions that were dismissed, at the time, as ludicrous, but have in fact come to fruition, like the importance of having dynamic environments in games and graphics engines that can handle it. So, here I present a complete list of all the computer-related or economic predictions I currently have, along with justification:

Speed becomes paramount to all mature markets: People have been ignoring speed for as long as they can, because its apparently rather difficult for programmers to properly optimize programs. This is fine in emerging markets because no one knows how fast things can go. However, the more mature a market gets, the faster the consumer will notice speed problems - even little ones. People are really impatient, and a program that successfully combines both ease of use and extremely fast calculations will win over a bloated, slow, feature-filled one. This has become markedly apparent in the current cycle of web applications, and will soon spill over into just about everything that we use.

Arguments against this usually say that a faster processor will make slow programs go away, and that algorithms are the only things that make significant speed differences. There are a lot of technical reasons I could go into concerning why this is wrong, but there's a much easier argument: Why have my programs gotten slower over the years as my processor speed has increased? Because programmers are getting too lazy. In fact, most of the speed increases over the years have been due to algorithmic optimizations, and yet... programs are still slow. The amount of speed you can now gain over properly building an architecture and optimizing your program is so incredibly large that it is noticeable even for comparatively large computational tasks, and hence represents an economic benefit that has yet to be exploited. It's a little more complicated then simply making fast programs, however, involving a combination of user friendliness, speed, and avoiding feature bloat. The myth that speed doesn't matter in programming, however, is about to start costing companies serious money if they continue to believe it.

Rasterization won't get replaced by ray-tracing: Or rather, it won't get replaced any time soon. There are a lot of incredibly annoying computational issues with raytracing, and a lot of them can actually be solved by combining both techniques. As a result, what will happen is a slow evolution, where ray-tracing will slowly work its way into rasterization pipelines, likely starting with variable density volumetric entities, until it eventually replaces rasterization altogether once we have more computational power then we know what to do with. This probably won't happen for another 20 years, though.

A lot of people argue that we can do impressive amounts of raytracing even with modern computing power, and that the increased parallelism in CPUs 20 years from now will result in feasible realtime raytracing engines that can compete with modern rasterization very well. There are two problems with this: The first is that they are ignoring the fact that rasterization itself also benefits from parallelism, and as such it's rendering quality will increase as computing power does. This usually leads into the second mistake: people argue that rasterization will simply hit a ceiling and be unable to get past it, and only raytracing can produce true photorealism. These people completely fail to understand just how much stuff can be efficiently accomplished using rasterization, and also do not understand how raytracing can be combined with rasterization to achieve almost the same amount of realism for a tiny fraction of the computing cost. Other people just don't understand how computationally expensive the tiny nuances of photorealism are.

Low-level languages will become even more important: Lots of people want low-level languages to vanish, but due to the above speed concerns, that simply isn't going to happen. However, business moves too fast for people to worry about low-level routines all the time, so what will happen is an increasing chasm between high speed low-level languages that are dependent on high-level languages to do complex tasks, while the high-level languages will be increasingly dependent on low-level libraries in order to deliver effective performance. Hence, language interoperability becomes incredibly important, because the programs of the future will likely be written in 2 or more languages. The ability to simply pick a language as a tool, choosing it based on what problem needs to be solved, will become invaluable. This is likely to happen very quickly, in just 5 or 10 years. At the same time, this increasingly wide division between high level and low level languages will create a vacuum that needs to be filled by...

Middle-level languages: A middle-level language will be a language that allows a programmer to quickly and efficiently write a method either in the style of low-level memory management, or high-level complexity management. This would likely be accomplished with something like D, where the programmer would be able to control and override the high-level garbage collectors and variable management whenever they desire, with little to no resistance from the language syntax. While many high-level languages today attempt to make some low-level functions available, it is often clumsy and far from complete. This language would act as an intermediate compromise between the necessary low level speed hogs and high level complexity management. This transition, however, is not going to happen for probably another 10 or 20 years, due to people needing to recognize that there is a schism in the first place, along with several engineering problems that must be confronted.

Education will soon fundamentally change: We've been using the same, outdated rote methods of teaching for almost 150 years, slapping on in-place attempts at more modern learning, trying to work such fundamentally incompatible methods into the existing framework that refuses to change. It is becoming so economically irrational for people to continue being schooled this way that the instant an alternative comes up, it will rapidly displace the existing system. This is already happening at a small level with Khan Academy, which I believe is precipitating a fundamental change in how we learn things. We aren't there yet and we probably won't be for say, 2-3 decades, but around that time we will see a huge shift in the educational paradigm.

Anti-authoritarianism becomes rampant: This one probably won't happen for a good 50 years, but the inklings of its beginnings have already shown up, primarily in Anonymous and the multiple middle-east government coups. Anonymous will end up being one of the most important social movements in modern history, as it matures from a group of pranksters into something that unites a large portion of humanity together. Governments will be forced to become more transparent and accountable, and debates about the effectiveness of representative democracy will rage in internet forums or whatever the future equivalent is. Part of this change will likely be influenced by a changing educational system that becomes much more effective at promoting critical thinking and individualistic problem solving skills. Extreme anti-authoritarianism, including anarchy, will become far more vocal and possibly less ignored by the public, but by necessity will remain fringe groups.

The economy will become both more capitalistic and more socialist: This is not a contradiction. The huge disparity between the wealthy and the poor is reaching such an absurd level in the United States that it has created an economic disparity that can be taken advantage of. At the same time, the most successful companies are already beginning to realize that increasing competition and other capitalistic values inside their own corporations results in far more productivity and efficiency (just look at what Larry Page is doing at Google). That means that capitalistic values will become more pronounced at smaller and smaller economic tiers, while the economy at large takes on a more socialistic approach to even out the wealth distribution. I have no idea when this will happen, because it is dependent on the two arguing political parties in the united states to realize that they both want the same wealth distribution. They just have to stop arguing and come to a compromise to try and do something about it.

...

So there you have it, my predictions for the future. Some of them might be right, others might not, others might be influenced by me planning to directly instigate them, but hopefully this was an interesting read nonetheless.

Investigating Low-level CPU Performance

While reconstructing my threaded Red-Black tree data structure, I naturally assumed that due to invalid branch predictions costing significant amounts of performance, by eliminating branching in low-level data structures, one can significant enhance the performance of your application. I did some profiling and was stunned to discover that my new, optimized Red Black tree was... SLOWER then the old one! This can't be right, I eliminated several branches and streamlined the whole thing, how can it be SLOWER?! I tested again, and again, and again, but the results were clear - even with fluctuations of up to 5% in the results, the average speed for my new tree was roughly 7.5% larger then my old one (the following numbers are the average of 5 tests).

Old: 626699 ticks
New: 674000 ticks

//Old
c = C(key, y->_key);
if(c==0) return y;
if(c<0) y=y->_left;
else y=y->_right;

//New
if(!(c=C(key,y->_key)))
return y;
else
y=y->_children[(++c)>>1];

Now, those of you familiar with CPU branching and other low-level optimizations might point out that the compiler may have optimized the old code path more effectively, leaving the new code path with extra instructions due to the extra increment and bitshift operations. Wrong. Both code paths have the exact same number of instructions. Furthermore, there are only FOUR instructions that are different between the two implementations (highlighted in red below).

New 00F72DE5 mov esi,dword ptr [esp+38h] 00F72DE9 mov eax,dword ptr 00F72DEE cmp esi,eax 00F72DF0 je main+315h (0F72E25h) 00F72DF2 mov edx,dword ptr [esp+ebx*4+4ECh] 00F72DF9 lea esp,[esp] 00F72E00 mov edi,dword ptr [esi+4] 00F72E03 cmp edx,edi 00F72E05 jge main+2FCh (0F72E0Ch) 00F72E07 or ecx,0FFFFFFFFh 00F72E0A jmp main+303h (0F72E13h) 00F72E0C xor ecx,ecx 00F72E0E cmp edx,edi 00F72E10 setne cl 00F72E13 movsx ecx,cl 00F72E16 test ecx,ecx 00F72E18 je main+317h (0F72E27h) 00F72E1A inc ecx 00F72E1B sar ecx,1 00F72E1D mov esi,dword ptr [esi+ecx*4+18h] 00F72E21 cmp esi,eax 00F72E23 jne main+2F0h (0F72E00h) 00F72E25 xor esi,esi 00F72E27 mov eax,dword ptr [esi] 00F72E29 add dword ptr [esp+1Ch],eax

Old 00F32DF0 mov edi,dword ptr [esp+38h] 00F32DF4 mov ebx,dword ptr 00F32DFA cmp edi,ebx 00F32DFC je main+31Dh (0F32E2Dh) 00F32DFE mov edx,dword ptr [esp+eax*4+4ECh] 00F32E05 mov esi,dword ptr [edi+4] 00F32E08 cmp edx,esi 00F32E0A jge main+301h (0F32E11h) 00F32E0C or ecx,0FFFFFFFFh 00F32E0F jmp main+308h (0F32E18h) 00F32E11 xor ecx,ecx 00F32E13 cmp edx,esi 00F32E15 setne cl 00F32E18 movsx ecx,cl 00F32E1B test ecx,ecx 00F32E1D je main+31Fh (0F32E2Fh) 00F32E1F jns main+316h (0F32E26h) 00F32E21 mov edi,dword ptr [edi+18h] 00F32E24 jmp main+319h (0F32E29h) 00F32E26 mov edi,dword ptr [edi+1Ch] 00F32E29 cmp edi,ebx 00F32E2B jne main+2F5h (0F32E05h) 00F32E2D xor edi,edi 00F32E2F mov ecx,dword ptr [edi] 00F32E31 add dword ptr [esp+1Ch],ecx

I have no real explanation for this behavior, but I do have a hypothesis: The important instruction is the extra LEA in my new method that appears to be before the branch itself. As a result, it may be possible for the CPU to be doing branch prediction in such a way it shaves off one instruction, which gives it a significant advantage. It may also be that the branching is just faster then my increment and bitshift, although I find this highly unlikely. At this point I was wondering if anything I knew about optimization held any meaning in the real world, or if everything was just a lot of guesswork and profiling because what the fuck?! However, it then occurred to me that there was an optimization possible for the old version - Move the if(c==0) statement to the bottom so the CPU does the (c<0) and (c>0) comparisons first, since the c==0 comparison only happens once in the traversal. Naturally I was a bit skeptical of this having any effect on the assembly-rewriting, branch-predicting, impulsive teenage bitch that my CPU was at this point, but I tried it anyway.

It worked. There was a small but noticeable improvement in running time by using the old technique and rewriting the if statements as such:

c = C(key, y->_key);
if (c < 0) y = y->_left;
else if(c > 0) y = y->_right;
else return y;

Optimized: 610161.8 Ticks

The total performance improvement over my failed optimization attempt and my more successful branch-manipulation technique is a whopping 63838.2 Ticks, or a ~10% improvement in speed, caused by simply rearranging 4 or 5 instructions. These tests were done on a randomized collection of 500000 integers, so that means the optimized version can pack in 10% more comparisons in the same period of time as the bad optimization. That's 550000 vs 500000 elements, which seems to suggest that delicate optimization, even in modern CPUs, can have significant speed improvements. Those of you who say that toying around with low level code can't infer significant performance increases should probably reconsider exactly what you're claiming. This wouldn't directly translate to 50000 extra players on your server, but a 10% increase in speed isn't statistically insignificant.

Language Paradigm Wars Suck

In the time since I first looked at a VB6 book, to now, I have heard a lot of things about programming. I have heard people say that programmers should never need to know what a pointer is. I have heard people say that there is never any reason to code in assembly. I've had someone tell me that coding in C++ is the worst mistake I will ever make, and that the only language you should ever use is C. Someone else told me that programming in C was for idiots and you can do anything you want in C#. I've seen other people say functional programming is more pure then anything else. I've had object-oriented concepts shoved down my throat since high school, and people constantly tell me that you should never use "protected" or friend functions, let alone have a function or variable outside of a class.

These people are all wrong.

A programming paradigm, just like a language, is a tool. You can't take a hammer out of your toolbox and expect it to efficiently cut down a tree. At the same time, you can't say the saw you invented to cut down the tree is going to be very good at nailing a board to the wall.

People who insist C exists only because of inertia are arguing that the hammer exists only because of inertia and that you should use a saw to nail your board to the wall instead. In a similar manner, people who insist that functional programming isn't good for anything in the real world are trying to cut down a tree with a hammer.

A paradigm is a tool. The next programmer who tells me I should do [x] instead of what I'm using for no reason other then what I'm using "sucks", "is outdated", "doesn't work" or any other totally nonspecific reason without ever looking at what I'm actually fucking doing with it is going to get a boot to the head.