> Part of the problem is that defensive weapons > like this have traditionally been oversold to > the public. (Remember the Patriot during the > Gulf War?)
True, true. The over-sell of the Patriot was that Patriots were, IIRC, designed only to protect military installations. If you're defending an airfield or small installation from Scuds, hitting the Scud and knocking it enough off course that it lands in the desert two miles away is a win.
Of course, if you do this to defend a city, you take a pretty good chance of knocking this missile away from the city and into the suburbs.
> In the split second before the disco ball > melts down to nothing, anyone in the vicinity > would be made very, very unhappy.
Aren't people in the vicinity of disco balls very unhappy all the time? That and people in the general vicinity of Abba tribute bands. They're unhappy, too.
A cloud of shell parts has a very different aerodynamic profile. The remnants of the shell might still be initially traveling in the same direction, but the fragments will not maintain that course. You only have to change the trajectory of the shell enough to make it fall short of its target.
So performance is very important in situations where the size of the application user base needs to scale dependably.
Its not entirely clear to me from the articles that the performance gap is very large, or if it exists, or if it does, who is in the lead. I think that its safe to argue that for a given application, a proper implementation in.NET or J2EE would have nearly equal performance (when performance is your weighted notion of resource utilization, scalibilty, etc.). As long as that gap is realitively small, or manageably sized, I think that it will not be part of the equation driving the choice of tools.
Where I work, we spend boat loads of money on hardware that most fanboys and slashdot addicts would scoff at. We take a major performance hit and it sucks budgets dry. Why? Because the software costs associated with buying different hardware is so high, it would make you cry.
I feel confident saying that as long as the percieved performance gap is small, or at least manageable, performance will not drive decision making. Tool efficiency and developer training will (or should) drive the decisions made.
Remember, too, that its hard to compare the costs of additional capital equipment and additional software labor. While additional capital expenditures for hardware can hit your budget and your cash flow like a ton of bricks, its software costs that nickle and dime even the best budgets to death.
> Its not about branching. Its about data references using PC relative addressing. The PowerPC has no PC relative data addressing modes.
Point taken. Section 4.2.3.1 of the same book is "Integer load and store address generation".
1. Register indirect with immediate index addressing for integer loads and stores - In this case, you get a 16-bit index in the instruction added to the value in a general purpose register, which is used to compute the effective address.
2. Register indirect with index addressing for integer loads and stores - this is the same as above, except that two registers are used and there is no encoded index.
3. Register indirect addressing integer loads and stores - use just one general purpose register as an address for a load or store.
So, the point is that in every case, some form of relative addressing is used. In order to make relocatable code, ie code that can be linked happily with other binary objects, you have to have some sort of reference address, and PC-relative addressing is the only way to do this.
Even though there is no PC-relative addressing mode, the only way to guarentee that the relative addresses used in different object files won't clash is to do PC-relative. The fact that this is not easy on the PowerPC doesn't make it any less necessary.
It just so happens that I friend of mine has a copy of "PowerPC Mircoprocessor Family: Programming Environments for 32-bit Microprocessors" sitting on his desk, which I grabbed. Here is how PowerPC processors branch (from sectino 4.2.4.1 of said dead-tree document):
1. Branch relative addressing mode - the immediate displacement operand is sign exteneded and added to the current instruction address to produce the branch target address. So, PC relative addressing. There is no need for a programmatically accessible program counter because this is all done by the branch execution unit. Single 32-bit instruction.
2. Branch conditional to relative addressing mode - same as branch relative addressing, except that the branch is only executed if the proper condition codes are set. Single 32-bit instruction.
3. Branch to absolute addressing - the operand address is sign extended and used as the branch target. As the name implies, this is absolute addressing. Only problem is, the operand address is only 23 bits wide in a 32-bit implementation, and with the zero pad, it gives only 25 bits of absolute address (word alignment required). So, if you absolute address anything, you can only absolute address 25 bits worth of the address space.
4. Branch conditional to absolute - same as regular absolute addressing, except that you have to encode condition codes, so the operand address is nowo only 13 bits if I read the diagrams correctly, meaning that you can only absolutely address 15 bits of address space with the zero pad.
5. Branch conditional to link register - if you clobber the link register, you can branch to a 32-bit address. Of course, you have to clobble the link register, so I would think this would be most helpful in returning from a function call, not going to it, since the link register holds the return address. And if you use it forward instead of returning, you have to load the link register.
6. Branch conditional to count register - same as link register branching as above.
All of that said, the reason that the Mac OS ABI uses PC relative addressing is because the only way to fully address a 32-bit address space is to do PC relative addressing. According to this book, there is no two instruction width branch, eg a branch instruction which encodes an entire 32-bit absolute address in two 32-bit words (one word for branch encoding and condition codes, one word for the whole 32-bit address).
This leads me to believe that there is no way to do all absolute addressing on PowerPC unless you implement new instructions (which will take more time to get to the processor, and to decode) or limit yourself to 15 or 25 bits of the address space.
So, the short version is that that there is no way for the Mac OS ABI to do absolute addressing.
This leads me to believe that PowerPC does run of the mill PC-relative addressing, so that, for example, branches only take one instruction width, rather than having to store an entire 32-bit address in another location, etc.
I'm confused by the purpose of the article, but I think the point was that PC-relative addressing forces the compiler to compute the address of a branch target in a function call to a fully-linked part of the binary. I don't think that address computation of that sort is responsible for a 10-15% performance hit, because wouldn't full time absolute addressing require more memory access on the already saturated MPX bus?
If I'm incorrect in this, please tell me, and I will look for more information.
Slashdot spends *a lot* of time talking about Apple. I'm not entirely sure how Uncle Steve built his company to attact so much attention, but it just seems that we talk about it a lot.
As far as the Cult of Steve, I am a member, having recently returned from exile in the PC wilderness. Ah, how nice it is to return to the warmth of the Reality Distortion Field, where all benchmarks are Photoshop and all the UI components are lickably delicious.
Macs aren't the only products that inspire fanatical devotion (see comments re Linux, BSD, etc.). Not even just computers (shocking, isn't it?). Have you ever met people who drive Saturns? We're rather fanatical about our friendly dealerships and polymer side panels (dent resistant *and* rust proof:)
(This is pretty nifty. Beats flipping through several sites, or as other posters have said, waiting for banners to load on cnn.com. Now if they offer it a couple of other languages, my life will be complete.)
Okay, this article is even more innane than the currently discussed one. While there are occaisonal good points, and some blatant pandering to the Weekly Standard's core audience, I can't get past this line:
Make no mistake, as emperor, Palpatine is a dictator--but a relatively benign one, like Pinochet. It's a dictatorship people can do business with.
Benign? Pinochet? Head... hurts... too... much...
I would guess that there a more than a few people, slashdotters among them, that would argue that Mr. Pinochet's time in power in Chile was more torture, murder, corruption, and deception than benign.
I don't have any problem with the bland nihlism that apparently irritates Mr. Brin so much, maybe because it appeals to me. I'm not bothered by the incredible plot inconsistencies or the general lack of good story telling. These are movies, not films. I suspend my disbelief, and magically, I'm entertained. Of course, I'm easily entertained, so maybe I'm a bad judge.
Oh, and I save my religous devotion for Star Trek and Vi.
That aside, I think the real problem is that we're quibbling over subplot and subtext in a place it doesn't belong. The original appeal of the space opera in New Hope was that the story arc - moronic, cheesy, and poorly constructed as it might be, IANA writer just an engineer - was epic (insert sound effect for listeners of the Tony Kornheiser show). Whats killed Eps I and II is that we have time to consider the finer, or not so fine, plot components because the story line is so darn boring. As much as it might be a subtle introduction into the making of an emperor, a story arc about a trade dispute pales in comparison to saving the universe from destruction.
Save the intellectualism for Trek and Battlestar Gallactica, and give me more epic space opera in my Ep III, and I'll be happy.
I wonder if continuing to improve on existing technology, and not trying to move in completely new ones, is the best idea.
Of course its the best idea. Its just never the most fun.
Writing new lines of code is way more fun than squashing esoteric bugs in legacy code. Design new computer architectures is always more sexy than modding an old one. Making snazzy solid state storage is currently way more chick-magnet-ish than breaking the superparamagnet barrier, or at least as chick-magnet-ish as either of things can be.
We all assumed that magnetic media was on its way out because of things like superparamagnetism. If Seagate's research folks had decided that HAMR was too costly, too fragile, or too difficult, they wouldn't be doing it.
Just like everyone thought that Moore's Law was out the window because X-ray lithography was so expensive and unreliable, and then the manufacturers come back with visible spectrum equipment that can make smaller and smaller features. Then we have no more Moore's Law because we did the math and even X-ray lithography won't save us forever, and then we nanotech semiconductors.
Magnetic media is here to stay, and that's not a bad thing. We're only leveraging, oh, 40 years worth of research and development:-)
I agree that this is a fundamental programmer attribute, and one that should not be ignored in a first interview.
But, would you believe that not everyone thinks sandals and suits go together? I went to court on a traffic violation and wore a tie, etc., and sandals. The judge called me a no-sock, sandal-wearing hippie. Of course, then he didn't make me pay the fine, so it worked out okay:-)
that you're interviewing programmers, aka code monkeys. They might dance, but they will never perform. You'd probably like an engineer or a scientist. How you interview for them is totally different.
I worked for a startup company back when it was the cool thing to do. The nerds with titles were debating how to interview for a new position, and the battle came down to this essential problem - which is the best question:
1. What is java.lang.Thread.join()?
or
2. Tell me about how you start and stop different execution paths in a multithreaded application.
If you ask (1), you get a code monkey. He or she will write good code when given proper instruction because he or she has a minimum set of skills. Code monkeys can handle hammers and screwdrivers because they've used them before. Ask them to use, say, a quarter sheet finishing sander and they will be confused.
Ask (2), and you get an engineer or a scientist. Knowing that you can wait for the termination of a thread in java with join() is nice, but understanding the implications and uses of join() is ten thousand times more important. Understanding the concept is more important than perfect syntax.
My suggestions for questions are these two, because I think you are less likely to pick a code monkey and more likely to pick an engineer:
1. Tell me about a project you are particularly proud of, and explain some of the technical issues you faced in finishing it. (This is a good question for several reasons. First, you get a good sense of interpersonal skills, because they have to tell a story. You also can gadge a candidate's general interests in the larger field of computer engineering/science, and a feel for their particular strengths. Lastly, you get to see whether this candidate is a finisher or a ship-it-when-it-compiles person because you asked about finishing a project, which is never the most glamorous, but frequently the most important part of being a software engineer.)
2. Tell me about a project you worked on with a team. What kinds of challenges did you face and how did you solve them? (Again, story telling, this time with a definite bend towards interpersonal skills. You also get to assess team work skills, etc., in a technical environment. When I was asked about this question I talked about how my junior design project team needed to be more organized to meet our project schedule, so we got stricter about version control, documentation, etc. If the candidate tells you story about this irritating person or that jerk, you should consider whether or not you're going to be the jerk he talks about in his next interview.)
True, true. One of the few good things going for SGI is that the userbase is very loyal, and for just as many technical reasons as not so technical ones.
And you almost pinned down what I do:-) I work for a large company, but I develop applications that never leave the lab, and have user bases on the order of 10. Since what we do is pretty much fully custom applications for real time simulation, we get to pick and choose the tools, and ever since we couldn't buy any more Harris parts, we've been an all SGI shop.
You're right. Maybe I misspoke. I should have said engineering community, not scientific. The data sets, etc., that are most frequently seen in the scientific (and parts of the engineering community) are still so large, that no one considers moving away from SGI. When the data is large and the visualization is intense, you buy an Onyx. (As I type, I could walk over and touch the Onyx3800 or the rack of O300 in the computer room.)
What I'm refering to is the smaller applications, the ones that don't justify the purchase of an Onyx, and don't warrant significant time on an Onyx. Around here, there are a small number, but growing, group of projects that started 10 years ago on a fleet of Onyx. The data sets haven't grown significantly in that time, and what would have choked a PC and required an Onyx 10 years ago isn't that big a deal now. While I realize this is still a small set, the number grows every couple of months.
Would you agree that smaller, especially custom applications, might eventually move away from SGI?
Everybody has mentioned Sony and (sp) Eriksson, but even if there was a chance in hell of this kind of product getting sold, I don't think they'd buy from either of those two. (Apple isn't selling its own PDA because the market is saturated and no one is making money. The cellular handset market is 10 thousand times worse, so don't look for this any time soon. Eriksson might make a likely partner, but longterm Sony is a major competitor in the digital-lifestyle space, so I don't see them going there. Eriksson or Nokia, maybe.)
Who does Apple know that makes phones? A company established in the cellular industry, maybe down on its luck in recent years, looking for a breakthrough product? Maybe one that sells things like phones
and has been getting good press lately for Bluetooth gear seeing as how Apple loves Bluetooth. If oonly there was a company that Apple already had a relationship with, then we'd know who they might go to for this sort of thing.
NVIDIA says that if you ask for contents of the framebuffer in a call to glReadPixels and you ask for it in the same pixel units its stored in, you won't be really disappointed. If, however, you ask for that same region of the framebuffer in another format, you're screwed. (So, if your framebuffer is 8-8-8-8 RGBA, and you ask for luminance or 10-10-10-2 or something else odd, you aren't going to be pleased with the performance.)
This isn't by the way, just a render-movies-on-your-PC issue. Lots of scientific computing, visualization, etc., applications render with OpenGL and then grab the framebuffer to store a result. This throughput issue is significant considering that for many applications, what was an enormous data set 10 years ago is now not such a big data set. Like another poster said, this issue is one of the ones that still ties people to SGI.
While 99% of your other concerns might be dealt with, there are still lingering problems like this one that keep some people from moving to commodity hardware.
Since the posting-to-100-comments time for this article was relatively short, I'm guess most of us won't RTFA, and we'll just rehash the National ID cards in the US debate.
I'll condense the national ID card debate Slashdot style:
1. Some Americans (the smart ones) are concerned about the unconstitutional and immoral encroachment of the federal government and the State in general into private affairs,the cancellation of your civil liberties, and the abandonment of privacy as a fundamental notion of American identity. (Yes, I said immoral. And I meant it.)
2. Some Americans don't care, and won't care, until someone comes after them individually, by which time, it is already hopelessly too late.
3. Most Europeans will treat the Americans in (1) with disdain and in (2) with general disgust, and then go on at length about how the tradition in whatever country they're from permits a stronger *national* government and notion of the State while maintaining a firm but limited notion of civil liberties. They will then make a disparaging remark about American culture based on one of the following: Walmart, McDonalds, Britney Spears, Backstreet Boys, nuclear weapons, ballistic missile defense, or neo-colonialism.
4. Some Americans will then counter the culture argument with some remark based on one of the following: grooming habits, combined GDP, nuclear weapons, WWI and/or WWII.
5. People reading Slashdot from places that are not the US nor Europe will watch as the Americans get flustered at the European attitude, while the Europeans get flustered at the American attitude,
all the while wondering when they will start listening instead of just waiting for their turn to talk.
Where I work, the trend has been towards the standarization of company wide processes, across all of the disciplines: engineering, HR, IT, etc. The hope was, if they can distill the proper process, they can make incompetent or semi-imcompetent people productive, and make competent people slightly more productive.
IT spending is viewed in the same way. Lots of companies thought that if they just implemented the right file server, or purchasing system, or XML based web services something or other, incompetent people would be productive, customer relations would be quick and helpful, engineers would be free to create, and everything would be puppy dogs and teddy bears and big red balloons.
Only problem: both of these assumptions are wrong.
Every company needs standard processes so that people can be efficient. But no amount of process makes incompetent people competent. Every company needs decent IT, but no amount of IT makes incompetent people competent.
What more companies are realizing, in both process and IT, and probably other areas as well, is that just spending more money (1) is not a good way to get work done, (2) takes resources away from business segments that produce products, and (3) doesn't necessarily make anything better.
IT is now just approaching it true value from the topside because we've all been under the impression that it could magically make our lives better, and it doesn't.
(And just to nitpick, while IT is tech, tech is not IT. There are plenty of tech jobs that aren't IT.)
The truth helps. Just keep speaking the truth, and tell your friends, people on the bus, folks at work.
There are a couple of important points to consider.
* Systems related to national security shouldn't be on the internet in the first place. Sure, that's what its was designed for, to be a comm network that would survive a nuclear strike and still route packets. Of course, plenty of government networks are already physically disconnected. Not firewalled, just not connected. So no Slashdot reading on your power grid terminal. Until we actually start building secure software, cause we don't now, some systems absolutely have to stay disconnected, or connected only through separate, encrypted, physically secure networks.
* Instead of feeping creaturism, maybe its time to actually start worrying about security, ala OpenBSD. Could it be that people would put up with substandard office software and not-so-intuitive file browsers if we guarenteed them that the financial data on their computers would be safe? Would you pay extra for your internet-connected pacemaker (which will probably send data to your doctor) if you knew that somebody couldn't hack it and turn it off? Would your Mom put up with having to learn a confusing operating system if it meant that her Quicken data wouldn't get stolen? I bet mine would.
* And maybe, just maybe, we, as software engineers should stop living up to the low expectations of the marketdroids and the PHBs (oooh look, shiny GUI) and start demanding more of ourselves. The reason that propoganda like this punk is spewing travels so fast is that the computer-using public has been conditioned to expect so little (Oh, another reboot? No big deal. Server's down? Eh, kick it, I'll go get a cup of coffee.)
So, I'd tell people to stop whining, stop freaking out, and stop bowing to the government-media complex's instinct to make everything a damn crisis. Instead of worrying, do something. If you're a software dude, start thinking about robustness and security instead of pretty. If you're a (l)user, start learning how to secure your stuff, and start demanding that they companies you buy from do the same.
Ah, yes. EPIC. Explicitly Parallel Instruction Computing. AKA VLIW. EPIC is market-speak. Intel didn't want to admit that it was making a VLIW chip for two reasons:
1. There is only one company that has every sold a VLIW chip that actually worked, and that people bought: TI makes DSPs, where are VLIW. They make tons of money. They are the only ones that ever did it right.
2. There is only one company that has ever made a good VLIW compiler: TI, again.
Lets think briefly about how great EPIC is, using the two main selling points I remember from a presentation I saw on it a few years ago (sorry if my memory is bad, no coffee this morning, I'm not responsible).
1. Instructions are Explicitly Parallel. So, the compiler tells you that these two or four or however many instructions can be executed without worrying about data dependency. Terrific. Assuming that the compiler actually works, which is still an open question.
The only difference between this setup and what's in your Athlon or Pentium4 is that the looking-for-independence is done in hardware on your Athlon instead of by the compiler on your Itanium. This means that there is the *possibility* that EPIC does better at finding independence because the compiler *should* know more about the code when its in a higher level language. *Should*. Essentially, until the science of compilers takes a quantum leap or we start using programming languages that makes these things easier (correct me if I'm wrong, please), Itanium will be at most as fast as a superscalar processor that finds independent instructions on its own and does register renaming.
2. Predicates and conditional execution. While the whole notion of the predicate in EPIC is more complicated and complex than just conditional execution, its not entirely more useful IMHO, or at least that was my impression the last time I heard someone talk about it. Alpha has conditional execution. ARM has conditional execution. I can append checks to the condition codes in ARM assembly. I don't really understand why this is so nifty.
I've said it before, and I'll say it again. Resist the urge to think that whatever marketdroids tell you is new is actually good. Sometimes its not.
(If more knowledgeable people are lurking, please correct any errors I've made, but I think I've got this right.)
> imho it's better to get rid off all the old junk and start over once in a while.
Unless of course you've got an installed base somewhere in the billions, 20 years worth of compiler optimization, a factor of, what 100, more people that know the assembly language, etc. And it doesn't help if good compilers won't exist by the time your chip comes out. And if the internal interface teams have difficulty communicating, you're going to be late, hot, slow, and over-complicated.
Starting over is nice from a design perspective, especially because it feeds the urge for creativity that most engineers have. Unfortunately, that do-over is not always executed well, and it turns out to be a little underwhelming, just like Itanium.
Fight the urge to think that all new things are good. Please.
Slashdot Mirror
> Part of the problem is that defensive weapons
> like this have traditionally been oversold to
> the public. (Remember the Patriot during the
> Gulf War?)
True, true. The over-sell of the Patriot was that Patriots were, IIRC, designed only to protect military installations. If you're defending an airfield or small installation from Scuds, hitting the Scud and knocking it enough off course that it lands in the desert two miles away is a win.
Of course, if you do this to defend a city, you take a pretty good chance of knocking this missile away from the city and into the suburbs.
> In the split second before the disco ball
> melts down to nothing, anyone in the vicinity
> would be made very, very unhappy.
Aren't people in the vicinity of disco balls very unhappy all the time? That and people in the general vicinity of Abba tribute bands. They're unhappy, too.
A cloud of shell parts has a very different aerodynamic profile. The remnants of the shell might still be initially traveling in the same direction, but the fragments will not maintain that course. You only have to change the trajectory of the shell enough to make it fall short of its target.
So performance is very important in situations where the size of the application user base needs to scale dependably.
.NET or J2EE would have nearly equal performance (when performance is your weighted notion of resource utilization, scalibilty, etc.). As long as that gap is realitively small, or manageably sized, I think that it will not be part of the equation driving the choice of tools.
Its not entirely clear to me from the articles that the performance gap is very large, or if it exists, or if it does, who is in the lead. I think that its safe to argue that for a given application, a proper implementation in
Where I work, we spend boat loads of money on hardware that most fanboys and slashdot addicts would scoff at. We take a major performance hit and it sucks budgets dry. Why? Because the software costs associated with buying different hardware is so high, it would make you cry.
I feel confident saying that as long as the percieved performance gap is small, or at least manageable, performance will not drive decision making. Tool efficiency and developer training will (or should) drive the decisions made.
Remember, too, that its hard to compare the costs of additional capital equipment and additional software labor. While additional capital expenditures for hardware can hit your budget and your cash flow like a ton of bricks, its software costs that nickle and dime even the best budgets to death.
Cool. I agree. I was wrong.
> Its not about branching. Its about data references using PC relative addressing. The PowerPC has no PC relative data addressing modes.
Point taken. Section 4.2.3.1 of the same book is "Integer load and store address generation".
1. Register indirect with immediate index addressing for integer loads and stores - In this case, you get a 16-bit index in the instruction added to the value in a general purpose register, which is used to compute the effective address.
2. Register indirect with index addressing for integer loads and stores - this is the same as above, except that two registers are used and there is no encoded index.
3. Register indirect addressing integer loads and stores - use just one general purpose register as an address for a load or store.
So, the point is that in every case, some form of relative addressing is used. In order to make relocatable code, ie code that can be linked happily with other binary objects, you have to have some sort of reference address, and PC-relative addressing is the only way to do this.
Even though there is no PC-relative addressing mode, the only way to guarentee that the relative addresses used in different object files won't clash is to do PC-relative. The fact that this is not easy on the PowerPC doesn't make it any less necessary.
It just so happens that I friend of mine has a copy of "PowerPC Mircoprocessor Family: Programming Environments for 32-bit Microprocessors" sitting on his desk, which I grabbed. Here is how PowerPC processors branch (from sectino 4.2.4.1 of said dead-tree document):
1. Branch relative addressing mode - the immediate displacement operand is sign exteneded and added to the current instruction address to produce the branch target address. So, PC relative addressing. There is no need for a programmatically accessible program counter because this is all done by the branch execution unit. Single 32-bit instruction.
2. Branch conditional to relative addressing mode - same as branch relative addressing, except that the branch is only executed if the proper condition codes are set. Single 32-bit instruction.
3. Branch to absolute addressing - the operand address is sign extended and used as the branch target. As the name implies, this is absolute addressing. Only problem is, the operand address is only 23 bits wide in a 32-bit implementation, and with the zero pad, it gives only 25 bits of absolute address (word alignment required). So, if you absolute address anything, you can only absolute address 25 bits worth of the address space.
4. Branch conditional to absolute - same as regular absolute addressing, except that you have to encode condition codes, so the operand address is nowo only 13 bits if I read the diagrams correctly, meaning that you can only absolutely address 15 bits of address space with the zero pad.
5. Branch conditional to link register - if you clobber the link register, you can branch to a 32-bit address. Of course, you have to clobble the link register, so I would think this would be most helpful in returning from a function call, not going to it, since the link register holds the return address. And if you use it forward instead of returning, you have to load the link register.
6. Branch conditional to count register - same as link register branching as above.
All of that said, the reason that the Mac OS ABI uses PC relative addressing is because the only way to fully address a 32-bit address space is to do PC relative addressing. According to this book, there is no two instruction width branch, eg a branch instruction which encodes an entire 32-bit absolute address in two 32-bit words (one word for branch encoding and condition codes, one word for the whole 32-bit address).
This leads me to believe that there is no way to do all absolute addressing on PowerPC unless you implement new instructions (which will take more time to get to the processor, and to decode) or limit yourself to 15 or 25 bits of the address space.
So, the short version is that that there is no way for the Mac OS ABI to do absolute addressing.
This leads me to believe that PowerPC does run of the mill PC-relative addressing, so that, for example, branches only take one instruction width, rather than having to store an entire 32-bit address in another location, etc. I'm confused by the purpose of the article, but I think the point was that PC-relative addressing forces the compiler to compute the address of a branch target in a function call to a fully-linked part of the binary. I don't think that address computation of that sort is responsible for a 10-15% performance hit, because wouldn't full time absolute addressing require more memory access on the already saturated MPX bus? If I'm incorrect in this, please tell me, and I will look for more information.
Slashdot spends *a lot* of time talking about Apple. I'm not entirely sure how Uncle Steve built his company to attact so much attention, but it just seems that we talk about it a lot.
:)
As far as the Cult of Steve, I am a member, having recently returned from exile in the PC wilderness. Ah, how nice it is to return to the warmth of the Reality Distortion Field, where all benchmarks are Photoshop and all the UI components are lickably delicious.
Macs aren't the only products that inspire fanatical devotion (see comments re Linux, BSD, etc.). Not even just computers (shocking, isn't it?). Have you ever met people who drive Saturns? We're rather fanatical about our friendly dealerships and polymer side panels (dent resistant *and* rust proof
a story from the Onion makes news.google.com?
(This is pretty nifty. Beats flipping through several sites, or as other posters have said, waiting for banners to load on cnn.com. Now if they offer it a couple of other languages, my life will be complete.)
Okay, this article is even more innane than the currently discussed one. While there are occaisonal good points, and some blatant pandering to the Weekly Standard's core audience, I can't get past this line:
Make no mistake, as emperor, Palpatine is a dictator--but a relatively benign one, like Pinochet. It's a dictatorship people can do business with.
Benign? Pinochet? Head... hurts... too... much...
I would guess that there a more than a few people, slashdotters among them, that would argue that Mr. Pinochet's time in power in Chile was more torture, murder, corruption, and deception than benign.
I don't have any problem with the bland nihlism that apparently irritates Mr. Brin so much, maybe because it appeals to me. I'm not bothered by the incredible plot inconsistencies or the general lack of good story telling. These are movies, not films. I suspend my disbelief, and magically, I'm entertained. Of course, I'm easily entertained, so maybe I'm a bad judge.
Oh, and I save my religous devotion for Star Trek and Vi.
That aside, I think the real problem is that we're quibbling over subplot and subtext in a place it doesn't belong. The original appeal of the space opera in New Hope was that the story arc - moronic, cheesy, and poorly constructed as it might be, IANA writer just an engineer - was epic (insert sound effect for listeners of the Tony Kornheiser show). Whats killed Eps I and II is that we have time to consider the finer, or not so fine, plot components because the story line is so darn boring. As much as it might be a subtle introduction into the making of an emperor, a story arc about a trade dispute pales in comparison to saving the universe from destruction.
Save the intellectualism for Trek and Battlestar Gallactica, and give me more epic space opera in my Ep III, and I'll be happy.
I wonder if continuing to improve on existing technology, and not trying to move in completely new ones, is the best idea.
:-)
Of course its the best idea. Its just never the most fun.
Writing new lines of code is way more fun than squashing esoteric bugs in legacy code. Design new computer architectures is always more sexy than modding an old one. Making snazzy solid state storage is currently way more chick-magnet-ish than breaking the superparamagnet barrier, or at least as chick-magnet-ish as either of things can be.
We all assumed that magnetic media was on its way out because of things like superparamagnetism. If Seagate's research folks had decided that HAMR was too costly, too fragile, or too difficult, they wouldn't be doing it.
Just like everyone thought that Moore's Law was out the window because X-ray lithography was so expensive and unreliable, and then the manufacturers come back with visible spectrum equipment that can make smaller and smaller features. Then we have no more Moore's Law because we did the math and even X-ray lithography won't save us forever, and then we nanotech semiconductors.
Magnetic media is here to stay, and that's not a bad thing. We're only leveraging, oh, 40 years worth of research and development
> # Can you wear sandals with a suit and tie?
:-)
I agree that this is a fundamental programmer attribute, and one that should not be ignored in a first interview.
But, would you believe that not everyone thinks sandals and suits go together? I went to court on a traffic violation and wore a tie, etc., and sandals. The judge called me a no-sock, sandal-wearing hippie. Of course, then he didn't make me pay the fine, so it worked out okay
that you're interviewing programmers, aka code monkeys. They might dance, but they will never perform. You'd probably like an engineer or a scientist. How you interview for them is totally different.
I worked for a startup company back when it was the cool thing to do. The nerds with titles were debating how to interview for a new position, and the battle came down to this essential problem - which is the best question:
1. What is java.lang.Thread.join()?
or
2. Tell me about how you start and stop different execution paths in a multithreaded application.
If you ask (1), you get a code monkey. He or she will write good code when given proper instruction because he or she has a minimum set of skills. Code monkeys can handle hammers and screwdrivers because they've used them before. Ask them to use, say, a quarter sheet finishing sander and they will be confused.
Ask (2), and you get an engineer or a scientist. Knowing that you can wait for the termination of a thread in java with join() is nice, but understanding the implications and uses of join() is ten thousand times more important. Understanding the concept is more important than perfect syntax.
My suggestions for questions are these two, because I think you are less likely to pick a code monkey and more likely to pick an engineer:
1. Tell me about a project you are particularly proud of, and explain some of the technical issues you faced in finishing it. (This is a good question for several reasons. First, you get a good sense of interpersonal skills, because they have to tell a story. You also can gadge a candidate's general interests in the larger field of computer engineering/science, and a feel for their particular strengths. Lastly, you get to see whether this candidate is a finisher or a ship-it-when-it-compiles person because you asked about finishing a project, which is never the most glamorous, but frequently the most important part of being a software engineer.)
2. Tell me about a project you worked on with a team. What kinds of challenges did you face and how did you solve them? (Again, story telling, this time with a definite bend towards interpersonal skills. You also get to assess team work skills, etc., in a technical environment. When I was asked about this question I talked about how my junior design project team needed to be more organized to meet our project schedule, so we got stricter about version control, documentation, etc. If the candidate tells you story about this irritating person or that jerk, you should consider whether or not you're going to be the jerk he talks about in his next interview.)
Too... many... buzzwords... head... hurts...
True, true. One of the few good things going for SGI is that the userbase is very loyal, and for just as many technical reasons as not so technical ones.
:-) I work for a large company, but I develop applications that never leave the lab, and have user bases on the order of 10. Since what we do is pretty much fully custom applications for real time simulation, we get to pick and choose the tools, and ever since we couldn't buy any more Harris parts, we've been an all SGI shop.
And you almost pinned down what I do
You're right. Maybe I misspoke. I should have said engineering community, not scientific. The data sets, etc., that are most frequently seen in the scientific (and parts of the engineering community) are still so large, that no one considers moving away from SGI. When the data is large and the visualization is intense, you buy an Onyx. (As I type, I could walk over and touch the Onyx3800 or the rack of O300 in the computer room.)
What I'm refering to is the smaller applications, the ones that don't justify the purchase of an Onyx, and don't warrant significant time on an Onyx. Around here, there are a small number, but growing, group of projects that started 10 years ago on a fleet of Onyx. The data sets haven't grown significantly in that time, and what would have choked a PC and required an Onyx 10 years ago isn't that big a deal now. While I realize this is still a small set, the number grows every couple of months.
Would you agree that smaller, especially custom applications, might eventually move away from SGI?
that makes cell phones?
Everybody has mentioned Sony and (sp) Eriksson, but even if there was a chance in hell of this kind of product getting sold, I don't think they'd buy from either of those two. (Apple isn't selling its own PDA because the market is saturated and no one is making money. The cellular handset market is 10 thousand times worse, so don't look for this any time soon. Eriksson might make a likely partner, but longterm Sony is a major competitor in the digital-lifestyle space, so I don't see them going there. Eriksson or Nokia, maybe.)
Who does Apple know that makes phones? A company established in the cellular industry, maybe down on its luck in recent years, looking for a breakthrough product? Maybe one that sells things like phones and has been getting good press lately for Bluetooth gear seeing as how Apple loves Bluetooth. If oonly there was a company that Apple already had a relationship with, then we'd know who they might go to for this sort of thing.
If only I could think of a company like that...
And I tend to agree that its a software issue.
NVIDIA says that if you ask for contents of the framebuffer in a call to glReadPixels and you ask for it in the same pixel units its stored in, you won't be really disappointed. If, however, you ask for that same region of the framebuffer in another format, you're screwed. (So, if your framebuffer is 8-8-8-8 RGBA, and you ask for luminance or 10-10-10-2 or something else odd, you aren't going to be pleased with the performance.)
This isn't by the way, just a render-movies-on-your-PC issue. Lots of scientific computing, visualization, etc., applications render with OpenGL and then grab the framebuffer to store a result. This throughput issue is significant considering that for many applications, what was an enormous data set 10 years ago is now not such a big data set. Like another poster said, this issue is one of the ones that still ties people to SGI.
While 99% of your other concerns might be dealt with, there are still lingering problems like this one that keep some people from moving to commodity hardware.
Since the posting-to-100-comments time for this article was relatively short, I'm guess most of us won't RTFA, and we'll just rehash the National ID cards in the US debate.
I'll condense the national ID card debate Slashdot style:
1. Some Americans (the smart ones) are concerned about the unconstitutional and immoral encroachment of the federal government and the State in general into private affairs,the cancellation of your civil liberties, and the abandonment of privacy as a fundamental notion of American identity. (Yes, I said immoral. And I meant it.)
2. Some Americans don't care, and won't care, until someone comes after them individually, by which time, it is already hopelessly too late.
3. Most Europeans will treat the Americans in (1) with disdain and in (2) with general disgust, and then go on at length about how the tradition in whatever country they're from permits a stronger *national* government and notion of the State while maintaining a firm but limited notion of civil liberties. They will then make a disparaging remark about American culture based on one of the following: Walmart, McDonalds, Britney Spears, Backstreet Boys, nuclear weapons, ballistic missile defense, or neo-colonialism.
4. Some Americans will then counter the culture argument with some remark based on one of the following: grooming habits, combined GDP, nuclear weapons, WWI and/or WWII.
5. People reading Slashdot from places that are not the US nor Europe will watch as the Americans get flustered at the European attitude, while the Europeans get flustered at the American attitude,
all the while wondering when they will start listening instead of just waiting for their turn to talk.
Where I work, the trend has been towards the standarization of company wide processes, across all of the disciplines: engineering, HR, IT, etc. The hope was, if they can distill the proper process, they can make incompetent or semi-imcompetent people productive, and make competent people slightly more productive.
IT spending is viewed in the same way. Lots of companies thought that if they just implemented the right file server, or purchasing system, or XML based web services something or other, incompetent people would be productive, customer relations would be quick and helpful, engineers would be free to create, and everything would be puppy dogs and teddy bears and big red balloons.
Only problem: both of these assumptions are wrong.
Every company needs standard processes so that people can be efficient. But no amount of process makes incompetent people competent. Every company needs decent IT, but no amount of IT makes incompetent people competent.
What more companies are realizing, in both process and IT, and probably other areas as well, is that just spending more money (1) is not a good way to get work done, (2) takes resources away from business segments that produce products, and (3) doesn't necessarily make anything better.
IT is now just approaching it true value from the topside because we've all been under the impression that it could magically make our lives better, and it doesn't.
(And just to nitpick, while IT is tech, tech is not IT. There are plenty of tech jobs that aren't IT.)
The truth helps. Just keep speaking the truth, and tell your friends, people on the bus, folks at work.
There are a couple of important points to consider.
* Systems related to national security shouldn't be on the internet in the first place. Sure, that's what its was designed for, to be a comm network that would survive a nuclear strike and still route packets. Of course, plenty of government networks are already physically disconnected. Not firewalled, just not connected. So no Slashdot reading on your power grid terminal. Until we actually start building secure software, cause we don't now, some systems absolutely have to stay disconnected, or connected only through separate, encrypted, physically secure networks.
* Instead of feeping creaturism, maybe its time to actually start worrying about security, ala OpenBSD. Could it be that people would put up with substandard office software and not-so-intuitive file browsers if we guarenteed them that the financial data on their computers would be safe? Would you pay extra for your internet-connected pacemaker (which will probably send data to your doctor) if you knew that somebody couldn't hack it and turn it off? Would your Mom put up with having to learn a confusing operating system if it meant that her Quicken data wouldn't get stolen? I bet mine would.
* And maybe, just maybe, we, as software engineers should stop living up to the low expectations of the marketdroids and the PHBs (oooh look, shiny GUI) and start demanding more of ourselves. The reason that propoganda like this punk is spewing travels so fast is that the computer-using public has been conditioned to expect so little (Oh, another reboot? No big deal. Server's down? Eh, kick it, I'll go get a cup of coffee.)
So, I'd tell people to stop whining, stop freaking out, and stop bowing to the government-media complex's instinct to make everything a damn crisis. Instead of worrying, do something. If you're a software dude, start thinking about robustness and security instead of pretty. If you're a (l)user, start learning how to secure your stuff, and start demanding that they companies you buy from do the same.
>> very advanced VLIW-esque architecture
Ah, yes. EPIC. Explicitly Parallel Instruction Computing. AKA VLIW. EPIC is market-speak. Intel didn't want to admit that it was making a VLIW chip for two reasons:
1. There is only one company that has every sold a VLIW chip that actually worked, and that people bought: TI makes DSPs, where are VLIW. They make tons of money. They are the only ones that ever did it right.
2. There is only one company that has ever made a good VLIW compiler: TI, again.
Lets think briefly about how great EPIC is, using the two main selling points I remember from a presentation I saw on it a few years ago (sorry if my memory is bad, no coffee this morning, I'm not responsible).
1. Instructions are Explicitly Parallel. So, the compiler tells you that these two or four or however many instructions can be executed without worrying about data dependency. Terrific. Assuming that the compiler actually works, which is still an open question.
The only difference between this setup and what's in your Athlon or Pentium4 is that the looking-for-independence is done in hardware on your Athlon instead of by the compiler on your Itanium. This means that there is the *possibility* that EPIC does better at finding independence because the compiler *should* know more about the code when its in a higher level language. *Should*. Essentially, until the science of compilers takes a quantum leap or we start using programming languages that makes these things easier (correct me if I'm wrong, please), Itanium will be at most as fast as a superscalar processor that finds independent instructions on its own and does register renaming.
2. Predicates and conditional execution. While the whole notion of the predicate in EPIC is more complicated and complex than just conditional execution, its not entirely more useful IMHO, or at least that was my impression the last time I heard someone talk about it. Alpha has conditional execution. ARM has conditional execution. I can append checks to the condition codes in ARM assembly. I don't really understand why this is so nifty.
I've said it before, and I'll say it again. Resist the urge to think that whatever marketdroids tell you is new is actually good. Sometimes its not.
(If more knowledgeable people are lurking, please correct any errors I've made, but I think I've got this right.)
> imho it's better to get rid off all the old junk and start over once in a while.
Unless of course you've got an installed base somewhere in the billions, 20 years worth of compiler optimization, a factor of, what 100, more people that know the assembly language, etc. And it doesn't help if good compilers won't exist by the time your chip comes out. And if the internal interface teams have difficulty communicating, you're going to be late, hot, slow, and over-complicated.
Starting over is nice from a design perspective, especially because it feeds the urge for creativity that most engineers have. Unfortunately, that do-over is not always executed well, and it turns out to be a little underwhelming, just like Itanium.
Fight the urge to think that all new things are good. Please.