|
My brain is built of paths and slides and ladders and lasers and I have invited all of you to enter its pavilion. My brain, as you enter, will smell of tangerines and brand-new running shoes.
  TEH EVIL PLANS! | 
Posted - 8/29/2006 12:17:22 AM | I was going to post another deep, introspective examination of my career choices, but I got on a sugar rush and started reading Microserfs and just lost the mood. So I'll do that some other day.
Instead, here's the contents of a new file on my desktop titled Evil Plans.txt:
PHOENIX EXTRACTION PLAN
=======================
- Test run, check for possible problems w/ GPU fan rig
- Reconfig network so it runs as client to Umaro
UMARO DEPLOYMENT
================
- Get mails transferred from Relm and Phoenix
- Finish setting up mail accounts
- File transfer from Phoenix
- styleXP etc. (Phoenix has serial)
- Organize Start Menu
- Organize files (esp. stuff to back up)
- DVD backups
- Take care of stupid Windows activation crap
CELES UPGRADE
=============
- Swap CPU
- More Win Activation BS?
- Move MP3 files off to Relm
ROBOT MOUSE PROJECT
===================
- Finish soldering and such
- Test it out, see if it works
- Get some desoldering braid (the Shack?)
- If not, try to replace dead parts (probably just the 2 red LEDs at this point) from Radio Shack or whatever
- If all else fails, buy a new one and build that instead
- Pictures
CUSTOM GAME CONSOLE PROJECT
===========================
- Just buy a stupid variable power supply so we can see if the LCD panel works
- Rig up power harness and signal feed w/ the canniballized ribbon
- Milestone: get a working Composite signal feeding into the panel, e.g. from the VCR or whatever (slice up a cable)
- Check into a proper connector for ribbon so we can have a REAL circuit instead of Frankenstein
- Design a power supply and build it (even if it means hacking a 12V or something)
- Milestone: get a breadboard and whatever other supplies, rig up a more permanent test bed w/ proper power supply
- Look into microcontrollers etc. and get one
- Develop something that emits a composite video signal
- Milestone: custom image displayed on test hardware
- Decide what to do next: flash storage and an OS ROM?
LEGACY GAMING MACHINE PROJECT
=============================
- Need CD drive (probably)
- Need floppy drive (consider getting two, one for Umaro w/ silver bezel, depending)
- Need hard drive
- Need sound card (can we steal the one from Phoenix?)
- Need OS
- Clean out case and PSU
- Rewire power supply so it works (switch is in the box o' parts IIRC)
- Get machine POSTing at the very least before buying parts
Mysterious.
| |
| The Big Computer Tale | |
Posted - 8/28/2006 2:50:45 AM | OK, I promised that this was coming, so here it is: the full tale of adventure, from the beginning to the end. I'm too lazy to dig up links to individual events and the corresponding entries here; if you're genuinely bored enough to care, help yourself to the archives.
It all started at some point in the past. I don't remember what point that was (didn't I just get done telling you that I'm too lazy to look it up?). Anyways, at that point, I was running an old Athlon XP 2400+ on a crippled 512 MB of RAM. I had somewhere in the neighborhood of 70GB of hard drive storage, split across two aging and creaky IDE hard drives. The only really interesting bit in the system was the gleaming GeForce4 Ti4800... which was an absolutely awesome piece of hardware, back 4 years ago when I built the machine originally.
Somewhere along the line, it struck me that my normal development habits just didn't jive with this particular piece of hardware. At that point, "normal development habits" were 1 or 2 instances of VS2003, up to half a dozen browser windows, a couple of instances of Notepad, and whatever other incidentals - IM clients, etc. etc.
The easy fix at the time was to boost up to 1GB of RAM; this had a marked and much appreciated benefit, since it eliminated an awful lot of slow, noisy hard-disk swapping. However, it didn't really solve the core problem.
Eventually, I moved up to VS2005. The average number of browers climbed a bit. It is now common for me to run 3 instances of VS at a time. I was trying to run (and debug!) a next-gen 3D game on hardware that barely scraped minimum spec for the fully-optimized retail version; clearly, the stresses of running a development environment and a very demanding, unoptimized game were just too much.
The problem is, I'm very tight-fisted. I hate spending money on things I don't absolutely need. Financial frivolity is not one of my traits. So, for quite a while, I just sucked it up and slogged along on my slow-ass machine, trying to convince myself that it wasn't really a big deal.
Then, in the vicinity of June of this year, I found the truth. (Incidentally, truth comes in a shape that bears an astounding resemblance to an Asus W2JB laptop.) The truth includes a dual-core CPU and a real, honest-to-God decent video card. I needed the truth to do some development while travelling - something that my old laptop (a Celeron 1GHz with 128MB of RAM) quite obviously just wasn't going to be able to handle.
It took roughly three seconds for me to become permanently addicted to dual-core power for development. (I'm still not really sold on it for gaming, but that's another rant altogether.) Our game is split into two projects, one that uses the C++ compiler in Visual Studio, and one that uses a proprietary compiler toolchain. Dual-core means I can do a full rebuild of the game and compile both halves simultaneously. (Or, more commonly, it means I can compile both in series on one CPU core while I faff about on the spare core...)
I returned from my travels, smitten with the beauty of dual-core, but still not entirely enlightened. You see, my first and true love was with another dual commodity - dual monitors. I felt dirty and evil, betraying my fidelity to two monitors for the illicit lust-fest of two CPU cores.
Thankfully, I eventually figured out that I was being a moronic Puritanical idiot with my technology, and embraced a more progressive view on relationships. For a time, I happily used two monitors and two CPU cores, by connecting one of my LCDs to my laptop.
That was a pretty happy arrangement, but only as a temporary fix. In fact, I'd only decided to try it in the first place because I'd already committed to building a new development PC. The sticky part was, I was going to wait for the new Conroe processors to arrive, as the word on the street was that AMD would slash processor prices once Intel's new powerhouse chips were available.
So I contented myself to wait for the fateful day of Conroe release, hobbling along on the laptop. Unfortunately, it's just not comfortable; the laptop's screen runs at 1440x900 while the second display runs at 1280x1024, leading to weird aspect ratio glitches. It also means having a laptop chew up valuable desk space which I normally use for hand-written notes and sketchings. All in all, it satisfied my baser technological thirst, but it just wasn't convenient.
Fortunately, new hardware was on the way... I was just about to order parts for a nice AM2 system and hunker down to get my discounted Athlon X2 CPU once the Conroe date passed. On a whim, I decided to check some Conroe benchmarks, just out of curiosity.
If you don't already know just how soundly the X2 line gets its ass kicked by Conroe... well, then, you probably haven't been able to make heads or tails of all the hardware gibberish I've been saying all this time, so who cares.
That was the clincher; I decided to go LGA775 instead of AM2. It would be only the second Intel machine I'd bought in over 5 years (the laptop being the first) - and the first Intel machine I ever built myself. After some fond farewells to AMD (ok, it was a rude hand gesture) I sank my teeth soundly into the bullet, and bought the parts.
Now all I had to do was wait for the CPU itself to become available.
Easier said than done, as it turns out. For whatever reason I missed the actual release of the CPU by several days - I was asleep, or drunk, or abducted by aliens, or whatever. Can't recall. Anyways, by the time I got around to finding a place to actually buy a CPU, they were already sold out. I missed another couple of release cycles, including a pretty major reshipping on August 16.
I was close to despairing of ever finding a real, live E6600 CPU for sale anywhere. I tried one store who claimed they were in stock, but they ended up being a bunch of crap heads. (See my complaints from several days ago for the lowdown on just how evil they were.) At last, I gave in and just bought an E6400 from NewEgg.
... Lo and behold, a small time later, I realized that NewEgg also had E6600's in stock. So, naturally, I bought one. For good measure, I got a cheap Athlon64 3700 to replace the 3200 in my gaming machine. The stingy-bastard half of me still isn't speaking to the techno-lust half of me for dropping all that money, but damned if the techno-lust half isn't one happy mo-- well, Samuel Jackson knows what I mean.
Anyways, the E6600 finally arrived. I don't recall when, since I live in a sort of blurry state and pay very little attention to things like days, time, time of day, or daytime. It was time to build the box.
I'd already decided that the new machine would be named Umaro (fitting the trend of FF6-themed characters). I got a nice, sleek, silver XBlade case, some OCZ RAM with silver heatsinks, hooked up my silver Saitek keyboard, and so on. It looks pretty sharp.
Assembly was pretty much boring; the only sticky moment was trying to figure out how to get the LGA775 heatsink back off of the motherboard to check on the thermal paste coverage. That was a few minutes of barely-tempered panic, until I read the manual and figured out how to release the anchor pins.
From there, it's pretty much been a breeze. I'm still installing SDKs and such, but I'm confident that compiles and edit/compile/run-game turnarounds will be even more astoundingly fast than on the laptop.
Naturally, some annoying crap with Windows activation happened. I actually had enough activations until I installed new motherboard drivers, at which point the dreaded "You changed your hardware you evil bastard" dialog appeared. Moral of the story: install all drivers, service packs, and important devices before activating Windows. So I'll have to call the nice hotline sometime and get that sorted out.
The only weak point in the machine right now is the GPU, which is a Radeon X800XL. That GPU was previously in my gaming machine, Celes; I bought a GeForce 7900GT to put in the new system, but just couldn't bring myself to leave all that awesome power untapped. Since I do all my PC gaming on Celes (because it's hooked up to my LCD projector), the only thing I'd ever really run on the 7900GT would be development stuff... and I already know the X800XL is more than capable of handling that with ease.
So now my development machine is vastly more potent, my gaming machine got a solid CPU and GPU upgrade, and I've got lots of spare parts available. My entire old dev box (Phoenix) is now awaiting decommissioning (once I get all my data off it); I've got two spare CPUs sitting around (the E6400 and the old A64 3200 from Celes); and in the process I discovered a gutted old 486 that used to serve as my router.
All in all, it's a pretty good deal. I have a spare and still decent box already built; I can build a couple more systems relatively cheaply; and if I can find a working AT power supply I'll be well on my way to getting the "old-school" gaming machine I've been wanting to build for a few years now.
And to get all that digital joy, all I have to do is go without eating for the next 438 years. Seems fair.
| |
| Saturday, August 26, 2006 |
| Ahhh, bliss! | |
Posted - 8/26/2006 4:36:15 PM | My Conroe machine is up and running.
It is a deeply beautiful thing.
| |
| Thursday, August 24, 2006 |
| Introspection in a Tidy Aluminum Can | |
Posted - 8/24/2006 4:01:10 AM | I've had an interesting phrase poking around the corners of my mind lately; I don't recall exactly when or why it decided to start making a pest of itself, but considering my sleep habits of late, that is perhaps not surprising.
The guilty phrase is "lonely profession." I can think of half a dozen different ways to interpret that: the solo macho man scaling mountains and living off the land for months at a time; a researcher studying first-hand the effects of solitary confinement; being the only monkey in the world capable of speaking Swahili. Throw those words into Google, and you'll find teachers, sports coaches, writers, artists, and people from pretty much every walk of life bemoaning the solitude and isolation of their careers.
But I'm not a teacher, a coach, a writer, artist, or Swahili-speaking monkey (or Swahili-speaking anything, for that matter) - so I can't really comment much on what those people have to say. What I do know is that my own career can be very, very effectively described by the phrase "lonely profession."
It's nearly paradoxical, in many ways; thanks to massive leaps in technology in the past decade, I am a handful of milliseconds away from any suitably connected person in the world. While a generation ago I may have penned my navel-gazing rants of lunacy into a spiral-bound notebook, today I can slather it all over the Web and let thousands of strangers read it. Heck, on a daily basis I communicate instantaneously with people on a totally different continent.
Certainly, this technological extroversion and capacity for communication provides a very powerful illusion of community. In many ways, communities do exist - even thrive - on the Internet; I actively participate in two on a daily basis (our very own GDNet, natch, and the forums over at Egosoft). There is no question, though, that these media lack something that can only really be had from face-to-face, physical interaction. I'm not edumacationed in the lore of psychology, so I have no words to really pin down what that quality is - if indeed anyone has truly pinned it down.
But I do know that I miss it.
Consider Joe Random in his Boring Day Job. Joe punches the clock, hangs out and chit-chats at the water cooler, and plots to overthrow his evil twisted manager - he's a perfectly healthy, stereotypical member of the great American workforce. Now, suppose something happens in Joe's job - maybe it's really good, maybe it really sucks. But Joe definitely wants to talk about it.
Let's say that, for whatever reason, Joe has exhausted the talking potential among his cow-orkers, and now wants to continue talking in a larger social circle. Maybe he goes home, or goes to the pub, or whatever. He finds a group of willing listeners.
Pause the stream for a second and ponder: for some very large percentage of careers out there, Joe can probably discuss his Big Event just fine. People may not have direct experience with Whatever It Is Joe Does, but they can probably relate with similar experiences from their own lives. Joe's job is something that any other random person can appreciate - maybe not perfectly, but at least to a significant degree.
So Joe talks, gets his catharsis, tosses back a couple brews, and that's that. Joe is now happy; he's either shared his grand tale of success, or bitched about his dismal lot in life, depending on whatever happened in our little hypothetical slice of Joe's hypothetical life.
For contrast, let's look at a typical programmer. Bob the Wonder Hacker has a Big Event in his job, just like Joe. Maybe he was up all night solving some fiendish bug, or maybe he accomplished some huge feat of elegance and ingenuity. Maybe his manager was just being a luddite dick. Whatever.
So Bob goes to the pub, and by random luck, he meets Joe. He listens to Joe's tale, and understands. After nodding vigorously and buying Joe a celebratory (or sympathetic) round of drinks, Bob launches into his own tale.
It takes only seconds for things to go terribly, gut-wrenchingly wrong. Bob says those all-dreaded words ("distributed client infrastructure"), and Joe's eyes glaze over. Oblivious (thanks to the brews), Bob continues on; it isn't long before he makes his second faux pas ("concurrency issue") - Joe's jaw loosens a bit and he begins to drool.
Soon, Bob has talked about multithreading and his brilliant domain-specific functional mini-language that exploits referential transparency and atomic message passing to bypass the concurrency problem regardless of the locality of the client and server ends of his service connection. Poor Joe's eyes have gone from glazed to bugged, and then oozed clean out of his skull and plopped onto the floor. His jaw is long past slack and has unhinged, his tongue lolling out and making unsightly stains on Joe's tie. Dizzy and on the edge of unconsciousness, Joe slumps forwards onto the bar, cracking his forehead sharply on his beer. Amidst the spilled booze and trickle of blood, Joe casts Bob the Evil Eye, gives him a rude gesture, and stumbles off to nurse his wounds and try and figure out what the hell clown currency has to do with anything.
Lately, I've become painfully sympathetic to Bob's plight. It's a bit of a stereotype that programmers are supposed to be fairly asocial to begin with (although I'm not entirely sure about the causality between being a programmer and being asocial, but I'm getting ahead of myself there). To make things worse, there are very few people in the world who can really truly understand the kinds of ups and downs we experience as part of our everyday work.
I noticed this pattern quite some time ago, and it's bothered me in a sort of subtle, subconscious way ever since: I'll be talking to some friend of mine and ask how their week went. They'll probably throw out a couple of anecdotes about what happened at the office/warehouse/nuclear power plant, we'll share the appropriate emotional responses, and then they ask me.
I learned a long time ago not to give honest answers. Instead, I'll take a quick mental average of the time span in question (day, week, life, whatever) and respond either "good" or "bad." That's it. My work experience - to everyone else - is entirely boolean.
It occurs to me (just now, of all times) that I really don't know what kind of impression that makes. Maybe people think I'm boring, or inarticulate (unlikely, considering how verbose I tend to be), or maybe bipolar or something. I really don't have any idea. But I also have no idea how I can fix that situation, because as soon as I try to explain how my week really was, people end up losing their eyeballs and waking up with weird bruises on their foreheads. It isn't exactly endearing, you know?
Of course, the Internet can't be ignored here. Via the miracle of technology, I have contact with a pretty large number of people who can appreciate the subtleties and interesting experiences of my job. Unfortunately, it just doesn't seem to provide the same kind of depth. Physical interaction adds such a huge layer of potential to a conversation that it simply cannot be rivaled by digital media. I can talk shop about programming via the Internet, but I can't punch anyone in the arm for making corny jokes, or pass them another drink, or make funny faces at them in the middle of important meetings. It simply is not - and cannot be - the same.
Sure, there's more than just work to talk about over in meatspace. There are all kinds of other mutual interests that can be discussed; there's Real Life stuff to talk about (and do) that doesn't have to stray into the realm of work. The job isn't everything. The problem is, the job is a very hefty chunk of things; we all spend a huge slice of our time working, and the simple mathematics of the situation dictate that a correspondingly large chunk of our life experience will be filtered through our jobs.
And when you can't talk about your job, that means you can't talk about a significantly large chunk of your life. That's a peculiarly nasty curse to live with.
I work a lot, primarily because I have a pretty powerful love for what I do. I find few activities as fulfilling and stimulating as crafting software. It's a rich and beautiful experience. And, being the touchy-feely kind of guy that I am, it kills me that I can't share that with more people.
I can't count the number of times I've been sitting here, usually in the dark, halfway through a can of concentrated sugar and stimulants, when I've been struck by something. Sometimes it's frustration or anger at a nasty bug. Sometimes it's inspiration. Sometimes it's an odd feeling of sheer joy at the fact that I'm doing what I'm doing. Sometimes it's a random insect that has snuck into the apartment by some crafty subterfuge.
When those moments occur, my first impulse is to share it - find someone, talk about it. Vent, or revel, or whatever; just do it together. Experience is enriched when it is shared.
It's always a painful shock to realize there's nobody to share with.
Maybe things would be better if I had a physical shared space with my colleagues. I'm sure it would help at least marginally. But that really doesn't do me too much good in the here-and-now. The people I know who can sympathize with the technical realities of my life are, unfortunately, largely just random acquaintences - not the kind of people you can call breathlessly at 4 AM and spazz out about stuff.
The people I can call at 4 AM to spazz out wouldn't have a damn clue what I'm talking about, which sort of cheapens things a bit.
I really don't have a point here. This isn't going anywhere - most likely because, if I knew where to go, I wouldn't have a problem to talk about in the first place.
It's a weird thing, the way technology has affected things. This is the kind of stuff you put in a journal or diary. Even as recently as five years ago, a journal was something you kept private. It's a sort of healthy all-American half-joke that you beat up your siblings for peeking into your private thoughts. When one wished to ponder these sorts of issues, the first choice was often the most concealed available medium. I know a few people who trusted more of their deep inner secrets to ink and paper than they did to other human beings.
Yet here we are, in the ripe old year of 2006, and it is no longer unthinkable to spill one's mind about such personal issues in front of potentially millions of viewers. It's the ultimate contrast from what the journal of days-gone-by stood for; there is no control at all over who may stumble across the scrawl of our subconscious.
I'm not sure what to make of the fact that it seems sensible to say stuff like this in a public forum. I think part of me is busy questioning the other part's sanity for being so comfortable with the notion.
Maybe it's because this is the best place I've got to find other people to discuss it with. That would almost seem pathetic if it didn't make so much damn sense.
Maybe it just sucks to be doing something incredibly cool - something I've dreamed of doing for years - and really have nobody to share with.
Maybe that's why I'm here.
| |
| Wednesday, August 23, 2006 |
| Financial Rape | |
Posted - 8/23/2006 3:26:54 PM | My wallet is bleeding.
So the scumsuckers over at Buy.com claimed to have E6600 processors in stock, so I bought one a while ago (I posted about it, I think). Turns out they're a load of lying bastards and did not, in fact, stock the processor. I knew it was too good to be true, especially with all the reputable sites listing out-of-stock at that point. Oh well.
So finally Newegg got them in stock, and dropped their obscene markup so that the price was competitive with street prices from other sites. I like Newegg, so I decided to cancel the (still not shipping) Buy.com order.
Get this - half of the order-confirmation emails from them talk about this other site, Shop.com. So I figured they were just the same site. Turns out they're not. Now, here's the crappy thing: Shop.com has my user account with its password... but no record of any orders from me. Buy.com doesn't have my user account on file.
So I'm thinking I may have to break down, dust off my phone, and talk to the dismally mindless fringe filth that usually populates tech support hotlines for online shopping sites. Fortunately, just before I resigned myself to that most excruciating of fates, I found an interesting link on Buy.com - Order Lookup.
Turns out you can look up full order details, including billing and shipping address information, with only the order number and a couple of trivial pieces of information. You know, the kind of information they send in fricken plaintext to you in the invoice email.
In other words, they're a massive security hole just waiting for fraud to happen. So I'm never buying from those assholes again.
On the bright side, I got my CPU from Newegg. Unfortunately, in a moment of weakness, I got an E6400 instead of the E6600 (the difference is 1MB of cache and a slight clock speed boost). Normally I wouldn't worry about this, but I'd sworn to myself I'd get the E6600 "no matter what" since it's the sweet-spot of the price/performance curve. (Naturally, this also means it's bloody hard to find in stock.)
So now I have an E6400 due in tomorrow, and an E6600 due in next week... along with my impulse-buy Athlon64 3800 upgrade for my gaming rig (up from the 3200 that's in it now).
Now, I was committed to spending that money, so it's not like I really care. I have a solid hardware budget that I've been saving for quite some time, so I won't have to trade food for sexy Conroe goodness. But the real bastard of the matter is this: between the E6400 and the 3800 upgrade, I've just cleared out $500.
And $500 just happens to be the budget I had set for getting a 360.
This leaves me with a nasty conundrum: return the two extra CPUs and get the 360, or keep the CPUs (you never know when you might want an extra CPU!) and wait until after Christmas for the 360 in hopes that the price will drop?
Door Number Two is looking like the winner here, since I'm probably going to be far too lazy to repack the CPUs and mail them back for the refund (especially since I'll get slammed with a restocking fee). I also can't pass up the opportunity to get discounted console hardware; considering I didn't buy an Xbox until almost three years into the product lifecycle, I think waiting a few months for a 360 will be fine.
So now all I have to do is endure the seductive siren call of Dead Rising that haunts my dreams...
| |
| Tools: the unsung, underpaid heroes of everything | |
Posted - 8/14/2006 3:44:42 AM | I want you to do something. This is something that virtually everyone can do. You don't have to be a game programmer, a programmer at all, or even have a job in computing. You don't even have to use computers, ever. (Well, OK, you do have to use computers, or you wouldn't be here.)
I want you to write down a list of 5 tools you use on a regular basis, to get stuff done. Pick your favorites; it doesn't have to be scientific, just the 5 you can think of quickly that make the biggest difference in your daily life. If you're a programmer, list your IDE, editors, browser, whatever. If you're an artist, list your art software, tablets, pen and paper brands, and so on. If you sit around on your fat ass all day surfing the web and eating junk food, list stuff like "plastic bags," "the Coca-Cola corporation," or "fork."
Got your top 5? Good. Now find out who made each of them. Send the creator a letter of thanks, and make it sincere. If appropriate, send a small cash donation, anything you can afford.
No, this is not a subtle plot - I did not litter the above paragraphs with subliminal messages in an attempt to harvest cheques and praise from you. (Go ahead, read it again - you won't find any such devious devices. I hid them too well! They don't exist.)
I haven't lost my grip on reality, either - fact is, I never had one.
My motivation for this is simple: tools are underappreciated. That may sound weird in a day and age where editor, compiler, and 3D modelling package are defended in epic flamewars that make religion jealous. Who hasn't been singed by the roiling inferno of Emacs vs. vi, Visual C++ vs. GCC, Max vs. Maya? Linux vs. Windows? OpenGL vs. DirectX? Puppies vs. kittens?
Sure, plenty of people understand very well that tools are important, and how much effect they can have. I've dribbled quite a few grandiose tomes about how important tools and efficient workflow can be. But there's still a problem.
I love Fred Brooks. I really do. If you haven't read The Mythical Man-Month, go buy it and read it like ten times, rightfrickennow. It's genius, it's profound insight, and it's crammed full of invaluable truths about how our business works. And it's three decades old. You can't buy timeless power like that. (Well, actually, you can - try Amazon or your local Borders.)
Good ol' Fred suggested an interesting formation for software development teams, similar to the way surgeons do their thing. One of the central members of the Surgical Team is the tool creator. Brooks correctly and emphatically points out just how valuable that guy really is, and makes it clear that to underestimate that role is suicidally foolish.
And yet how many times have we all looked over the classifieds, seen a nice-looking job with great pay and benefits for which we are totally qualified, and then shrugged it aside because "it's just tools"? Shame on us. Shame on us stupid, stupid fools. I've done it, and I'm pretty sure you probably have, too. Heck, if you're like me, you do it a lot - and rarely if ever realize it.
Here's a quick thought experiment for you: think about some huge, awesome, ground-breaking, revolutionary project that you'd be interested in working on. The Pneumatic Midget Cannon, Doom IV, a cure for cancer, holographic interactive porn, whatever. Now, suppose you're given your dream job working on this project: you set your own hours, your own responsibilities, and even your own salary. You can have one of two main roles: working on the project directly, or creating tools for others to use as they do the project. The positions are identical in every possible way, except for the actual work you do.
Show of hands: who wants to make tools?
Put your hand back down, you filthy liar. Everybody wants to be on the front line, doing the sexy job and raking in the TV interviews and book deals. Can you name a single person involved in the Manhattan Project, without looking it up? But I bet you know the president who dropped the bomb. Can you name three people who have worked on Visual Studio? (Microsoft employees need not apply.) But you probably know people who use it... like, say, John Carmack, or Tim Sweeney.
Ever heard of Alexander the Great? Sure you have. Ever heard of Iolaos the Ironmaster? Didn't think so - he was "merely" the guy responsible for creating most of the legendary weapons and armor used by Alexander's mighty armies.
And yet you've never heard of him.
OK, fine... the fact that I totally made the guy up sort of skews the numbers. But it's the principle that counts; I had to make him up because nobody knows who actually did it. Being the guy that makes the tools isn't glamorous or attractive. It's just boring. If you want the glory, you've got to be the guy who goes out and uses the tools.
Some people might argue that that is a natural thing; after all, a sword isn't really worth much unless you cut and stab stuff with it. Compilers can't write code by themselves. Little balls wrapped in leather don't run around autonomously on fake grass fields. People have to use the tools. So who really cares if the tool creators don't get any love?
I say, though, that this situation is a travesty, a tragedy of epic proportions, a horror and shame and all-around detriment to all of civilisation. Well, maybe not all that, but it definitely sucks.
Sure, we have to use the tools in order to do anything meaningful, so tools on their own are nothing. But what is a great man with no tools? I submit to you that he's actually an impotent shmuck who will get fat and die of a myocardial infarction on his couch from eating too much junk food. Or maybe get stabbed by the Other Guy and breathe his last in a decidedly anticlimactic pool of innards. That sort of depends on what exactly he was going to do. But either way, he's probably not going to get much done.
Magnificent tools with no users are, at worst, still pretty good tools. Magnificent users with no tools at all aren't worth jack.
Truman would be nice and obscured by history if he hadn't cooked a couple of cities clean off the map. Had he never gotten ahold of computers and programming tools, John Carmack would have been... well, not nearly as famous most likely. If good ol' Alex didn't have his sword, he wouldn't have done that whole Gordian Knot thing, and we probably never would have heard about him.
There's a moral to all this. The next time you start up some project, don't fall victim to the temptation to do the tools later. I routinely see projects start up, and people are all excited and enthusiastic, and really keen on getting stuff done. They figure it's worth the mild inconvenience of editing things by hand and gimmicking around for a while until the "tools" are all done. After all, maybe the data formats will change, or my ideas will go some other direction, or... or... or... whatever. Write in your own excuses.
The important thing is, those excuses are evil lies. Eventually, you will reach a point where not having tools is actually costing you more time, effort, and frustration than the expense of doing all the "boring" job of creating the tools. I think most people already realize that; the problem is, most people wait too long to do the tools. By the time you notice that you need tools, it's already too late.
Suppose you're out on the battlefield. Maybe you're saving the earth from evil alien demons, or whatever. You brazenly swaggered out onto the field unarmed, certain that as soon as you knew the level of danger, you could run back, order a suitable weapon, wait for it to be manufactured, learn how to use it, then get back out to those evil demons in time to load some hot lead in their maniacal asses.
Sounds really stupid, doesn't it? And yet, in software development - especially games - we do this to ourselves all the time. We start with just a "quick and dirty prototype" and then refine it into a "pre-1.0 version" and so on. Next thing we know, it's legacy code, three generations of maintenance programmers have poked at it, and the users still create data files by hand in Notepad.
If you realize you're hurting for lack of a tool, you've already wasted invaluable and irrecoverable time. It's too late; the demons are already using your bones as toothpicks. And, honestly, when can we not see the need for tools in advance? The alien demon invasion scenario is obvious enough, sure, but what about WidgetMeister 2.0? Is it possible that we might actually not be able to reliably predict what tools we'll need?
Well, you tell me. Personally, I can't think of a single case where the purpose of the end product is known, but we can't figure out what tools will be needed to get the job done. Any good gamer or military buff can tell you that, to repulse an alien demon invasion, you need some Big Fucking Guns. And any good programmer can tell you what tools you'll need, long in advance.
Here's a scenario: excited with the plans for New Project Foo, the team sits around one afternoon with coffee and donuts, brainstorming and talking. Someone mentions the Quux Data that will be so essential to Foo's operation. Developer One says something like, "Yeah! We can do Such and Such and The Other and it'll all be great! And if we use XML or Other Buzzword of Choice we can reap unfathomable benefits in terms of Obscure Business-speak Bullshit Phrase!" And in pops Developer Two with, "Yep... yep... we could even create a really cool GUI drag-and-drop editor that magically creates Quux files and pets kittens, all in an environmentally friendly way!"
And everyone agrees that the editor would be Really Awesome, and We Should Definitely Totally Do It, and such. Then the resident cynic (that's usually me) says something like, "Well, we have to get the data format nailed down first. We should probably do a prototype, too." Somewhere along the line (it may take a few months), everybody agrees that there's enough work to do, and the Quux Editor will get pushed back to Version 2.0. Hey, then we can sell it as a New Feature - value added to justify the exorbitant upgrade price. Perfect plan, right? Quux files can be edited easily in WhateverApp... it's a little finicky and not as user-friendly as it could be, but who cares?
Sound familiar? I've seen this one play out numerous times, and always with the same results: sometime down the line, long after it is too late, we all wake up and realize that some dark hellspawn is cleaning its teeth with our former shin bones. Oops.
So, if you're the kind of person who doesn't read between the lines very well, or has to have things spelled out in explicit sound bytes (or if you just skipped all my palaver to read the last paragraph and get the punch line), here's the point of my little musings:
Build your tools first. Don't let the Legions of Evil pick flesh out of their molars with the shreds of what used to be your leg.
| |
| Thursday, August 10, 2006 |
| Musings on the future, part 2 | |
Posted - 8/10/2006 6:07:27 PM | I'm finally going to get around to wrapping up my thoughts on programming languages and the future of processing hardware. Be sure to read part 1 first, or none of this will make sense. I'd also highly recommend Carmack's keynote speech for some additional background and validation of my ravings. In fact, I'll just flat out say that Carmack's speech is required viewing for really getting much out of this entry. So go burn a few hundred MB of bandwidth, and come back when you're done.
Ready? Good.
Let me start with multi-processing, or more accurately the challenges of parallelized programming. Current technology revolves around a model called Symmetric Multi-Processing, or SMP. SMP basically gives you a handful of identical processors, and lets you run code on them in parallel. In the early days, SMP meant literally having more than one CPU chip; nowadays, the trend is to cram the processors onto a single die, known as a multi-core architecture.
Intel's plans for the future involve what I've come to call core proliferation. The reason we are seeing such a big shift towards SMP, as Carmack outlined, is that we're close to the limit of what a single core can do. The logical place to continue getting speed boosts is to add more cores. Core proliferation, in a nutshell, is the tendency to continue adding cores as the primary means of increasing raw processing performance.
Core proliferation - and, really, the entire notion of SMP - has dire consequences for most programmers. (NB: I'm going to focus primarily on games here, partly because, well, this is GDNet, and partly because that's what I know best.) The bulk of performance-critical game code is written in C or C++ these days. The problem is, both languages really suck at writing parallelized code.
There are basically three main levels at which we can parallelize any given computing process. The first and highest level is separation of processes. An easily identifiable example of this is doing graphics on dedicated GPUs, and running game logic on the CPU. These are two different processes that can be done largely independently. Incidentally, this is also the same model that early multitasking operating systems used - divide things into (largely) unrelated processes, and each runs independently. When possible, they run in parallel. The "process" term is still in active use in OS kernels to discuss that level of organization.
The next level down is separation of steps, or (more familiarly) mulithreading. Here, we have several steps in a single process that can be done independently. Each is split into a "thread" and shunted off onto any available processor. Threading is almost exclusively done on CPUs, although programmable shaders represent a sort of analogue. The important difference here is that threads are often deeply interrelated.
The final level is separation of operations, where we actually look at the individual atomic instructions that the code executes on the CPU, and do some magic to make them run in parallel. Hyperthreading is exactly that. Back in the day, it's the tactic that Abrash and Carmack used in Quake to get performance gains there.
Now, I'm abusing terminology a little bit. Most of the time, multithreaded software is not actually divided in the separation-of-steps plane. In fact, today the majority of multithreading is done to accomplish separation of processes. As an interesting side note, this has been the cause of a not-so-minor philosophical war between various flavours of Unix and Windows; Windows tends to prefer splitting processes rarely and threads often, whereas the traditional Unix approach is to split processes (in the OS sense of the word) rather than threads.
This isn't because people are belligerent shmucks who don't like using words the same way I do. It's because of the programming languages we use.
Multithreading is, these days, more or less synonymous with separation of processes. At Egosoft, as we've looked at updating our technology for taking advantage of SMP in the future, we've approached it from the perspective of dividing up threads (and, by extension, CPUs) by processes, rather than by steps in an individual process.
The reason for this is interesting and all-important: separation of processes requires far less synchronization than separation of steps.
Let me explain a bit what I mean by that. Consider two individual processes, rendering graphics and rendering audio. The graphics process involves doing a lot of transformations, lighting, shader code, and eventually pushing around pixels. Audio requires doing some physical simulation of the environment, controlling volume levels, doing mixing, and eventually pushing raw waveform data to the sound hardware.
These processes are highly independent; the only time they really need to "sync up" is to make sure a gunshot sound goes off at the same time as the muzzle flash is drawn on the screen and the bullet flies out on it's way toward some hapless bastard's skull. Typically, these two processes are synchronized per-frame; that's the simplest way to effectively make sure they stay lined up. If graphics rendering takes longer (which it's almost guaranteed to do), the audio code waits around for a while; once they're both ready, they do the next frame's worth of work, and the cycle goes on.
By contrast, consider the act of splitting up AI into multiple threads. Suppose I've got fifty tanks all doing their thing in some virtual environment. They roam around and do stuff. Then, one tank decides to shoot at another - tank A wants to whack tank B. Unfortunately, tank B's position is currently being decided by AI thread number two, while tank A is being handled by thread number one.
What we have here is a classical synchronization problem. In order to know where to fire, tank A has to know tank B's position. But tank B is currently deciding where to move. Tank A has to wait until thread 2 finishes moving tank B, or risk a miss. However, what happens if tank A is the first tank handled by thread 1, and tank B is the last one handled by thread 2? Now thread 1 has to wait for all of thread 2 to finish running before it can start its first tank.
Now, there are some ways around this, obviously. The problem is, they are complicated, and bug-prone. I won't get into the technical side of how to solve that problem (it's actually one of the easier ones to solve), but that's a good taste of how complicated it is to split things up by steps rather than by processes. Believe me when I say it gets much worse than that - especially when you throw in the ultimate unknown: multiplayer.
For now, the answer is easy: just perform separation of processes, stick one process on each CPU (and maybe combine some of the quicker processes onto a single CPU), and you're done. You can avoid too many sticky synchronization issues, and still get a benefit from SMP.
That's a great solution, and will remain the staple way that game developers take advantage of SMP - for a while.
But eventually, if the CPU manufacturer's get their way, we will encounter core proliferation. What happens when you have 24 cores, but only 6 distinct processes? You're forced to either approach separation by steps, or waste 18 processors. But separation by steps is hard, and one of the biggest unexplored frontiers of software development today. The net result is that it will be hard to develop games - which, in turn, means development will get more expensive.
So are we all doomed to waiting 6 years and paying $90 for Halo 4? Don't panic just yet.
There are two main ways that we will solve the problem of core proliferation. The first, and most obvious, is to improve our tools. The main reason that multiprocessing is expensive is because C and C++ suck for synchronization. There have been better ways to write parallelized software for literally decades - in the realm of functional programming languages.
Ericsson actually realized this a number of years ago; they had a need for extremely parallel and highly reliable systems. The existing technologies wouldn't cut it. So they invented their own, which has gone on to enjoy quite a bit of cult success - you may have heard of Erlang.
Within the scope of the next 5 years, developers will begin leaving C and C++. In their heydey, those languages were favorable for one primary reason: they spoke a language very close to that of contemporary hardware. They worked well with low-level concepts like memory pointers and even assembly language. They closely mirrored the design structure of the hardware itself.
However, in the past several years, that has ceased to be the case. Processors are now flooded with bizarre prediction technologies and genuinely remarkable capabilities for doing things out of order (while still getting the right result). Caches, pipelines, and predictive systems are what have gained us the bulk of processor performance in the past 8 years. Carmack makes a vital (but brief) allusion to this early in his talk.
C and C++, by contrast, have not kept pace. They still represent anachronistic models of computing and processing, which no longer speak to the hardware. They do not intrinsically understand threading, multiprocessing, or even branch prediction. Individual compilers have done a fairly reasonable job of converting C/C++ code into assembly that is aware of those concepts; initiatives like OpenMP have helped with parallelism as well.
But ultimately it will not be enough. C and C++ are dying, because their once great strength - closeness to hardware - is long gone. As the hardware continues to diverge from the outdated model of those languages, they will become progressively less relevant to mainstream development, particularly in performance-critical, close-to-the-system sectors like the game industry.
Functional languages will have their day in the sun - and it will begin in the next few years. This is virtually inevitable. The reason? Functional languages have the potential to represent the model of hardware much more closely. The benefits of functional programming for parallelism and massive concurrency are very well-understood, and well-discussed elsewhere.
However, note carefully that they have only the potential - IMHO, current functional languages aren't real great for practical development in many cases, and are very far from realizing their true potency.
Now it's shameless plug time: enter my little pet project, Epoch. The big struggle right now for Epoch is to find its killer trait, that one thing that will make it kick so much ass that it just totally wipes the floor with existing tools, and takes over the world. (I'll be honest - that's pretty much what I want to see it do.)
From the beginning one of my big emphases for the language has been the ability to think close to hardware. In my mind that is the single strength that is truly responsible for the success of C and C++ in the gaming sector, and I think that's the sector that Epoch has the best chance of succeeding in (due, in no small part, to the fact that that's where I personally can bring its influence to bear).
However, I think my original concept was off base. Initially, I thought it'd be another C - talking about memory pointers, able to call specific code addresses via function pointers, supporting inline assembly, and so on. Parallelism would be important, but I saw it as a mostly orthogonal concern. The more I look at it, though, the more I'm convinced that the opposite is in fact the case.
Allow me to paint for you a hypothetical picture. Imagine a processor which is not 16 or 32 general-purpose cores crammed together, but instead 64 or 128 highly specific mini-CPUs. Each pipeline is designed for a particular type of processing: one set of pipes may be really good at doing short tasks millions of times in a row. Another set might be good for deeply-pipelined operations like graphics processing, where a chunk of data has a lot of work done on it over a relatively long period of time, but massive globs of data are processed this way in parallel. A third might be really good at the stuff that we use SIMD instruction sets for today. Yet another set might excel at slow operations that rely on external input. Let's call all of this mini-pipelining.
So far what we've got is a classical example of ASMP, or asymmetric multi-processing, where each "node" in the set of processors is not necessarily identical to the others. Instead, each is highly specialized for a particular family of tasks - but not necessarily just one particular task, the way GPUs are currently.
Combine this with a memory architecture that can supply memory efficiently and at sufficient bandwidths to keep each mini-pipe happy. We have now eliminated processor stalling as much as possible.
At this point, we have one major question: how does one create software for this? Do we have to specifically address each mini-pipe in our code, the way we have to design for CPU-vs-GPU workloads now? (Or, for a more scary example, consider the way we have to code for processors such as Cell.) Or do we invent some kind of hyperthreading-analogue that intelligently splits code up and runs it on each micro-pipe as appropriate?
I think a HT-style approach is out, for one main reason: it would require knowledge of the code being executed on a relatively massive scale (i.e. potentially tens of thousands of instructions). While this is certainly possible to do in realtime (especially in the span of the next 5-10 years we're talking about here), it's stupid to do so - because the code is largely static. It doesn't need to get re-analyzed every time it gets run; it only needs to be analyzed once, each time it is compiled.
The natural solution is to use some kind of hinting, where the compiler emits a sort of meta-data markup on the code, telling the processor which pipe to run various tasks on. To some extent, appropriate pipes can be determined solely by which sorts of instructions the code uses, but ideally we'd see the instruction set look much more like RISC than the CISC-style we get currently. (That's a pretty involved discussion, though, so I'll gloss over it for now.)
So again, we have an important question: where does the compiler get these hints from? Does it generate them automatically from the code? Or does the programmer have a hand in adding them, ala OpenMP or threading?
The answer is nice and Zen-like: both, and neither.
Functional programming provides the perfect venue for exploring this possibility. First of all, it allows the compiler to make some very sophisticated deductions about the code being handled. Secondly, it allows the programmer to add subtle hints without expending extra effort.
Designing a multithreaded program is many times harder than designing a single-threaded one. Achieving comparable quality is hard enough; getting a genuine performance benefit is more difficult still. However, with a good, well-designed functional language, it should be possible to allow the programmer to provide subtle hints about the kinds of work he's doing, without expending extra effort. In fact, he may well save himself some time, too.
Consider a contrived and obviously overly-abstract example: if the kinds of operations done by tail-recursion can be shown (by the compiler) to belong on Minipipe A, whereas operations done by map on a certain type of data structure work best of Minipipe B, the programmer can interchange those methods (quite easily) to affect which minipipe runs a given chunk of code. If, by chance, the map approach is more sensible and leads to cleaner code, he gets a double bonus: the code is better, and it runs on pipe B, thusly being more performant. (I will conjecture that this case will happen quite often, although I have nothing more than intuition to justify that statement for the time being.)
Now that's just the crude, rudimentary level of things. Chuck in a JIT-compiler and hardware-level profiling data, and think about what that might do to code. Combine all of that with a CPU that supports JIT-style execution as well as adaptively changing the pipes that run code - what I've been mentally referring to as "adaptive mini-pipelining."
Just chew on that one for a few minutes. I suspect you'll get as excited as I have over the huge potential that such an approach can afford.
So... there's my musings on the future, and where I believe things will end up. I may have the timescales off by a significant amount, but I think the trend towards AMP-style processing is more or less inevitable. I know there's a lot of awfully definitive and sweeping statements made here, and only time will tell, but I think I've gotten a pretty decent handle on the state of affairs and its likely directions.
The question, of course, is what do you think?
| |
| Woohoo! | |
Posted - 8/8/2006 4:55:02 PM | The agony has ended. I've finally found suppliers who actually carry stock of Conroe CPUs and compatible motherboards, and made the big plunge.
Now I just have to wait on shipping. There's also a small chance that the place I got the CPU from will be sneaky filthy bastards and drop it on back-order, but we'll see.
The final specs:
- Intel E6600 Core 2 Duo CPU
- Asus P5B-Deluxe Motherboard
- G.Skill 2GB DDR2-800 CAS4 RAM
- Sapphire Radeon X800XL GPU
- Seagate Barracuda 300GB SATA3 HDD
The GPU is easily the weak point in the system, but it's a beefy enough card, and it'll run the stuff I need to work on plenty well. It's also an easy upgrade should the need arise down the road.
So... if the universe decides to play nice with me, I should be free from my sluggish-development woes within a week. I'm not holding my breath, though.
For now I've got my laptop set up and using one of my LCDs as a second display. It's awkward as anything and very annoying to have two totally different-sized monitors, but it's only for a week or two at the most - and the speed gains over my old machine are so huge as to make it more than worth the discomfort.
All told it clocks in at just under $1350, which is a couple hundred more than I originally wanted to spend, but considering the increased wallop of the Conroe CPU and an added 100GB of hard drive space, I think the price difference is more than reasonable.
It'll be almost two months from my original decision to upgrade when I finally get this machine built. Waiting totally sucks.
| |
| Why my kids will be home-schooled | |
Posted - 8/7/2006 5:25:13 PM | So I've been catching up on my web reading after my trip, and I came across Daerax's post about the school system. I find my own story remarkably similar, and my opinions about the ssytem just as strong.
It wasn't until fourth grade or so that I really cottoned on to the fact that the system was actually damaging me. Looking back, though, I think I can see why - for my first three years of education, I had the tremendous fortune to have teachers who recognized my situation, and handled it accordingly. In fact, I can deliberately trace back my enjoyment of those three years to those teachers.
I'm normally pretty self-conscious about thinking differently from most "normal" people. I've had more than one person tell me they thought I was "a little slow" or even autistic until I happened to give in and throw out something intelligent-sounding. That's largely been the result of my school experience; the system came very close to burning that out of me entirely, and pushing me to just stifle it and blend in with the status quo. That's why I find all of this so scary - it very nearly worked.
(Some of you may be chortling into your shirt sleeves at the mere thought of me being uncomfortable talking about myself. Believe me, this is pretty much the first and only venue I've used to do so. I vent all of my smug arrogance here because it never gets to see daylight anywhere else  )
As my parents like to tell it, they first noticed I was "a little different" when one of my first sight-words was "cholesterol" -- at the age of four. One night I copied the entire periodic table of the elements from my older sister's chemistry textbook and hung it on my wall - being five years old at the time.
Once, before I started school, I got in trouble for insulting a second grader for not knowing how to do multiplication. In the first grade, when the class was learning to trace the alphabet over inch-high, dotted letters, I was sneaking down the hall and copying the cursive alphabet reference from one of the other classes, and copying random bits of sheet music into the margins of my homework. I rarely turned in anything that wasn't covered in doodles of astronauts, spaceships, and ray guns.
I don't recall for sure, but sometime between the first and second grades, my teacher caught the "warning signs." As I look back on it, I owe pretty much my entire life to Mrs. West. She made a very strong impression on my parents about just how important it was to feed my behavior - which, she warned, would become increasingly anarchic and chaotic over the years. She strongly emphasized the fact that I would begin to fight the system, and made it absolutely clear that I was to be encouraged - even assisted - in that, no matter what.
Naturally, I didn't find any of that out for years. The only inkling I had was the "special test." The test was fine with me, since it meant I got to skip a couple hours of class. It was quite a while before I caught on to what the test was for. The only part of it that really stands out in my memory was a single question.
The guy giving the test was nice enough; he knew better than to use a condescending tone with kids, which I had already subconsciously learned to equate with people who were worth respecting. He got to a question about the "difference between a 'yard' and a 'pound'".
As I recall, I got a good minute and a half into a diatribe about the philosophical implications of imprisoning animals and confining them to prescribed spaces versus treating them as near-equal members of society (that is, pets). The guy got really bug-eyed and finally interrupted me, and explained that he was talking about units of measurement. I remember thinking that it was odd to have such a simple question on a (clearly important) test.
That kind of thing continued; the better teachers I had would give me extra challenges and leeway to screw around while I waited for the rest of the class to catch up - provided, of course, I didn't disrupt anything. The bad teachers would insist I quit drawing on my homework, quit staying inside to write out computer programs in my notebooks instead of playing on the playground, quit taking my notebooks outside, and so on. A "survey" of the students in that year asked what everyone's favorite part of the day was; the other students' answers were usually things like "recess" or "lunch." Mine was "getting done with math early and working on my own problems."
There were more incidents than I can really count; eventually, as predicted by my first grade teacher, I got outright confrontational. Fortunately, a well-timed move lined up with a perfect opportunity for me to begin home-schooling. In sixth grade I joined a weekly program that was designed to supplement home-schooling with proper lab experiments, social interaction, and so on. It took about three weeks for the teacher to pull me aside and ask if I was willing to do the eighth-grade level course work instead; that was the highest he could offer.
I dropped another couple of years into The System, and had quite a few very explosive run-ins with the more traditional, closed-minded teaching staff. I got along quite well with a couple of teachers, who quickly pushed me off into my own projects when it became clear that the regular class pace wasn't enough. Usually, they did so in the face of very severe opposition - and, in one case, harsh consequences - from the higher-ups in the system.
I formed a group of students that swore to overthrow the student-council body and cause chaos at every school event; we successfully operated for two years. If it hadn't been for the good teachers there, we probably would have explored our more elaborate plots - and gotten sent to the Big House for serious property damage.
On more than one occasion, I got into pretty deep trouble for telling teachers how they should be running their classes, or outright correcting misinformation. In retrospect, I probably shouldn't have done it in front of the entire class, but I still think it's a bit stupid for the system to discourage criticism from the very people that are supposedly being trained to deal with real life.
I technically finished high school, but, being a home schooler, have no credentials to show for it. Legally speaking, I'm a dropout. I don't regret it. In the years since, I've thought seriously about going back to college to finish up a degree; I'd love to learn, and some of the stuff I'm most interested in is impossible to study outside of academia. Through it all, the single reason I've put off doing so is always the same: I love to learn, but I hate being taught.
It is telling that so many smart kids come through the education system so thoroughly disgusted with it. I can readily think of dozens of ways in which the system can (and should) be changed, and I know from talking to other people in situations similar to my own that my views are not unique.
The more I look at the state of this nation and Western society as a whole, the more apparent it is to me that virtually all of our problems arise from a single cause: free thinking is actively discouraged. Our society is designed to create a system of automatons. For a country that is supposed to be the icon of freedom and individuality, we're doing a shitty job of it.
Why do we elect morons into government offices? Because vanishingly few voters educate themselves about the issues. Most - including many in my own family - use knee-jerk reactions and hasty decision points, or vote along party lines. It's not always because they're stupid; usually it's because they just don't know any better. Or they're lazy.
Why do our corporations topple to stupidity, greed, and corruption? Why is white-collar crime becoming an increasingly rampant problem? Why is religion being used increasingly as a mindless excuse for a vast host of ridiculously intolerable behavior? Why is misinformation on the Internet so painfully easy to propagate?
All of these problems can be cured by a single, simple thing: critical analysis and reasoning skills. The ability to consider an issue, think it through from various points of view, and come to a decision is a vital skill for living as an adult member of a civilised society. Without that skill, society will inevitably lapse into a cycle of complacency, which leads to increasing concentration of ever-greater powers to an ever-decreasing number of people, until eventually we arrive at a more or less feudalistic or even imperialistic situation. In the happy cases, a large enough underground of critical thinkers arises, overthrows the tyrrannical powers, and ushers in a (woefully short) era of freedom and prosperity.
I think right now this country is well past the complacency phase and quite a ways down the road to creating a dictatorship. I know I'm hardly alone in that assessment.
For quite a while, I believed that such a cycle is an inevitable and natural part of the way societies work. Certainly the pattern has been observed often enough. An informal look at society clearly shows that critical thinkers are a minority - the people who really genuinely care, and who have the mental skills to do something, are simply overwhelmed by the vast herds of those who don't.
The responsibility for keeping society operating lies squarely on the shoulders of those who have the ability to think for themselves, and the integrity to act accordingly. But if those people are outnumbered too severely, it is all too easy to accept defeat, and allow the cycle of collapse to take over. It is my belief that this is the predominant cause of the decay of "free" societies into feudalistic or despotic ones.
So what are we to do? If there are not enough of us to stem the tide forever, and keep the weight of entropy from destroying our efforts, should we accept that fate? Should we expend our energy and our lives in vain, and postpone the inevitable for perhaps another generation, at the most? Or should we resign ourselves to the reality that most people are lazy, ignorant fools who will gladly jump off the lemming-cliff of society and drown, if it means they don't have to turn off the TV?
Being cynical and more than a bit lazy myself, my answer for quite some time has been "eh, screw it." I figured it would be better to enjoy life and not worry about things I can't control a hundred years into the future.
But that's stupid. If nobody worried about 100 years from now, we'd leave the world in pretty crappy shape. It may be easy for us to write off future generations... but what if the people of the early 1900's had decided the same? What if, 100 years ago, someone had decided "eh, screw it" and turned the surface of the planet into nuclear-ravaged glass? Someone will suffer the consequences in 100 years; the fact that it probably won't be us is irrelevant. The survival of society is impossible if the views of every person are as narrow as their own lifetimes.
Why should we fear consequences from criticising government? For that matter, why should we fear consequences from criticising our own employers? Problems do not get fixed by people quietly pretending they don't exist. Problems get fixed by people raising holy hell until enough others get concerned and take action. Those who question and challenge the status quo should not be looked on with distaste or distrust; they should be the heroes and idols of society. Being a whistle-blower should not have the stigma of the annoying, bratty kid who tattle-tales all the time. That should be a role of honor, respect, and admiration.
I for one am sick of the situation. I'm not content to just watch it go to hell. And someday, hopefully, I'll be in a situation to decide where and how my own children will be educated.
In my mind, there really isn't much of a decision to make. My children will be home-schooled. They will be taught to be critical thinkers, to attack the system, to question weakness, and to encourage proactive change. I will raise my children to dream - fervently and with the passion of great visionaries - of overthrowing the system. My kids will tell people that, when they grow up, they want to be whistle-blowers, and the bigger the scandal they blow open, the better.
The cycle is not impossible to overthrow. It is not too late to change. There is still plenty of hope for fixing tomorrow. But it will take critical thinkers, skeptics, people who challenge anything and everything they see.
Such people are not rare by virtue of some genetic prank. They are not rare because they are unusual, or because "normal" people are incapable of taking on such a role. Such people are not required to be extraordinarily smart, insightful, or genetically lucky. They just need to be trained.
Our society has reached its current situation precisely for one reason: our educational system has caused it. The collapse and decay - so evident to those of us who do have those all-important skills of analysis - is the inevitable and inescapable by-product of a system that trains children to prefer regurgitated dogma to carefully considered opinion. The entire connotation of the word "opinion" has shifted; it no longer represents a view derived from analysis and thought. Opinions are now utterly arbitrary, purely subjective, and unassailable. In many circles, it is actually considered reprehensible to hold an opinion with any basis in logic or rationality.
Anyone can be a critical thinker. It does not require a prodigious "IQ" (although the very notion of IQ is pretty stupid and directly tied to the very system that's caused us so much trouble). You don't have to be weird, abnormal, unusual, or even especially smart to do it.
And, amazingly enough, there is a direct correlation between one's ability to think critically, and how much one cares about important issues. Complacency is an epidemic problem in our society, but not because of something in the water - because nobody has been trained with the mental skills to realize that they should care.
Daerax, I'm fully behind your efforts. Let me know how your project develops - I'd like to do the same, when the opportunity arises. It's time to fix the problem.
| |
| Guuuuuuuuhhh. | |
Posted - 8/4/2006 10:26:56 PM | It's hotter than Satan's balls on a barbeque.
I'm going to bed.
| |
| Wednesday, August 2, 2006 |
| Interlude: on tools | |
Posted - 8/2/2006 12:13:10 PM | I'm going to interrupt my two-part brain dump on future hardware and programming technologies, for a couple of reasons. I'll start from the beginning so that hopefully my explanation is vaguely coherent. (That's unlikely, though, considering the extremely advanced state of sleep deprivation I'm in at the moment.)
I'm getting ready to make a little road trip up to my parents' place in Indiana, ostensibly to help out with construction on their new house, and other such stuff. Unfortunately, this isn't a proper vacation, which means I'll be taking some work with me. (It works out fine, though - they'll be asleep by 9PM every night which gives me a couple of hours guaranteed to get stuff done  )
So I've been copying my build environment over to Relm, my laptop, in order to be able to take my projects on the road. This is a pretty easy procedure, since I've got about 90% of it set up already from previous travels. The rest could actually be automated, but I haven't gotten around to it yet; I'll have to seriously think about it for the future. But that's another digression I don't have time for.
The upshot of this little bland slice of routine is that I realized just how much my current development box sucks. It's a great, reliable, and incredibly resilient machine, no doubt; but it's simply too old and decrepit for developing a next-gen game.
I've been planning, of course, to upgrade to a shiny new Conroe box - but it'll be another couple of weeks before inventory levels stabilise on the processor model I want, and I'm holding out for some price drops on the few Conroe-compatible motherboards. So I've just been hobbling along on my AthlonXP 2400 and GF4Ti4800 for the past couple of months, quietly losing my mind and pretending to be patient.
I timed a full compile/launch cycle on Phoenix, my development machine - the time it takes to recompile the entire game code (sans stable libraries, of course), start the game, and reach a point where I can actually play - I mean "work". On average, the length of the cycle is 6 minutes. What's worse, because there's a couple of game menus involved, I have to by physically present at the machine to keep the process moving forwards, so I can't even nip off for those 6 minutes to do other things.
And, since my processor is ancient rubbish, my machine is pretty much totally monopolized by the strain of running the compiler and/or the game. All of this translates into massive amounts of downtime, and as I've burbled before, downtime is very bad.
By contrast, on Relm, the glorious, beautiful, dual-core hunk of digital sexiness, the compile/launch cycle is roughly 40 seconds.
Yes, that's right. 40 seconds. Versus 6 minutes.
The more I think about it, the more I can directly trace my low productivity over the past few weeks to my hardware. Much of the time I don't have to do a full rebuild, which cuts the code/run cycle down to 2 or 3 minutes, but that's still 2 or 3 minutes I shouldn't have to be losing.
What's worse, I don't have the patience to sit in my chair and stare at the compiler while it does its thing - and I can't do anything else on the machine in the meantime. So, quite often, I'll get up and pace around, stretch, grab another drink, etc. This has two negative effects. First, I rarely sit down again at the exact moment that I can resume being productive, which adds to the downtime. Secondly, and more importantly, I lose my brain state.
I realized today that I haven't gotten into a proper groove in weeks, because I'm subconsciously frustrated as hell by the sluggishness of my hardware. So instead of building up momentum and getting huge swaths of things done, I keep stuttering in little abortive bursts, punctuated by compiles and waiting for the game to load.
My main excuse for hanging on to Phoenix has been the dual-monitor happiness. Yeah, 17" widescreen is really nice, but it just can't touch dual-17s for raw real estate. I'm constantly running two or three instances of Visual Studio for showing code and data files side-by-side. At any given moment there's a half-dozen browser windows, Notepad snippets, IM conversations, emails, and whatever else floating around. It's a critical part of getting stuff done.
Now that I've reminded myself just how much I'm sacrificing for those dual screens, though, I think it's time to just say "Screw it" and move over to the laptop entirely. I'll have to do that for this trip anyways... and moving all the data, email, blah blah blah back onto my desktop is a nuisance... so I'm just going to shift my development operations entirely over to Relm, until such time as I get around to building the Conroe machine.
Well, as usual, I blew a lot more hot air than I thought... if you think estimating schedules for software development is hard, try estimating how much drivel I'll sputter when I get to raving about something pointless. I was originally going to segue into some additional thoughts on productivity, tools, and programming languages... but I've forgotten half of what I was going to say, and I think most of it fits better in the Musings sequence anyways.
So here's another cliffhanger ending for you. Please don't lynch me.
And now a word from our sponsors.
| |
| Musings on the future, part 1 | |
Posted - 8/1/2006 7:56:43 AM | I had a scary realization a short while ago, the kind that fills you up with feelings of age, the shortness of life, and - perhaps paradoxically - a deep sense of fulfillment at what has been accomplished in a fleeting span of time.
You see, it's been five years. The landscape of games technology has changed dramatically in that time, and the next five promise to be even more radical. Five years ago, I certainly wouldn't have predicted that things would turn out as they have.
As a matter of fact, five years ago, my plan was to be releasing the second or third generation of real-time raytracing technology. At the time I was still planning on software-based rendering, but that changed. I had a vision for a world with a radically different approach to computer graphics - and my products at the center of it all, naturally.
I "officially" discarded my other hobby projects to begin focused work on the "Freon 2/7 Project" in April of 2002. The announcement was made on my web site, to the vast audience of about three people. I'd already done quite a bit of experimentation in raytracing, and had written the beginnings of my own raytracer. Over the next two years, I poured thousands of hours into research and development on the technology.
It quickly became clear that software wouldn't hack it. I shifted my focus to developing a prototype of a system that would effectively be a fixed-function hardware accelerator for raytracing. At the peak of my research, I developed a fast global-illumination approximation algorithm, which still remains unpublished (out of hope that I might get to use it properly someday).
Soon, though, things started to slip; the original "release date" of December 17, 2003 came and went, with only a token update to the website. The second anniversary of the project came and went, and the whole thing just quietly shut down. I hacked off and on until the summer of 2004, and then stuffed the code into a .ZIP file, burned it to CD, and haven't opened it since.
Even in the intervening two years, things have changed. Two years ago, it was clear that a fixed-function raytracing card had no place in the market - but a programmable one had a good shot. The problem was, developing a proper emulator for a programmable system would require a full rewrite of my prototype code; more importantly, bringing the product to market would require substantial involvement (and money) from a hardware development team. I put the project away not because it was no longer worth pursuing, but because I no longer had the time - I'd buckled to the temptations of a day job, and had committed my remaining time to working with Egosoft.
After the day job went down the crapper, I found myself again with a surplus of time, but also a decent bit of burnout, and not much desire to work on many side projects. Over the past few months, that's clearly changed, with stuff like TKC2 and the Epoch language grabbing my attention.
Through it all, though, there's been a little nagging doubt in the back of my mind: what about Freon?
I've thought it over at length, and I think the time for the product has come and gone. There was a window of opportunity for a couple of years, but it's now closed. Shader Model 4 and the increasing convergence of CPU and GPU technology has basically eliminated the need for dedicated raytracing hardware. More importantly, programmable shaders in general have eliminated the quality disparity between rasterized and raytraced graphics. There's simply no need for raytracing in the market; there's no place for it.
Yet.
I think another window will open in a few years. Raytracing is inherently a more efficient and elegant rendering method than scanline conversion, and due to its power, it will eventually supplant traditional polygon-rasterization methods. This will particularly become true when hardware is fast enough to genuinely simulate complex lighting effects (global illumination, subsurface scattering, participating media, fully dynamic lights and geometry, and so on) rather than just making hackish approximations.
That time is a long ways off, though, and even that future has no place for dedicated raytracing hardware. Instead, I think the future is shaping up to hold something different.
The first step was AMD's integration of the memory controller and CPU. The AMD/ATi acquisition promises to provide further changes. Dual-core technology has hinted at the challenges to come, and a close look at multi-core processor plans of the future shows that there's no shortage of difficulties to overcome.
Perhaps most important, though, is the role of programming languages in all of this. Freon was killed, by and large, by programmability; with technology developed as far as it has, the age of fixed-function hardware is over. Programmability will be king for the foreseeable future, and likely until the von Neumann architecture is replaced entirely. But programmability requires programming languages, and the languages we have now are not enough.
For a few hours, I pondered the tradeoff of reviving the Freon project (which, after all, still has some promising proprietary technology) versus work on the Epoch language. Both have some potential, and both would require tremendous amounts of effort to really accomplish anything.
The more I think about it, though, the more I'm convinced that the future of both projects is one and the same. It lies down a twisting but all-important road of processing advancements, at the logical conclusion of core-proliferation and the challenges of writing multiprocessing-capable software.
And just because I'm a smug bastard, I'm going to make you wait to see what I think that future looks like 
| |
In locus hic, omnes res dementes sunt.
|
| S | M | T | W | T | F | S | | | | | 3 | | 5 | 6 | | | 9 | | 11 | 12 | 13 | | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | | | 25 | | 27 | | 29 | 30 | | | |
OPTIONS
Track this Journal
ARCHIVES
July, 2009
June, 2009
May, 2009
April, 2009
March, 2009
February, 2009
January, 2009
October, 2008
September, 2008
August, 2008
July, 2008
June, 2008
May, 2008
April, 2008
March, 2008
February, 2008
January, 2008
December, 2007
November, 2007
October, 2007
September, 2007
August, 2007
July, 2007
June, 2007
May, 2007
April, 2007
March, 2007
February, 2007
January, 2007
December, 2006
November, 2006
October, 2006
September, 2006
August, 2006
July, 2006
June, 2006
May, 2006
April, 2006
March, 2006
February, 2006
January, 2006
December, 2005
November, 2005
October, 2005
|
