That it was wrong then doesn't mean it is wrong now. That it is wrong now doesn't mean when the claim is made again a year or two down the road it will be wrong then. --
It's a beautiful illustration of the gains you can make from having a full understanding of trivial processes such as arithmetic. Lots of programmers couldn't even get fixed point math from integers without a recipe book, let alone implement a floating point struct using only ints. They don't even see why to learn either, until they see something like this.
I thought I had a good understanding of computer arithmetic (I mean, fixed point was no problem, I could write a bignum in my sleep...) until I read Chapter 4 of Knuth's TAoCP. What an eye opener! It replaced all my little tricks with a comprehensive understanding of fundamentals. --
If a 16 year old wants to shoot people...it's better off happening in the Arcade at school!
"Take that! Who's too stupid to do an unlimate triple Pythagorean combo grammar fatality now, huh?!" the psychotic teen is reported to have yelled repeated on his rampage through the new experimental "Learning With Gibs" lab. His friends and teachers call him "a very bright kid" who did very well in traditional classes, but just lacked the reflexes, hand-eye coordination, and hundreds of hours of video-game experience typical to teenage boys, to keep up with the new system.
Fortunately, nobody was injured, as he simply lacked the |\/|/\|) 1337 5|1LLZ to shoot people before they ducked for cover and ran away. --
I'm always happy when stuff like this comes out because it drives down the prices in a domino effect: 2nd best has to be cheaper than best, 3rd best has to be cheaper than 2nd best, et c. down to the cheap junk I buy. --
Optimizing compilers aren't bad, they're overrated. Some people depend on them too much and tell newbies "don't even bother with assembler; the optimizing compiler does a better job than you ever will."
how did you find out where that 99% of your run-time was spent? In the profiler.
...if you're a sloppy hack who has no idea what's going on in his program.
better algorithms and data structures in the general case
I don't know about you, but I generally try to get the best algorithms and data structures I can in the first place, for the performance-critical portions, and decent ones in other situations.
The only time you should have to resort to assembly is when you have absolutely performance critical tasks, ie Interrupt Service Routines.
I agree that it is best to avoid assembler when possible, but different people have different ideas about performance-critical tasks. More importantly, if you don't do serious work in assembler sometimes, you won't understand the machine.
Basically, you're advocating the tools of a sloppy style of "slap it together, get it running, then try to make work well later" which also is sloppy in terms of skill development. Doing a half-assed job to get things out the door today might seem worthwhile now, but you never learn to do anything but a half-assed job. That attitude is why most software is bug-ridden bloated crap and most programmers aren't capable of anything else. --
A good programmer knows what is going on in his programs.
I believe profilers, debuggers, and optimizing compilers are vastly overrated. Profilers are primarily valuable for finding horribly inefficient code you assumed wouldn't be used enough to matter, then forgot about. Alternative? Never write horribly inefficient code. A little extra effort of keeping code clean and efficient often helps avoid bugs, too.
I fall firmly into the "debuggers are a seductive waste of time" category. The effort of guessing what is wrong is good training that gives you more awareness and control of your programs. The action of setting breakpoints and stepping through the code is more time-consuming than you may realize, and I don't believe it usually speeds up debugging.
Optimizing compilers might give you an extra 2X performance boost over all your code, but usually 0.1% of your code covers 99% of run-time, and if you hand-optimize that 0.1% you can usually get at least an 8X boost. More importantly, knowing the hardware intimately tells you what kind of algorithms will be efficient. For example: how expensive are function-pointer calls as compared to conditional branches? What kind of looped conditional structures will screw up the pipeline? How small a block can you access randomly without causing cache misses? Are multiplications really more expensive than additions? Et c.
These toys are no substitute for your skills as a programmer, and depending on them blunts those very skills. --
A common saying is that stock is worth whatever people will pay for it. IOW, printing up double stock on the same assets doesn't deflate its value as long as the market doesn't seem to notice. When the market crashes, then you'll see lots of blame aimed at these practices, but not before.
Bill Parish is needlessly hostile in his wording, and so comes off as a conspiracy theorist, but he's got the facts right. Employees are getting stock options and selling them (or holding them); consider the exactly equivalent situation of Microsoft selling the stock options and giving the money to employees who then keep the money (or buy stock options).
If this happened, MS would be reporting a loss, because the money from selling stock options is investment capital, not revenue, and cash salary is an expense, though giving out stock options as salary isn't.
This is common practice, because funding your business partly with a Ponzi scheme lets you lower prices below cost, and thus outcompete competitors. If someone is doing it, everybody has to do it, or be driven out of business.
The problem is its fundamental similarity to a pyramid scheme: the ones who get in and out before the crash get rich, but an ever-expanding pool of capital must be tapped. When it reaches its limit, either by running out of new investors, or people realizing that eventually they're going to run out of new investors, it crashes. It can still go for a few years yet, though, maybe as much as a decade, before all the suckers looking for easy money, and all the retirement and college funds are tapped out. Even longer if messed up countries get their act together long enough for their citizens to accumulate real wealth to gamble on bubble stocks.
It could even lead to a third world war, if China and India decide that their citizens shouldn't hand off half the country to pay debts to foreigners who got out in time. --
Bresenhan's algorithm is a fast, simple (jaggy)line-drawing algorithm. Basically, you figure out the longer dimension and step along it pixel by pixel, keeping track of how far off you are getting from the logical line (the "error"); when you're more than half a pixel out, you move one pixel along the shorter dimension.
The clever bit is finding ways to keep track of the error without using division.
While line drawing is fairly trivial, often accelerated, and usually handled by libraries, it's also good for figuring out paths of moving sprites and many other tasks similar to line drawing.
Read about it in the Black Book and immerse yourself in the coolness. --
I have a treasured old copy of "Zen of Graphics Programming", which was the book that introduced me to such beauties as Bresenham's algorithm and dirty rectangle animation. This guy will get your enthusiasm up for graphics the way Knuth teaches a love of elegant, efficient data structures and algorithms.
Somehow, I never got around to buying the Black Book, though. I read his articles on the Quake engine though, and they're as relevant today as they were the day they were printed (not that low-level engine design is relevant to a huge audience, but at the least it's a good workout for your brain). Definitely worth the bother to download and read.
Let's try not to all download at the same time, ok? They'll still be there a month from now. They really should have put up a clear notice giving permission to make mirrors; demand is sure to be as crushing as the shipping accident that decapitated me. --
Basically, the article claims it's a Ponzi scheme. They are paying their bills, creating the illusion of solvency, with new investment.
The tricky bit is where they pay a lot of their bills with stock, which they don't have to report as if they actually spent anything. Let's say they take a billion in revenue (because I'm too lazy to look up the real numbers; recent historical figures are available in the article), pay out $800 million of expenses in cash, and pay out stock options currently valued at $600 million. By MS's accounting, they make $400 million -- the $600 million worth of stock options is ignored as if it was never given out.
The reason the stock is worth enough, of course, is that there is a constant stream of new investment, because MS appears to be making lots of money. Once the illusion breaks, MS will crash in an instant.
Their real business is printing hip, trendy stock. If MS stock stopped going up, and employees wouldn't take options as payment, MS would be losing money very quickly, and the stock would crash and burn, like me with a frayed support string. --
Oo, look! I buzzed around 20% more than I claimed I could. Wall Street will sure be impressed!
Invest in me, and I promise I'll lose less money than I say I will, too. Invest enough in me, and I might even buy enough profitable businesses to make up for my unprofitable main activity.
I mean, if I had hundreds of millions of dollars, and a main business that only cost a few million to run, I'm sure I could make up the difference somewhere, even without a head. --
Slashdot Mirror
That it was wrong then doesn't mean it is wrong now. That it is wrong now doesn't mean when the claim is made again a year or two down the road it will be wrong then.
--
To show the world that the direction of IBM's mainframe software is making a dramatic turn of 360 degrees.
--
They were building structures measuring in the hundreds of cubits three thousand years ago.
--
City TV (a Toronto station that single handedly changed Canadian standards)
So... What were they doing with their other hand while they put near-porn on TV?
--
I can just picture it: you can buy the Television and the /\-chip fix seperately, or you can just buy a T&/\ set.
--
It's a beautiful illustration of the gains you can make from having a full understanding of trivial processes such as arithmetic. Lots of programmers couldn't even get fixed point math from integers without a recipe book, let alone implement a floating point struct using only ints. They don't even see why to learn either, until they see something like this.
I thought I had a good understanding of computer arithmetic (I mean, fixed point was no problem, I could write a bignum in my sleep...) until I read Chapter 4 of Knuth's TAoCP. What an eye opener! It replaced all my little tricks with a comprehensive understanding of fundamentals.
--
I would have gladly voted for gore in video games too!
--
If a 16 year old wants to shoot people...it's better off happening in the Arcade at school!
"Take that! Who's too stupid to do an unlimate triple Pythagorean combo grammar fatality now, huh?!" the psychotic teen is reported to have yelled repeated on his rampage through the new experimental "Learning With Gibs" lab. His friends and teachers call him "a very bright kid" who did very well in traditional classes, but just lacked the reflexes, hand-eye coordination, and hundreds of hours of video-game experience typical to teenage boys, to keep up with the new system.
Fortunately, nobody was injured, as he simply lacked the |\/|/\|) 1337 5|1LLZ to shoot people before they ducked for cover and ran away.
--
Clearly, the judge has good taste in comics.
Exhibit A
Here's a bonus.
The Parking Lot Is Full
--
I'm always happy when stuff like this comes out because it drives down the prices in a domino effect: 2nd best has to be cheaper than best, 3rd best has to be cheaper than 2nd best, et c. down to the cheap junk I buy.
--
When you can get it for $200 and games actually take advantage of it.
--
Optimizing compilers aren't bad, they're overrated. Some people depend on them too much and tell newbies "don't even bother with assembler; the optimizing compiler does a better job than you ever will."
how did you find out where that 99% of your run-time was spent? In the profiler.
...if you're a sloppy hack who has no idea what's going on in his program.
better algorithms and data structures in the general case
I don't know about you, but I generally try to get the best algorithms and data structures I can in the first place, for the performance-critical portions, and decent ones in other situations.
The only time you should have to resort to assembly is when you have absolutely performance critical tasks, ie Interrupt Service Routines.
I agree that it is best to avoid assembler when possible, but different people have different ideas about performance-critical tasks. More importantly, if you don't do serious work in assembler sometimes, you won't understand the machine.
Basically, you're advocating the tools of a sloppy style of "slap it together, get it running, then try to make work well later" which also is sloppy in terms of skill development. Doing a half-assed job to get things out the door today might seem worthwhile now, but you never learn to do anything but a half-assed job. That attitude is why most software is bug-ridden bloated crap and most programmers aren't capable of anything else.
--
IIRC, entitled: "Wu'd in Haste; Fried, Stewed at Leisure"
--
A good programmer knows what is going on in his programs.
I believe profilers, debuggers, and optimizing compilers are vastly overrated. Profilers are primarily valuable for finding horribly inefficient code you assumed wouldn't be used enough to matter, then forgot about. Alternative? Never write horribly inefficient code. A little extra effort of keeping code clean and efficient often helps avoid bugs, too.
I fall firmly into the "debuggers are a seductive waste of time" category. The effort of guessing what is wrong is good training that gives you more awareness and control of your programs. The action of setting breakpoints and stepping through the code is more time-consuming than you may realize, and I don't believe it usually speeds up debugging.
Optimizing compilers might give you an extra 2X performance boost over all your code, but usually 0.1% of your code covers 99% of run-time, and if you hand-optimize that 0.1% you can usually get at least an 8X boost. More importantly, knowing the hardware intimately tells you what kind of algorithms will be efficient. For example: how expensive are function-pointer calls as compared to conditional branches? What kind of looped conditional structures will screw up the pipeline? How small a block can you access randomly without causing cache misses? Are multiplications really more expensive than additions? Et c.
These toys are no substitute for your skills as a programmer, and depending on them blunts those very skills.
--
A common saying is that stock is worth whatever people will pay for it. IOW, printing up double stock on the same assets doesn't deflate its value as long as the market doesn't seem to notice. When the market crashes, then you'll see lots of blame aimed at these practices, but not before.
Bill Parish is needlessly hostile in his wording, and so comes off as a conspiracy theorist, but he's got the facts right. Employees are getting stock options and selling them (or holding them); consider the exactly equivalent situation of Microsoft selling the stock options and giving the money to employees who then keep the money (or buy stock options).
If this happened, MS would be reporting a loss, because the money from selling stock options is investment capital, not revenue, and cash salary is an expense, though giving out stock options as salary isn't.
This is common practice, because funding your business partly with a Ponzi scheme lets you lower prices below cost, and thus outcompete competitors. If someone is doing it, everybody has to do it, or be driven out of business.
The problem is its fundamental similarity to a pyramid scheme: the ones who get in and out before the crash get rich, but an ever-expanding pool of capital must be tapped. When it reaches its limit, either by running out of new investors, or people realizing that eventually they're going to run out of new investors, it crashes. It can still go for a few years yet, though, maybe as much as a decade, before all the suckers looking for easy money, and all the retirement and college funds are tapped out. Even longer if messed up countries get their act together long enough for their citizens to accumulate real wealth to gamble on bubble stocks.
It could even lead to a third world war, if China and India decide that their citizens shouldn't hand off half the country to pay debts to foreigners who got out in time.
--
Bresenhan's algorithm is a fast, simple (jaggy)line-drawing algorithm. Basically, you figure out the longer dimension and step along it pixel by pixel, keeping track of how far off you are getting from the logical line (the "error"); when you're more than half a pixel out, you move one pixel along the shorter dimension.
The clever bit is finding ways to keep track of the error without using division.
While line drawing is fairly trivial, often accelerated, and usually handled by libraries, it's also good for figuring out paths of moving sprites and many other tasks similar to line drawing.
Read about it in the Black Book and immerse yourself in the coolness.
--
I have a treasured old copy of "Zen of Graphics Programming", which was the book that introduced me to such beauties as Bresenham's algorithm and dirty rectangle animation. This guy will get your enthusiasm up for graphics the way Knuth teaches a love of elegant, efficient data structures and algorithms.
Somehow, I never got around to buying the Black Book, though. I read his articles on the Quake engine though, and they're as relevant today as they were the day they were printed (not that low-level engine design is relevant to a huge audience, but at the least it's a good workout for your brain). Definitely worth the bother to download and read.
Let's try not to all download at the same time, ok? They'll still be there a month from now. They really should have put up a clear notice giving permission to make mirrors; demand is sure to be as crushing as the shipping accident that decapitated me.
--
Basically, the article claims it's a Ponzi scheme. They are paying their bills, creating the illusion of solvency, with new investment.
The tricky bit is where they pay a lot of their bills with stock, which they don't have to report as if they actually spent anything. Let's say they take a billion in revenue (because I'm too lazy to look up the real numbers; recent historical figures are available in the article), pay out $800 million of expenses in cash, and pay out stock options currently valued at $600 million. By MS's accounting, they make $400 million -- the $600 million worth of stock options is ignored as if it was never given out.
The reason the stock is worth enough, of course, is that there is a constant stream of new investment, because MS appears to be making lots of money. Once the illusion breaks, MS will crash in an instant.
Their real business is printing hip, trendy stock. If MS stock stopped going up, and employees wouldn't take options as payment, MS would be losing money very quickly, and the stock would crash and burn, like me with a frayed support string.
--
Watch as I buzz around in a circle!
Oo, look! I buzzed around 20% more than I claimed I could. Wall Street will sure be impressed!
Invest in me, and I promise I'll lose less money than I say I will, too. Invest enough in me, and I might even buy enough profitable businesses to make up for my unprofitable main activity.
I mean, if I had hundreds of millions of dollars, and a main business that only cost a few million to run, I'm sure I could make up the difference somewhere, even without a head.
--