Those who can, do. Those who can't do, teach. Those who can't teach...
And those who can't [Fill in the blank] make a website about it? I wonder how many more iterations until you get down to making a website about it.
I always sort of wondered about people who make a big website about something. As the population expands, being a famous [again, fill in the blank] gets harder and harder. As Kurt Vonnegut put it, before technology there's be a storyteller for the village, one guy who wasn't afraid of anything, another good at gardening, etc. Scale that up to a nation and things get much harder. Even in the super mega bookstores like Barnes and Noble there's only so much space, and any author is also competing against all the classics of the last 3000 years as well. In the last century, writing has gone from very competive to a long shot to a one in a billion shot at being the next JK Rowling or Robert Jordan.
Scale it up to an entire planet and marketing and con artistry and sheer dollars will overwhelm any native ability; I doubt most people who are the most famous for much of anything is really the best at whatever it is, aside from places like sports where the proof is obvious. Surely Britney Spears is not the best singer, or entertainer, or well anything of any kind, for example. It's probably not so bad for other areas but I imagine it applies to science and technology as well. I certainly know how much an ivy league degree means now (absolutely nothing) but even to me I'm sure I'd pick any guy who went to somewhere I'd heard of over some random school, all else being equal - you have to choose on something after all.
But this post was not about fairness, but sadness. What's scary is that uselessness is slowly but surely spreading to all aspects of our society. You can't even be a farmer any more, for god's sake. Not unless you were born with 50-100 acres of land with an established farm or millions of dollars.
Really, most people are just useless. That's the real truth. All real production factors are limited by resources, not labor or intelligence. A tiny percentage of the populance does the real work needed to build and run what's needed, usually for low pay and zero appreciation. The rest is all busywork that doesn't truly affect anything at all.
It's like an ever expanding proletariat of people who have no ability to possibly be the thing they are best at, or even ability to be genuinely useful at all. If your talent is dancing or singing you will have a one in a million shot to be employed enough to live off of at all let alone someone famous for it. But no matter how outclassed you are by others in a field, you can still make a website about it.
Which is sad because it really is giving up. It's a lot of work to spend on such nonsense, and though often you can make a living operating a website it is like being a professional baseball fan instead of being a professional baseball player.
Of course the irony is here I am talking about this...on my personal website.
Monday, February 8, 2010
Saturday, February 6, 2010
Infinitely fast or infinitely smooth?
It's funny how if you avoid all the 'best practices' conmen try to pass off on us how easily things dovetail together into awesome performance and great usability. As opposed to insane complexity and a stupefying learning curve where even someone with seemingly infinite ability to soak up raw information can't ever keep more than 10% of all the rules, antirules, patterns, antipatterns and exceptions to the rules...and even rules about exceptions.
Of the random, seemingly pointless tasks I've taken on, one that strangely makes life a lot easier is to take a bunch of points and smooth them out. But points that belong to an object, that have to smooth out without shrinking the mesh or having one of a billion possible bizarre side effects.
Now, it's hardly a novel task, and in any sane world every 3d package would have this available. But for some reason even the most expensive software that does this sucks basic task thats critical to any 3d endeavor sucks. A lot. Like, a whole lot. In ways you couldn't even expect something written by a lazy 12 year old could suck, let alone something made by supposedly the best (or at least best paid and best known) programmers in the world.
So at first I worked with the tools within Maya for this. The results were horrific. Basically, your work is completely destroyed just by smoothing. Then I worked with their scripts a bit. It worked, but dear god it was so slow. But, at least it was correct. Then I moved to C++, but still using the Maya data structures. The speedup was over 1500 times.
Really, that was fast enough for my purposes, but for unrelated reasons I had to make my own data structures that would be of use here. So, I figured I may as well stick them in Maya and see how it did.
And wow. I can literally smooth faster than I can measure. No matter how many verts I do (within the limits of a long) the timer returns nothing.
I was sure it was an error in my benchmarking, but I took it back into Maya and got the same results. I can finally have perfect smoothing without volume loss to any level on multimillion vert meshes without shrinking, and without waiting for 9 minutes like with zbrush and then getting a bunch of points in the middle of nowhere because some idiot doesn't know how to calculate a cross product properly and can't be bother to fix a bug that's been in there for about 80 years.
I'd honestly simply not have thought this was possible, and the interesting part is I didn't go on a manic speed quest but simply did things in a nonretarded manner and that made everything fall into place correctly. And it's not even some clever algorithm trick, just solid programming. All I do is calculate what the value should be exactly, not any tricky sticking things to curves or something like that (which never seems to work right, btw).
Of the random, seemingly pointless tasks I've taken on, one that strangely makes life a lot easier is to take a bunch of points and smooth them out. But points that belong to an object, that have to smooth out without shrinking the mesh or having one of a billion possible bizarre side effects.
Now, it's hardly a novel task, and in any sane world every 3d package would have this available. But for some reason even the most expensive software that does this sucks basic task thats critical to any 3d endeavor sucks. A lot. Like, a whole lot. In ways you couldn't even expect something written by a lazy 12 year old could suck, let alone something made by supposedly the best (or at least best paid and best known) programmers in the world.
So at first I worked with the tools within Maya for this. The results were horrific. Basically, your work is completely destroyed just by smoothing. Then I worked with their scripts a bit. It worked, but dear god it was so slow. But, at least it was correct. Then I moved to C++, but still using the Maya data structures. The speedup was over 1500 times.
Really, that was fast enough for my purposes, but for unrelated reasons I had to make my own data structures that would be of use here. So, I figured I may as well stick them in Maya and see how it did.
And wow. I can literally smooth faster than I can measure. No matter how many verts I do (within the limits of a long) the timer returns nothing.
I was sure it was an error in my benchmarking, but I took it back into Maya and got the same results. I can finally have perfect smoothing without volume loss to any level on multimillion vert meshes without shrinking, and without waiting for 9 minutes like with zbrush and then getting a bunch of points in the middle of nowhere because some idiot doesn't know how to calculate a cross product properly and can't be bother to fix a bug that's been in there for about 80 years.
I'd honestly simply not have thought this was possible, and the interesting part is I didn't go on a manic speed quest but simply did things in a nonretarded manner and that made everything fall into place correctly. And it's not even some clever algorithm trick, just solid programming. All I do is calculate what the value should be exactly, not any tricky sticking things to curves or something like that (which never seems to work right, btw).
Saturday, January 23, 2010
Optimizing and...nonoptimizing
I tried to take the high road and not post STL benchmarks compared to my own code, but I can see it's unavoidable but I will have to wait til I have that code under my nose to do so.
Still, though, all of the conflict over optimization is mindboggling. I do believe that optimization is usually a mistake, at least for the typical programmer. For lib writers and 3D tool apps it's absolutely vital and if you can't handle this well you may as well just watch it's always sunny in philadelphia instead of wasting your time.
The thing that really kills me about stl/boost is that the size of code just EXPLODES beyond reason with just a few includes. Proponents yammer on about compilers making better optimization with strict types to work with but seriously. Even if that were so (which is ridiculous) you now have 1728 copies of your templated code distributed through all your object files, which will get inlined right and left as needed during optimization (about the ONLY optimization compilers ever do right). Suddenly just using some cout statements has made your 2 meg project into 16 megs of code!
8 mb of instruction cache is the norm now, the same size as instruction cache, which blows me away. It takes a LOT of nontemplated code to make an obj that size. I mean, a hell of a lot. Yet, you are guaranteed that a hello stl app is at least 3-4 mb and any medium sized project using 'best practices' will be in the hundreds or the gig range.
Helpfully, microsoft tries to push you into the paradigm of having ALL obj files include ALL headers and have ALL projects as DLLs. This insane slice of hell means that you will be compiling days and days and DAYS in a large size project, and of course then you can't reasonably statically link to it. So you use a DLL, yet another case where someone 'solves' probems they created themselves by creating a problem that's worse than the original problem and which is almost impossible to extricate yourself from.
For a long time I wondered why instruction cache had gotten so huge. Now I know, and the answer is rather pathetic.
Still, though, all of the conflict over optimization is mindboggling. I do believe that optimization is usually a mistake, at least for the typical programmer. For lib writers and 3D tool apps it's absolutely vital and if you can't handle this well you may as well just watch it's always sunny in philadelphia instead of wasting your time.
The thing that really kills me about stl/boost is that the size of code just EXPLODES beyond reason with just a few includes. Proponents yammer on about compilers making better optimization with strict types to work with but seriously. Even if that were so (which is ridiculous) you now have 1728 copies of your templated code distributed through all your object files, which will get inlined right and left as needed during optimization (about the ONLY optimization compilers ever do right). Suddenly just using some cout statements has made your 2 meg project into 16 megs of code!
8 mb of instruction cache is the norm now, the same size as instruction cache, which blows me away. It takes a LOT of nontemplated code to make an obj that size. I mean, a hell of a lot. Yet, you are guaranteed that a hello stl app is at least 3-4 mb and any medium sized project using 'best practices' will be in the hundreds or the gig range.
Helpfully, microsoft tries to push you into the paradigm of having ALL obj files include ALL headers and have ALL projects as DLLs. This insane slice of hell means that you will be compiling days and days and DAYS in a large size project, and of course then you can't reasonably statically link to it. So you use a DLL, yet another case where someone 'solves' probems they created themselves by creating a problem that's worse than the original problem and which is almost impossible to extricate yourself from.
For a long time I wondered why instruction cache had gotten so huge. Now I know, and the answer is rather pathetic.
Friday, January 22, 2010
And most importantly, how do you stop yourself?
I really wish I'd not gotten into all this in the first place, especially since chances are no matter how much cool stuff I do I probably won't be able to get a paycheck of any sort out of it for years on end, if ever. Let alone translate all my work into it into hookers and blow.
And it just goes on and on. Every place I look in 3D software, tools are immature, core implementation is spotty or lacking, algorithms are naieve, libraries are a painful wreck of 'best practices' and overgenericity that make them unusable and yield very poor performance. It's hard to limit yourself to one thing, especially when you are trying to build everything on the shifting and treacherous foundation of the code of random strangers.
You can't depend on their code at all, except that it will largely be bad and usually have a ridiculous learning curve for trivial uses. Not that all my code is stellar; I try to only do what's useful for me and not get too caught up in perfection, but oftentimes you really do need that speed and/or usability to get anywhere. And you always need to have the stability that only comes through using something a lot. Not to mention simply wholly understanding something, which only seems to come from actually implementing it yourself.
Now I have to restrain myself from writing a good realtime ray tracer. And it's so hard to hold back, though such a ridiculous prospect. How long would it take? 2 years? I am sure someone could write something a lot faster with the right experience, though likely not with real time usefulness/awesomeness. It's hard to say what that would take, but I believe it is within reach; it's possible, and it's not even a matter of inventing anything.
All it would take is one crazy man with a lot of diet dr pepper, a few years locked in a room with a computer, and enough algorithm and C++ optimization knowledge to blow nearly anyone else's code benchmarks out of the water without breaking a sweat. Which describes me to a t, except I am sick to death of sitting alone and programming all day, and I don't have infinite money so I couldn't do that forever even if I wanted to.
And it just goes on and on. Every place I look in 3D software, tools are immature, core implementation is spotty or lacking, algorithms are naieve, libraries are a painful wreck of 'best practices' and overgenericity that make them unusable and yield very poor performance. It's hard to limit yourself to one thing, especially when you are trying to build everything on the shifting and treacherous foundation of the code of random strangers.
You can't depend on their code at all, except that it will largely be bad and usually have a ridiculous learning curve for trivial uses. Not that all my code is stellar; I try to only do what's useful for me and not get too caught up in perfection, but oftentimes you really do need that speed and/or usability to get anywhere. And you always need to have the stability that only comes through using something a lot. Not to mention simply wholly understanding something, which only seems to come from actually implementing it yourself.
Now I have to restrain myself from writing a good realtime ray tracer. And it's so hard to hold back, though such a ridiculous prospect. How long would it take? 2 years? I am sure someone could write something a lot faster with the right experience, though likely not with real time usefulness/awesomeness. It's hard to say what that would take, but I believe it is within reach; it's possible, and it's not even a matter of inventing anything.
All it would take is one crazy man with a lot of diet dr pepper, a few years locked in a room with a computer, and enough algorithm and C++ optimization knowledge to blow nearly anyone else's code benchmarks out of the water without breaking a sweat. Which describes me to a t, except I am sick to death of sitting alone and programming all day, and I don't have infinite money so I couldn't do that forever even if I wanted to.
Monday, January 18, 2010
Math, science, and computer science
One thing I strongly expected to be true, but turned out to be completely untrue is the idea that math is helpful for programming. It does seem to be helpful for programming MATH, but in general programming, not so much. And with the sheer volume of problems out there even when programming math I still have to look things up constantly and it's never something simple that you might remember from taking math classes years back.
Nor did it seem to increase my problem solving skills. Strangely, the biggest thing helpful there was, you know, solving lots and lots of problems. Not to mention being born smart, if you aren't, you are probably out of luck for programming much more than a dynamic webpage of some kind.
Not that I am advocating computer science, and really, what is that? I should know by now if anyone, but the best I can tell is it's algorithms. Which can mean anything, but specifically you could say it's a form of math. So maybe math is useful? Except there's mountains of applied math out there, all of which is useless if you don't actually apply it (go figure). The theoretical/proof side of math is just like algorithms, but not applied to the thing you actually care about but completely random things! So if you go that route, why not go with prolems in your domain? Of course, many a 'computer science' course is quite useless, even meaningless crap so theoretical math is much more useful than that.
But what really gets me, is science, and scientists. Or 'scientists', I suppose. No doubt there's many a brilliant scientist in the realm of 'hard' sciences, but for god's sake there's a lot of 'scientists' who don't know what science even means.
Of course ironically I am not sure how to define computer science, but that's because it's an ill defined, amorphous field. Scientific method is not. It's clean, pure, simple and beautiful. And easy to understand. Yet, most every phd holding 'scientist' I have known has no idea what the hell it is!
Math is simple, too. You have proofs, and definitions, and systems you create which are self contained and artificial. That is why you can prove anything at all. For science, it's the opposite. We have all these artificial systems and theories that (generally) make sense in and of themselves but the underlying premises and assumptions can never, ever be totally known.
At the extreme, whatever we do we can't prove we are not brains in jars or delusional madmen. That black is not orange. Anything. Nothing at all, because all perception hinges on assumptions that seem to hold true but which might have no basis in reality at all. Even at the most fundamental levels where we are pretty sure what's going on, we get constant minor refinements.
In short, we have evidence, not proof. This probably seems like nitpicking but it is probably the stem of 70% of the bad logic I see from scientists. And I see it constantly, constantly, constantly, in just about evry field. Halfassed papers that don't prove a thing, or offer a shred of evidence for or against. Braindead experiments that will obviously never yield results but cost millions.
And really, shouldn't you know what your own job is? It kind if blows me away, especially when we are talking people with phds and their own frickin research staff making unbelievably stupid and obviously untrue statements at every turn. I know I sound like a know it all, but I think it's more like it turns out regardless of the field or place or time, 80% of people are almost totally incompetent/irrelevant. I'm sure only a small percentage of those people really push anything forward in society at all. Not that I claim to be one, though I hope to at least be in the not totally useless 20%, but then no one thinks they are the idiot. And as I said before there's no way to prove otherwise (though I can offer evidence here and there) so maybe I'm the idiot.
Nor did it seem to increase my problem solving skills. Strangely, the biggest thing helpful there was, you know, solving lots and lots of problems. Not to mention being born smart, if you aren't, you are probably out of luck for programming much more than a dynamic webpage of some kind.
Not that I am advocating computer science, and really, what is that? I should know by now if anyone, but the best I can tell is it's algorithms. Which can mean anything, but specifically you could say it's a form of math. So maybe math is useful? Except there's mountains of applied math out there, all of which is useless if you don't actually apply it (go figure). The theoretical/proof side of math is just like algorithms, but not applied to the thing you actually care about but completely random things! So if you go that route, why not go with prolems in your domain? Of course, many a 'computer science' course is quite useless, even meaningless crap so theoretical math is much more useful than that.
But what really gets me, is science, and scientists. Or 'scientists', I suppose. No doubt there's many a brilliant scientist in the realm of 'hard' sciences, but for god's sake there's a lot of 'scientists' who don't know what science even means.
Of course ironically I am not sure how to define computer science, but that's because it's an ill defined, amorphous field. Scientific method is not. It's clean, pure, simple and beautiful. And easy to understand. Yet, most every phd holding 'scientist' I have known has no idea what the hell it is!
Math is simple, too. You have proofs, and definitions, and systems you create which are self contained and artificial. That is why you can prove anything at all. For science, it's the opposite. We have all these artificial systems and theories that (generally) make sense in and of themselves but the underlying premises and assumptions can never, ever be totally known.
At the extreme, whatever we do we can't prove we are not brains in jars or delusional madmen. That black is not orange. Anything. Nothing at all, because all perception hinges on assumptions that seem to hold true but which might have no basis in reality at all. Even at the most fundamental levels where we are pretty sure what's going on, we get constant minor refinements.
In short, we have evidence, not proof. This probably seems like nitpicking but it is probably the stem of 70% of the bad logic I see from scientists. And I see it constantly, constantly, constantly, in just about evry field. Halfassed papers that don't prove a thing, or offer a shred of evidence for or against. Braindead experiments that will obviously never yield results but cost millions.
And really, shouldn't you know what your own job is? It kind if blows me away, especially when we are talking people with phds and their own frickin research staff making unbelievably stupid and obviously untrue statements at every turn. I know I sound like a know it all, but I think it's more like it turns out regardless of the field or place or time, 80% of people are almost totally incompetent/irrelevant. I'm sure only a small percentage of those people really push anything forward in society at all. Not that I claim to be one, though I hope to at least be in the not totally useless 20%, but then no one thinks they are the idiot. And as I said before there's no way to prove otherwise (though I can offer evidence here and there) so maybe I'm the idiot.
Sunday, January 10, 2010
Software Engineering
Well, it's easy to be critical, but I don't begrudge that professors tend to be out of touch with industry and 'the real world'. I don't think you need to be in the trenchs to know how to fight a war, theory is important and the bloody details of implementing something in an optimized manner are mindboggling. Now that doesn't excuse something like in Loki where the author uses a vector (!) inside his block implementation, but a real issue is how can someone completely and utterly divorced from the nitty gritty details of life come up with all of these 'best practices' for software engineering?
Not that mere years of experience give someone the yodalike wisdom to make such judgements. If anything I find the more experience someone has the more likely they are to rest on their laurels or to have moved into a position where again they have little to do with much of anything. Some programmers wind up much like pampered pets kept around simply because they have some deep inside knowledge of one little portion of a business that's completely critical, others get bumped into management or semimanagement.
I guess what it comes down to is that things in computerland tend to fall into two categories:
1. Intractable problems.
2. Complete bullshit.
I am certain it's in category one, but the response everyone has is to try to solve it with category 2. Which I guess is highly profitable if all you care about it wresting a few grushniks from the corporate treasure chest, but personally I like to feel in some sense I DO something that has some kind of forward progress and purpose. Even if the purpose is something completely insane in most people's minds.
But, I will agree with this much, which has stood since the dawn of time as something that applies to any problem.
1. Define your problem very very thoroughly and break it into pieces.
2. Break it down more.
3. Assign each bit to someone.
4. Force the people to interface their bits in a semi reasonable manner.
5. ???
6. Profit.
The rest is bullshit. For example, six sigma. What does that even mean? I've never seen a single person use this properly. Anyone trying to sound impressive using it is a moron in the first place, but still.
If you've worked on such a project, you know it means ABSOLUTELY NOTHING. It's like passing a law that you will have no downtime or bugs. You can quantify its nothingness by the thickness of the accompanying contracts. If it meant anything at all, anything, it wouldn't need to have a 300-500 page contract describing in painful detail just what it means and what is expected. And no one in their right fucking mind would EVER sign anything that EVER put them liable for something to work bug free at all times and never go down, and if you look closely there's very little liability indeed. If someone signs off there's no bugs, then there's no bugs for the purprose of the contract...so what is the point? Only a conman would ever even come up with such a thing.
And, availability is nothing to do with coding. Unless you use a bunch of microsoft servers that need to be rebooted constantly (though they are improved dramatically in last 5 years), high availability is easy. EASY. That's what a sysadmin is for. You can have 99.999% uptime just by having a normal PC and reinstalling it any time oracle or whatever get's corrupted, and having another backup ready to flip on. Pay 1000 bucks a month for a colo and you have a guarantee even if terroists attack or something similar that your idiotic little project will continue running - and interestingly, bank systems seem to be down at least 4 hours a week every week. Sometimes days on end. So I have to question how 'mission critical' most projects really are, though certainly there's big bucks or big disaster involved in just a minute of downtime in some cases.
Not that mere years of experience give someone the yodalike wisdom to make such judgements. If anything I find the more experience someone has the more likely they are to rest on their laurels or to have moved into a position where again they have little to do with much of anything. Some programmers wind up much like pampered pets kept around simply because they have some deep inside knowledge of one little portion of a business that's completely critical, others get bumped into management or semimanagement.
I guess what it comes down to is that things in computerland tend to fall into two categories:
1. Intractable problems.
2. Complete bullshit.
I am certain it's in category one, but the response everyone has is to try to solve it with category 2. Which I guess is highly profitable if all you care about it wresting a few grushniks from the corporate treasure chest, but personally I like to feel in some sense I DO something that has some kind of forward progress and purpose. Even if the purpose is something completely insane in most people's minds.
But, I will agree with this much, which has stood since the dawn of time as something that applies to any problem.
1. Define your problem very very thoroughly and break it into pieces.
2. Break it down more.
3. Assign each bit to someone.
4. Force the people to interface their bits in a semi reasonable manner.
5. ???
6. Profit.
The rest is bullshit. For example, six sigma. What does that even mean? I've never seen a single person use this properly. Anyone trying to sound impressive using it is a moron in the first place, but still.
If you've worked on such a project, you know it means ABSOLUTELY NOTHING. It's like passing a law that you will have no downtime or bugs. You can quantify its nothingness by the thickness of the accompanying contracts. If it meant anything at all, anything, it wouldn't need to have a 300-500 page contract describing in painful detail just what it means and what is expected. And no one in their right fucking mind would EVER sign anything that EVER put them liable for something to work bug free at all times and never go down, and if you look closely there's very little liability indeed. If someone signs off there's no bugs, then there's no bugs for the purprose of the contract...so what is the point? Only a conman would ever even come up with such a thing.
And, availability is nothing to do with coding. Unless you use a bunch of microsoft servers that need to be rebooted constantly (though they are improved dramatically in last 5 years), high availability is easy. EASY. That's what a sysadmin is for. You can have 99.999% uptime just by having a normal PC and reinstalling it any time oracle or whatever get's corrupted, and having another backup ready to flip on. Pay 1000 bucks a month for a colo and you have a guarantee even if terroists attack or something similar that your idiotic little project will continue running - and interestingly, bank systems seem to be down at least 4 hours a week every week. Sometimes days on end. So I have to question how 'mission critical' most projects really are, though certainly there's big bucks or big disaster involved in just a minute of downtime in some cases.
Saturday, January 9, 2010
Google is going downhill
It's almost useless for searching on algorithms with all these damned links to paysites. As if someone would pay 20 bucks to read an article that turns out to be a paper filed so some idiot could (true story) patent counting sort 30 years after knuth invented it.
Subscribe to:
Posts (Atom)
