Battle of the Programmers
Saturday, 3. December 2005, 14:05:41
There are two kinds of programmers in the world. Real programmers and amateurs.
If you want a good example of which is which, go look at OSNews for real programmers. For amateurs, you can find a good sampling at Slashdot althought there are some real programmers there too. But it's easier to pick out the idiots because they announce themselves so flamboyantly.
And it's no wonder. To write an Operating System, you have to understand how the computer works. Right there, you have an advantage over everyone else. I don't know how many times I have to say it, but you cannot become a programmer unless you know how the hardware works. At the very least, how the CPU works. I find it amazing that some people graduate Computer Science with a degree and have no clue how computers work.
Hardware programmers know the difference between a right shift for signed numbers and unsigned numbers. They are two different operators even though the symbol is the same in higher languages. In Java, they had to add an operator. Hardware programmers are frustrated that there's no operator that will give you both the quotient and the remainder at the same time. Hardware programmers find it annoying that you don't have access to the carry bit or other CPU flags in higher languages. Hardware programmers hate that they can't multiply two 32-bit numbers together and get the 64-bit result in higher languages. Same goes for dividing 64-bit integer with a 32-bit integer. Everything mentioned here should be standard in every programming language.
This is what people who've only used high level languages don't get. That you're in shackles. You're being restrained. I don't need a safety net. I know what I'm doing. I don't have to be protected from myself. And I know many of you reading this don't need to be protected either.
This whole idea of protecting programmers from the hardware is a crock and I'll tell you why. What was their reason for not hitting the hardware directly? There were many reasons. The main ones were that there was no way to share resources and so that you couldn't inadvertantly cause damage in either the device or the data stored on it. And having a standard way of accessing these resources would make programming easier. All valid points. So why did they simply create another layer of SIMULATED hardware on top? We already had a hardware layer, so why did they create another one? What I'm getting at is that every OS has a different way of doing things. It's a complete and utter joke. How is this any different than when we were hitting the hardware directly? There's no transparency. We still have to write custom code for every OS just as we did before for every piece of hardware.
Now, I'm not for accessing all hardware directly. What I AM for is being able to do it if I want to. It's my computer. I should be able to do what I want. And if other users like it, they should be able to do it too.
Also, I want the shackled to fall off. I want to be able to extend my programming language at any time. If I want to use 32*32=64bit operations, I should be able to. If I want to only get the high order of that operation, I should be able to. If I want to access the hardware flags to make certain operations easier and faster, I should be able to. Amateurs have never used real power, so they don't know what they're missing. They have no clue how much better their software could be. So they think that what they're using is great.
Here's a newsflash for everyone. If you think the tools you are using are great, you are an amateur. Doesn't matter if you've been using them for 30 years or 3 years. You're an amateur. Real programmers always want more out of their tools. Real programmers are always customizing their tools to make them better. Right now, I can't think of a single tool that lets you expand your tool with relative ease other than maybe emacs. I never use emacs, but a friend of mine does and he has a lot of tools that he wrote into it and really improves his productivity.
Most programmers today don't even know how to use MMX, SSE or even what they do. Isn't that insane? All that processing power and it goes unused. Here's another one that I find shameful. Most programmers don't know how to properly use the cache. How pityful is that? Programming without properly using the cache is like using an old SuperPet. Go Google it if you don't know what it is. It was interesting for its time, but my point is that you may as well go use old technology if you're not willing to use current technology.
Maybe it's a ploy by big companies so that in 10 years from now, they can release this great new language that supports vector programming and all these recycled technologies. This will happen anyhow. If not this, then something else.
Here's my problem with high level languages. Let's say you have to process a LOT of data. It can be complicated or simple, it doesn't matter. Maybe it's as simple as converting an image from 16bit to 32bit. Or as complicated as processing a lot of statistical data that you've loaded into memory. Most would go through each one in sequence, process it and store the results. This is slow.
The reason that it helps to understand how computers work is the following. If you've never worked with the cache, listen up... this example should blow you away. The cache works well with memory that's used often. So what you do is figure out what your page size is on your computer. Usually 4K on Pentiums. Then allocate that much memory (or some multiple of it) that is on a page boundary. Then you fill that memory with as much data as you can. Simply copy it over. Prefetch the next data item, but do not load it in. This cannot be done in high level languages. But what it does is loads the next page of memory into the cache so that it's readily available once you're done processing the current batch of data. This means the data can be loaded from cache and not from RAM which takes longer. Even as you're copying the data into the allocated memory, prefetch data that's a little further ahead so that by the time you need it, it's in the cache already thus speeding up access. Otherwise, your program will be on average about 2-20 times slower. Now process the data while it's in this page-boundary allocated buffer. When you're done processing the whole batch, copy it back out to its destination using non-temporal stores. This will ensure that it writes it out directly to memory and not "pollute" the cache. This simply means that it won't disturb the cache that you're using to load the data. Cache is limited, so you don't want to use more memory than there is cache. Now repeat until you're done.
It seems on the surface to be crazy that copying data TWICE (once in and once out). Then to process the data in this buffer (reading and storing results yet again)... that this would be 2 to 20 times faster than processing it directly. Sometimes, you can get 100 times faster. But alas, using this technique is impossible in high level languages. On another note, how many programmers do you think know of this technique? Better yet, how many programmers would believe that this technique of doing MORE work is actually faster? Not many.
And we're making advancements in computing by using VM's? Something that REALLY doesn't let us use current technology. In C or C++, I can get SOME of the speedups I've mentioned above. I can align my data on a page boundary. I can prefetch the next page by actually reading one byte or word from the next batch and discarding it. This will in effect load the next page into the cache. I can process the data in the allocated page. However, I cannot do non-temporal stores. But sometimes, depending on what you're doing, this is not so bad. But in Java, you can't do any of this. And people still try to convince ME, ME!!! of all people that Java can be just as fast as C or C++. Well, up my nose with a rubber hose. Don't know if you've ever watched reruns of Mr. Kotter, but I've got a few crazy lessons for you.
And I don't have a problem with Java. What? No, it's people claiming things about Java that simply aren't true. That's what I don't like. Sure, the VM blocks me from doing things, but if you don't need those features, then fine. Java is used a lot for servlets for example. That's fine. Just don't claim that Java is something it is not. That's why I talk smack about Java. Because they claim it's a good general purpose language, yet it has a VM. If it has a VM, it can't be general purpose. It's blocking me from doing simple things. So that's why I say the things I do about Java. And no unsigned numbers. Please! That's just plain dumb. I'd be ashamed if I designed something like that. Ok, so I do have problems with Java. Can't hide the truth.
Technology comes in the form of hardware. If we're blocked from it, how can we become more technologically advanced? If new technology is beyond our grasp and locked away, what good is it? That will be our heritage in the computing world. In the future, our descendants will look back and wonder why we would voluntarilly put ourselves in shackles. All that power, but we refuse to use it. Not only that, but we refuse to acknowledge that there is a better way. We refuse to learn something new once we're satisfied with the current tool. We say it doesn't matter if it could be better. It works. That's all that matters. No, we can expend the same amount of effort and produce much better code. If you consider it effort to learn new things, you may consider a career change. Oh wait... that would involve learning something new.
We have to start asking questions. Is what we're doing the best way it can be done? Is this software going to be around 10 years from now or is this just a hack job? Will we move forward or will we be stuck continuously re-inventing the wheel? When new technology is made available, can we be the first to take advantage of it? Or will we be locked away from it forever? Are we satified with this situation?
I hope some of this has sparked some ideas and opened up a little corner of your mind into what's possible with the technology that's right beside you. It's right there waiting for you to use it to its full potential.
If you want a good example of which is which, go look at OSNews for real programmers. For amateurs, you can find a good sampling at Slashdot althought there are some real programmers there too. But it's easier to pick out the idiots because they announce themselves so flamboyantly.
And it's no wonder. To write an Operating System, you have to understand how the computer works. Right there, you have an advantage over everyone else. I don't know how many times I have to say it, but you cannot become a programmer unless you know how the hardware works. At the very least, how the CPU works. I find it amazing that some people graduate Computer Science with a degree and have no clue how computers work.
Hardware programmers know the difference between a right shift for signed numbers and unsigned numbers. They are two different operators even though the symbol is the same in higher languages. In Java, they had to add an operator. Hardware programmers are frustrated that there's no operator that will give you both the quotient and the remainder at the same time. Hardware programmers find it annoying that you don't have access to the carry bit or other CPU flags in higher languages. Hardware programmers hate that they can't multiply two 32-bit numbers together and get the 64-bit result in higher languages. Same goes for dividing 64-bit integer with a 32-bit integer. Everything mentioned here should be standard in every programming language.
This is what people who've only used high level languages don't get. That you're in shackles. You're being restrained. I don't need a safety net. I know what I'm doing. I don't have to be protected from myself. And I know many of you reading this don't need to be protected either.
This whole idea of protecting programmers from the hardware is a crock and I'll tell you why. What was their reason for not hitting the hardware directly? There were many reasons. The main ones were that there was no way to share resources and so that you couldn't inadvertantly cause damage in either the device or the data stored on it. And having a standard way of accessing these resources would make programming easier. All valid points. So why did they simply create another layer of SIMULATED hardware on top? We already had a hardware layer, so why did they create another one? What I'm getting at is that every OS has a different way of doing things. It's a complete and utter joke. How is this any different than when we were hitting the hardware directly? There's no transparency. We still have to write custom code for every OS just as we did before for every piece of hardware.
Now, I'm not for accessing all hardware directly. What I AM for is being able to do it if I want to. It's my computer. I should be able to do what I want. And if other users like it, they should be able to do it too.
Also, I want the shackled to fall off. I want to be able to extend my programming language at any time. If I want to use 32*32=64bit operations, I should be able to. If I want to only get the high order of that operation, I should be able to. If I want to access the hardware flags to make certain operations easier and faster, I should be able to. Amateurs have never used real power, so they don't know what they're missing. They have no clue how much better their software could be. So they think that what they're using is great.
Here's a newsflash for everyone. If you think the tools you are using are great, you are an amateur. Doesn't matter if you've been using them for 30 years or 3 years. You're an amateur. Real programmers always want more out of their tools. Real programmers are always customizing their tools to make them better. Right now, I can't think of a single tool that lets you expand your tool with relative ease other than maybe emacs. I never use emacs, but a friend of mine does and he has a lot of tools that he wrote into it and really improves his productivity.
Most programmers today don't even know how to use MMX, SSE or even what they do. Isn't that insane? All that processing power and it goes unused. Here's another one that I find shameful. Most programmers don't know how to properly use the cache. How pityful is that? Programming without properly using the cache is like using an old SuperPet. Go Google it if you don't know what it is. It was interesting for its time, but my point is that you may as well go use old technology if you're not willing to use current technology.
Maybe it's a ploy by big companies so that in 10 years from now, they can release this great new language that supports vector programming and all these recycled technologies. This will happen anyhow. If not this, then something else.
Here's my problem with high level languages. Let's say you have to process a LOT of data. It can be complicated or simple, it doesn't matter. Maybe it's as simple as converting an image from 16bit to 32bit. Or as complicated as processing a lot of statistical data that you've loaded into memory. Most would go through each one in sequence, process it and store the results. This is slow.
The reason that it helps to understand how computers work is the following. If you've never worked with the cache, listen up... this example should blow you away. The cache works well with memory that's used often. So what you do is figure out what your page size is on your computer. Usually 4K on Pentiums. Then allocate that much memory (or some multiple of it) that is on a page boundary. Then you fill that memory with as much data as you can. Simply copy it over. Prefetch the next data item, but do not load it in. This cannot be done in high level languages. But what it does is loads the next page of memory into the cache so that it's readily available once you're done processing the current batch of data. This means the data can be loaded from cache and not from RAM which takes longer. Even as you're copying the data into the allocated memory, prefetch data that's a little further ahead so that by the time you need it, it's in the cache already thus speeding up access. Otherwise, your program will be on average about 2-20 times slower. Now process the data while it's in this page-boundary allocated buffer. When you're done processing the whole batch, copy it back out to its destination using non-temporal stores. This will ensure that it writes it out directly to memory and not "pollute" the cache. This simply means that it won't disturb the cache that you're using to load the data. Cache is limited, so you don't want to use more memory than there is cache. Now repeat until you're done.
It seems on the surface to be crazy that copying data TWICE (once in and once out). Then to process the data in this buffer (reading and storing results yet again)... that this would be 2 to 20 times faster than processing it directly. Sometimes, you can get 100 times faster. But alas, using this technique is impossible in high level languages. On another note, how many programmers do you think know of this technique? Better yet, how many programmers would believe that this technique of doing MORE work is actually faster? Not many.
And we're making advancements in computing by using VM's? Something that REALLY doesn't let us use current technology. In C or C++, I can get SOME of the speedups I've mentioned above. I can align my data on a page boundary. I can prefetch the next page by actually reading one byte or word from the next batch and discarding it. This will in effect load the next page into the cache. I can process the data in the allocated page. However, I cannot do non-temporal stores. But sometimes, depending on what you're doing, this is not so bad. But in Java, you can't do any of this. And people still try to convince ME, ME!!! of all people that Java can be just as fast as C or C++. Well, up my nose with a rubber hose. Don't know if you've ever watched reruns of Mr. Kotter, but I've got a few crazy lessons for you.
And I don't have a problem with Java. What? No, it's people claiming things about Java that simply aren't true. That's what I don't like. Sure, the VM blocks me from doing things, but if you don't need those features, then fine. Java is used a lot for servlets for example. That's fine. Just don't claim that Java is something it is not. That's why I talk smack about Java. Because they claim it's a good general purpose language, yet it has a VM. If it has a VM, it can't be general purpose. It's blocking me from doing simple things. So that's why I say the things I do about Java. And no unsigned numbers. Please! That's just plain dumb. I'd be ashamed if I designed something like that. Ok, so I do have problems with Java. Can't hide the truth.
Technology comes in the form of hardware. If we're blocked from it, how can we become more technologically advanced? If new technology is beyond our grasp and locked away, what good is it? That will be our heritage in the computing world. In the future, our descendants will look back and wonder why we would voluntarilly put ourselves in shackles. All that power, but we refuse to use it. Not only that, but we refuse to acknowledge that there is a better way. We refuse to learn something new once we're satisfied with the current tool. We say it doesn't matter if it could be better. It works. That's all that matters. No, we can expend the same amount of effort and produce much better code. If you consider it effort to learn new things, you may consider a career change. Oh wait... that would involve learning something new.
We have to start asking questions. Is what we're doing the best way it can be done? Is this software going to be around 10 years from now or is this just a hack job? Will we move forward or will we be stuck continuously re-inventing the wheel? When new technology is made available, can we be the first to take advantage of it? Or will we be locked away from it forever? Are we satified with this situation?
I hope some of this has sparked some ideas and opened up a little corner of your mind into what's possible with the technology that's right beside you. It's right there waiting for you to use it to its full potential.
WIDGETIZE
How to use Quote function: