??? payphone calls once cost a quarter ???
when was this? (is there a timeline of the
(average?) price to use a payphone?
Actually that's a semi-interesting question, I know that it used to be a quarter up until a few years ago (I think in the past two or three years) in the Washington state area. And obviously it used to cost a dime, but thankfully the rate hikes on payphone use aren't as fast or large as postage rate hikes (used to be cheaper to mail someone, now it's cheaper to just call them (practically)).
Pay phones serve their purpose for both emergency calls, and for when the cell phone won't work. I think it's too early to pronounce them dead as well because telephone booths could easily be retrofitted to provide broadband access on the go (for laptops, for example), whereas portable/cellular solutions so far aren't widespread or reliable. (Ricochet still being 28.8 I believe in the Seattle area, where I live.)
Of course, it's not like the phone company is hurting for cash from running them-- the rate hike from a quarter to $0.35 must have been a shot in the arm for their profits.
The solution us to use 64-bit signed integers to represent the time. A big change though, so I don't expect that to happen. Plus, as someone else said, your solution would ruin dates prior to 1970 (which I'm sure some apps use).
Are you talking about compiler errors here? It so then why treat it differently than procedural languages? If not then what's the difference with pointers as they are used in C for example? Further some OOP languages like Java don't allow direct manipulation of pointers, now why blame OOP in general?
I'm not talking about compiler errors, I'm talking about issues with pointer arithmetic (run-time errors), for example, or just off-by-one errors with pointers or memcpy's (again, another example). My point though is that since most compilers output classes (be it in C++ or Pascal/Delphi) they use VMT's that are just arrays of pointers-- if an entry (for example, the entry for the 'Reboot' method) were to be overwritten, then calling the function would either halt the system or (worse) call another function entirely.
I'm not saying OOP is evil, I use OOP everyday in my work, but for mission-critical embedded devices like the Osprey uses, I'd think a more direct approach would be suitable (read: strictly C or low level assembly language). With C or assembler, unless you're using function pointers, these types of things are a lot less likely to happen.
As for Java.. who'd use that in a mission critical environment or embedded device? =)
IMHO OOP will one of the leading contributors to errors in safety oriented software that's used in advanced hardware-- my reasoning being that most OOP software (like Borland Pascal or Borland C++, for example) use VMT that are basically just pointers to functions that correspond to virtual functions or static functions. One poorly used pointer or overwritten memory address and suddenly you're calling the wrong code.
Sure, memory protection afforded by protected mode (on Intel processors, anyway, others have their own 'protection') can help safeguard some of the data used by classes in OOP, but AFAIK most of these embedded products most likely use nothing more advanced than an 8086 or 80186 (really, how much processor power is needed to control rotors and other externally embedded devices?).
But more to the point again, I think it's only a matter of time before bugs like these are fixed and dealt with, it's just too bad it has to lead to the loss of human life before they're found.
...it appears that everything2 has been slashdotted. =)
On a related note though, and seriously, whenever I need a definition for something I either a) forgot or b) literally do not know, I usually find it in the dark recesses of everything2. I've never contributed, but it's definately an awesome service.
Look, I'm not going to engage you in some flamefest where you spit out random unprovable "facts" that you deem to be gospel in your attempt to distort the truth. Anyone who investigates what's out in the media and what's been reported can easily see that HP worked in VLIW before Intel came along, and that the two partnered on Merced. Merced was not completely "fucked up" when they teamed with HP, Merced wasn't even in any sort of development beyond the typical vaporware talk you see at all the large community shows. Your idea that Merced is Intel's own labor of love and that McKinley is HP's own design is also false, based on everything stated so far in the media and on Intel's press site.
Please, don't try to flame me with disjointed half-truths and "facts" that you can't prove. If you have some sort of evidence that can persaude me you're right and I'm wrong, I welcome it, but so far you're just fanning flames and offering no real insight.
Ummm... *HP* came up with IA-64, not Intel. Part of the deal for Intel to deploy it was that HP wouldn't claim any credit for IA-64, OR for McKinley, which they also designed.
You're going to have to find another example of recent Intel innovation.
Actually I won't-- Intel and HP co-designed the technology. That's not a big secret that somehow instantly obliterates my opinion. It's a fact that HP was working on VLIW technology before Intel came along, and it's also a fact that the same research into VLIW went into the design of IA-64. But for you to say IA-64 existed before Intel got involved is erroneous. It wasn't until after they allied themselves that IA-64 was designed using technology created by both entities that it took shape. Regardless, it's still innovative and a vast departure from the x86 platform we deal with today.
Cool, I never checked out the Black Book edition because I figured it was just a re-release of his Zen of Graphics Optimization; if it really has Zen of Code Optimization as well then it'll be a real treat for developers/students since that was really the best text demonstrating how effective careful and sensible code optimization really was.
I've got both books seperately though, the only one I didn't have was Zen of Assembly Language, a book that was later included in electronic format on one of his books CD-ROM's anyways..
No one uses assembly anymore to draw the the fancy triangles on the screen and this book is full of examples like this.
I disagree, there are plenty of things that can be improved through assembly language, and through careful optimization of code. Especially with new instruction set enhancements such as MMX, 3DNow!, SSE and SSE2. Lest anyone reading here forget, Michael Abrash, already an accomplished developer, worked with id Software when they were working on the original DOS-based Quake. He talked about more than just graphics optimization, he talked about actually making the code DO less by arranging data intelligently. (Clearly something that can benefit developers to this day-- things like not rendering non-visible polygons are ideas that I got from Abrash's written works, and he has a whole treasure trove of good tips and ideas that can still be applied to todays work.)
Definately worth a good read, along with his 'Zen of Code Optimization'.
-- is an excellent author, and programmer. Even though I own it (and some of his other works) I sure hope they release 'Zen of Code Optimization' out to the public. A *very* nice book that covers the basics of code optimization that you'd be surprised most developers don't know or aren't thinking of while they code. Filled with more funny story lead-ins for each chapter as well, and a lot of personal information that kind of increases the interest overall in the topic at hand.
If you've never read this book, or his Zen of Code Optimization book, I definately suggest trying to pick it up from a library or (I'm sure it's out of print, but worth a shot) book store.
Uhh.. you sure you didn't just get x86-64 (AMD's 64-bit extension) and IA-64 confused here? x86-64 is essentially just another operating environment, IA-64 is a whole new instruction set. The Itanium is no more like a Pentium/PII/etc. than a DEC Alpha or SUN UltraSparc III is! AMD's plan was to fix one or two of the problems with x86 (ie the addressable memory area, lack of registers and stack based FPU), but otherwise keep compatability with old code. Of course, only having 16 registers (vs. 8 in x86) isn't all that much of a "fix" and using SSE2 to "fix" the stack-based FPU isn't as useful as had been hoped, but I digress...
Intel's documentation describes the IA-64 environment as just another operating mode, albeit a totally alien mode (real mode and protected mode atleast have the luxury of sharing the same environment-- registers, stack, etc. IA-64 has completely different registers or aliases IA-32 registers to IA-64 registers). IA-64 also has 128 general purpose registers and 128 floating point registers-- far more than SSE/SSE2 provided (weren't SSE's registers just aliases of ST (the normal FPU reg's)? I know MMX registers were just aliased ST registers.).
If you ask me though, talking about IA-64 is more like questioning Intel's competency then complementing it's innovation. IA-64 is now over 3 years late (first planned release for the Itanium was 1997, with early '98 being the first published date), and it's beginning to look like it's performance is going to be competive with chips that were out 3 years ago! To be fair, though, the Itanium is dead anyway, even Intel's all but given up on it in favour of the McKinley.
No disagreement here, you're right that Merced is WAY late, well beyond vaporware. The thing is though, Intel is starting to show the technology off and getting it into vendors hands in limited quantities. There's no doubt that the first iteration will flop as a processor in the market, but the thing is, atleast it's there and future iterations of the core will likely yield much better results. (EG: McKinley, as you stated.) How this relates to AMD vs. Intel as far as 'innovation' is again easy, Sledgehammer just extends IA-32-- IA-64 re-writes the whole mess and starts from scratch: new bytecode, new instructions, new environment, new everything, and an optimized (hopefully) core to run it all. Intel can't do much more with their IA-32 cores that they haven't already tried, the only way to make it run faster is to change the rules. (IMHO, of course.)
From my perspective (& I think most consumers) it's looking at Intel (with IA-64) & finding you need to buy not only a new computer, but new software as well because this "innovation" makes your old software run slower than my old 486DX2 50 with anything not coded for it...
Some people got ahold of early test processors and ran some old code on it, big deal. I'd hardly say that's how the real thing will perform.
In comparison AMD has created an open standard allowing full backwards compatibality while advancing the architecture to do similiar functions as what Intel did... Same software runs just as fast (if not faster)...
Uh, there's nothing closed about Intel's standards either-- or did you miss the part where I said they literally GIVE AWAY manuals with PAGES of information on both their assembly language mnemonics and the actual byte-code output by IA-64 compilers?
Hmm well I'm goign to choose AMD over Intel here... So it may not be "innovation" even if it is a new step up for x86 (similiar to when they went to using RISC-style core logic), it's still what makes sense to keep things runing without huge expenses... Heck do business users/home users need more than x86 anyways?
I'm glad you think technology is at a stand-still and that the x86 architecture, which was designed in the 70's, should carry us through the new millenium. Thanks, but no thanks-- it's clear from the extensions that BOTH AMD and Intel have added (MMX, SSE, 3DNow! and so on) that the architecture was never intended to be used for the tasks that are being asked of it. CISC is reason enough to ditch it.
Well that is your opinion... I wouldn't agree completely... I think what we have works & works pretty well for most things...
For most things.. right now. What are we supposed to use in 2-3 years or 5-10 years? More of the same, just smaller die and more transistors? The architecture was never meant to scale this far, and new architecures have been found since the original x86 that perform better and faster at a lower clock speed. This is why an 800 Mhz Itanium may well perform better than a 1.2 GHz Thunderbird when running native code.
We already complain about how coders & compiler writers can't seem to optimize code very well... This is just the worst thing possible when you think about it... Yes lets rely on peopel who don't have the time/desire to optimize for existing archs by requiring them to do so... Sure great 'innovation'...
I said compiler, I never said coder. Compilers for IA-64 would be responsible for ordering instructions properly such that they can be executed in parallel (IA-64 makes this process much easier and actually encourages executing multiple paths of code at the same time, taking branch prediction to a whole new level). Compiler writers don't tend to make the same poor choices in instruction selection as your typical lazy C++ or Visual Basic coder will.
Um no, this is not who it really works... IA64 is a VLIW arch which isn't even somewhat compatible with x86 on a internal level... It's not a 'new mode' but a complete replacement that has a 'compatability mode' of sorts which is incredibly slow & obviously not native to the cpu's core instruction set...
Actually you're wrong, and unfortunately not for the last time-- it **IS** just another operating mode as I described. You can freely switch (upon using CPUID to detect the presence of it anyways, unless you want to non-compatible with non-IA64 processors) between IA-64 code and IA-32 code (protected mode or real mode). This allows 32-bit OS's to take advantage of the new instructions without re-writing the entire thing from scratch as IA-64. It's a clear win for backwards compatibility because it gives software developers a chance to continue using their older IA-32 code whilst developing on an IA-64 platform, and vice versa.
frankly after reading this I don't believe your an 'assembly language programmer' or if you are you haven't finished reading those 'ver 1,000 pages!' of information on IA64...
Frankly I don't care what you believe-- I enjoy my work and I enjoy developing software in multiple languages (x86 being something I particularly enjoy writing). You're right about not having read all 1,000 pages of the Intel documentation though-- my company doesn't develop IA-64 solutions yet because we obviously don't have the hardware to test and develop on! I've really only read Volume I and Volume II, Volume III, the instruction set reference, I've only skimmed through to see what kind of instructions the architecure provides and how it relates to what the previous volumes discussed. I'll finish it eventually though, rest assured.
Hardware companies are building jets, and most software companies are simply building bigger biplanes with gold plated instruments, leather seats, and a teak prop.
I agree with you 100%-- but thankfully solutions are presenting themselves and eventually this will hopefully become a non-issue.
As a software engineer though, I tend to try to optimize my code wherever possible, hence why I'm usually the only developer here that reads x86 instruction reference manuals, or pours over assembler code like it's not big deal.
The thing is, most people just stick with what their compiler outputs and assume it's "good enough" and not worth optimizing-- never once bothering to throw their code under a profiler and see where the most CPU cycles are wasted. Merely doing that can lead to incredible speed increases, or atleast a better understanding of what code is eating up the most time. This can lead to more efficient re-writes, or better implementations. Here's my own personal example though--
I was given the task of writing something simple-- a UTF-8 decoder that would translate UTF-8 encoded strings to normal 8-bit ASCII strings (unicode characters would be left encoded). This was for Win32, so I tried three things--
MultiByteToWideChar (Win32 function)
Pascal/Delphi translation using shl, etc.
x86 assembler version (quickly, but carefully, written)
As it turned out, my results went something like this-- the x86 assembler code performed the task 3x - 4x faster than MultiByteToWideChar. The x86 code performed 1.5x - 2x faster than the Delphi code I wrote. Clearly the short time I spent writing it in assembler paid off, and considering how often this code is called inside our code, it was well worth it. Besides this, calling MultiByteToWideChar yielded a unicode result, not an ASCII result, so there was also the issue of memory use and the fact that Delphi had to silently translate the unicode characters back to 8-bit ASCII.
I think it's a good example of how developers can put the processor to use. People in IT, specifically developers and engineers, should quit dismissing x86 assembler as merely driver lore or as some black art. Sure, it's not as neatly portable as C or C++ or Java (although I argue that those aren't very portable as it is anyways), but with LITTLE work, most assembler functions (like the one I wrote for the task above) can be translated for use under any OS in almost any language that can link in external assembler code.
My point? There's hope out there yet for less bloatware and more screamware.;)
Yeah, and if you pit a 800Mhz Itanium against a 2Ghz Sledgehammer, I'd be very interested to see who is victorious.
Against the first run of Itanium's (IA-64), sure, I wouldn't be surprised if the Itanium got beat. You're not figuring in the fact that the Sledgehammer is running on a tried and true platform, just adding in new instructions and a few registers. IA-64/Itanium is an entirely different architecture, and will take time to mature (hence the huge delays since Merced/Itanium were originally announced many moons ago). Innovation doesn't occur overnight, and it doesn't always perform as planned right out of the gate. In the long term, IA-64 will eventually displace IA-32 in both the server sector and in the consumer sector; in the short term, IA-64 will be geared towards high-performance servers and workstations. The platform lends itself well to SMP, and it scales VERY well. I'd say in one and a half to two years from the date of first shipment of IA-64 CPU's we can expect to see some good numbers coming from that core.
You've got that backwards - AMD owns the desktop retail sector. Intel owns the server market and laptops.
AMD's 760MP SMP chipset coupled with the incredible 1.5GHz AMD Palomino just shown at CeBIT are going to be used in servers from Compaq and apparently IBM also.
No, I don't have it backwards. For the hobbyist, I won't deny for a second that AMD is kicking Intel's ass from here to [some city far from where you live]. In the RETAIL MARKET, AMD still hasn't got all of the OEM's and major PC manufacturers sewn up. It's all a matter of perspective I guess, I mean, I wouldn't mind if AMD beat the snot out of Intel, maybe it'd cause them to get their products out faster or be more competitive with their prices (especially for things like the Pentium 4, which performs worse but costs more than a Pentium III 1GHz). I think the competition is bringing some good things out, but I definately don't see AMD "owning" the retail sector.. that's just AMD evangelizing hard at work.
Go ahead, walk into Cicuit City, CompUSA, or any other computer store retailer and take a head count of Intel systems vs. AMD systems. That's what the non-tech saavy consumer sees. And that's what drives retail sales (that, and I've never seen an AMD television commercial, have you?).
AMD is definately on the right track with their Athlon product line, and the follow-ups they've made to it since, but they've still got a way to go with public relations.
Ack! What I actually meant by this is that IA-64 is one example of an innovation... however, concerning their x86 line of CPU's, Intel hasn't been all that innovative... all of the improvements made to the Pentium (ie. branch prediction, out-of-order execution, etc.) have been done before. Sorry for the confusion.:)
Well, they have been innovative where it counts, new instructions. MMX, SSE and SSE2 are VERY well designed and suited to the tasks that are common-place now-- multimedia experiences. (Be it games, playing movies, working with audio or video, etc. these instructions are a singificant help if present. I think MMX got more of a beating from the popular media than it deserved, considering how well the instructions perform when used properly.)
Branch prediction, out of order execution and so on, I agree, nothing new really except that those philosophies had never been applied to the x86 core. But definately not new ideas.
Every CPU that they have offered in recent years has been based on the ancient Pentium Pro core (the PII, PIII, and Celeron are all based on a P-Pro core). Finally they come out with the P4 and, frankly, its performance does not do justice to its gestation period.
You mock their use of the old Pentium Pro core, but I think of it as being proof of their excellent core design skills. For a core THAT old to still be giving birth to new products TODAY is a testament to how well designed it was. (And also gives reason as to why Intel is losing the coveted speed race-- the PPro core was never designed to go as far as it has, it just did simply because it was designed so well to begin with.) You'll receive no arguement from me about the Pentium 4, it was a big mistake to make the cuts they did (dropping their L3 cache entirely and cutting back on their L2 cache from the original specs). The final nail in the P4's coffin has got to be the lack of good FPU support-- SSE2 might be a great technology once it receives more adoption, but for older software or discontinued software, the P4 was a major blow.
You also ignore their laughably bad motherboard chipsets. Until recently, if you wanted top performance and stability, you went with the 440BX, which was designed years ago.
I'm not a big fan of Intel chipsets, but the topic was processors, not core logic chipsets. Again, you'll get no arguement from me about their dealings with Rambus and their chipset problems (i820, etc). Although, to be fair, the i815e IS a nice chipset, it's just too bad Intel caved into what MUST have been pressure from Rambus to neuter the chipset to only accept 512MB PC133 max.
Is it "innovation" or "let's add stuff to lock more people into our products!"?
It's innovation-- take your own question and apply it back to the original x86 architecture. Was Intel locking anyone into their products then? The answer is yes, but as everyone here on/. is aware, emulation isn't illegal and nobodies stopping AMD from making their own compatible version of IA-64 (the specs are all out there for the taking, check out developer.intel.com, and Intel will even ship, FOR FREE, IA-64 manuals to you that weigh in at over 1,000 pages!).
So Intel has added as of yet unused and so far unnecessary registers to a new operating mode which can (will?) potentially lock consumers into their products as software gets written to take advantage of said (dubious and patented) innovations?
Wrong. You clearly aren't an assembly language programmer-- the biggest problem with x86 CPU's is the LACK OF GENERAL PURPOSE REGISTERS. IA-64 addresses this problem using these methods--
128 General Registers (64-bit)
128 Floating-point Registers (82-bit)
As you can see, compared to the number of registers available in the 386 through to the Pentium 4, this is a HUGE number. (FYI: The Pentium III has 4 32-bit general purpose registers, 6 if you count ESI and EDI, 7 if you can safely use EBP. There is also a similarly low number of FPU registers, again, Intel has addressed this with IA-64.) These registers would not go unused, and they are VERY necessary. The kind of optimizations this will open up are mind-boggling to an assembly programmer.
While AMD has simply taken an existing operating mode, added a few general purpose and non-proprietary registers, and improved the overall design and performance of a tried-and-true architecture with known quantitative qualities?
You're suggesting that Intel sticks with an admittedly broken and ancient architecture? Intel has stretched the x86 core as far as it's going to go, the only innovation that can occur now is with a changing of paradigms and a changing of actual instruction sequencing. IA-64 puts more of the burden on the compiler to figure out what code is trying to do, and puts less of the stress on the run-time architecture (not to belittle the IA-64's strong architecture, simply that it's taken a much more RISC approach than their x86 processors have).
All of your points about cost of innovation and so on are moot-- it wouldn't be innovation if Intel stuck with the status quo. AMD isn't innovating, AMD is copying and now trying to extend x86 to last a little longer. Intel wants to ditch the x86 architecture but still leave a migration path for older users (hence the 'IA-64 is just another mode of the processor' trick-- code can switch at will from IA-64 mode to protected mode to real mode and back, and real mode/protected mode code can take advantage of IA-64 if the mode exists without using an IA-64 OS). In the end, one is innovation and one is just an attempt to keep the x86 around that much longer.
I'm not anti-AMD, but to say that Intel isn't trying to innovate and is instead trying to force people to adopt some new hardware of theirs is just plain wrong. I don't think either company is trying to do that, or else we'd see a total dismissal of the x86 instruction sets-- but instead, we're seeing both AMD and Intel keep the x86 around in both their 64-bit implementations as legacy support.
I don't know if I think of AMD as a second class CPU maker/distributor, but I still hold Intel in a higher regard simply because they tend to offer more in the way of innovation.
Take a look at Itanium (or their IA-64 instruction set) vs. AMD's Sledgehammer core-- IA-64 is just another operating environment, like Protected Mode was to Real Mode, except that IA-64 processors start out in IA-64 mode instead of having to switch modes after being reset. Sledgehammer, AFAIK, is just new instructions without a new operating mode. IA-64 introduces a HUGE number of general purpose CPU registers (no more EAX, EBX, ECX, EDX, EDI, ESI limitations!) while (from an admittedly brief review) AMD adds a total of 8 general purpose registers.
AMD is definately a lot different from their start-up days, and it's nice to see them trying to innovate with technologies like 3DNow! (and even nicer to see adoption of their technology alongside Intel's own technology), but I still see some work to be done before they get the major acceptance Intel enjoys in the marketplace (and not the hobbyist).
(Before anyone flames me, I know Gateway and other companies offer AMD processors in some of their offerings, but in general you still see a much larger number of Intel processors out in the retail sector vs. AMD processors.)
Mini-Discs aren't a total flop, yet. I definately agree that they haven't met with the widespread acceptance of CD's, but then they came out at what was probably the height of CD's lifespan. I think if Sony was doing this as 'the big new thing' today and was starting all over, it might meet with better acceptance.
One thing that concerns me is DVD-Audio-- while the normal human (or one who doesn't listen to music that could take advantage of it) won't hear the difference between DVD-Audio and CD, for people who listen to classical or other appropriate kinds of music, this format will be a boon-- now I wonder if these formats can peacefully co-exist, or if the higher quality (but larger media) will lose out. I tend to think people will lean towards media that can fit in your pocket amongst your keys/change, but for home theatre-types, DVD-Audio should reign supreme.
BTW: What's so poor about the durability of CD media? If properly taken care of, the media can last almost indefinately-- compared to cassettes which will ALWAYS lose quality over the passage of time, and are MUCH more sensetive to mother nature than a CD is. (Both suffer from long durations in direct sunlight, but only cassettes suffer from being placed near a large magnetic source, AKA: a speaker.)
Actually I always thought the Gameboy Color looked more like a portable NES, and the Gameboy Advance looked more like a portable SNES (albeit with smaller screen and lower resolution-- it's got the mode-7 type scaling/rotating features though!).
I just hope Capcom's Super Street Fighter II looks good on this small of a screen. =)
Actually it's a lie-- it's not an updated Mario 3, it's an updated Super Mario Mario 2 (the lame filler one that had weird vegetable picking crap). I personally would rather that they had released a game that had the same look and feel as Super Mario World (Super Mario 4), especially since the hardware on this thing could have easily done it.
Oh well, maybe their next Mario game on the GBA will take advantage of that-- or mebbe Zelda on this thing will look like A Link To The Past did on the SNES.
I just hope Nintendo realizes that a large portion of gamers today are adults, and leaves the Pokemon crap off of this system.
You just KNOW Nintendo will dive right in with a Pokemon game at launch, or closely afterwards. I just hope 3rd parties jump on board for this system (which so far seems to be happening) more than they did for Nintendo's N64 console. Capcom appears to be porting their popular titles (Super Street Fighter II is listed as one of the games in development for the GBA), and I believe I saw some Konami titles further up on Nintendo's games list.
Will I buy one though-- **absolutely**. $99 is a little much (Japan is getting it for around $82), but it's still reasonable and well, I can't help it, I love the idea of playing 4-player Mario Kart Advance. =)
...that this story gets posted right after the 'micropayments vs. advertising' story.
It'd be REALLY nice if we could live with banners the size they are now, but unfortunately I can see their point of view on this:
The advertisers realize that screen sizes are increasing, the resolutions at which typical end users are increasing and thus their segment of the physical screen is decreasing. 19 inch monitors are becoming common-place, and 17 inch monitors are entering the low-end space formerly occupied by 15 inchers. What's an advertiser to do, faced with a smaller footprint on the screen? Insist on larger space of course!
Now, am I defending this move? No. I think the whole point of larger screens is so you have more space to do your actual work in, NOT so some dumbass advertiser can annoy me even more with Flash animations or larger and more distracting GIF animations (the former being particularly annoying to me now-- I never noticed them before, but recently when I've hit ESC in IE to stop the pages animations, I've noted that the Flash animations CONTINUE, eating up more CPU cycles than the GIF images did).
My suggestion to people who get as annoyed by this as me? Don't frequent sites that have this kind of "user-experience killing" advertising.. A prime example is C|Net-- I don't visit their site anymore, and haven't for months.
Slashdot Mirror
Actually that's a semi-interesting question, I know that it used to be a quarter up until a few years ago (I think in the past two or three years) in the Washington state area. And obviously it used to cost a dime, but thankfully the rate hikes on payphone use aren't as fast or large as postage rate hikes (used to be cheaper to mail someone, now it's cheaper to just call them (practically)).
...even if we'd rather not admit it.
Pay phones serve their purpose for both emergency calls, and for when the cell phone won't work. I think it's too early to pronounce them dead as well because telephone booths could easily be retrofitted to provide broadband access on the go (for laptops, for example), whereas portable/cellular solutions so far aren't widespread or reliable. (Ricochet still being 28.8 I believe in the Seattle area, where I live.)
Of course, it's not like the phone company is hurting for cash from running them-- the rate hike from a quarter to $0.35 must have been a shot in the arm for their profits.
The solution us to use 64-bit signed integers to represent the time. A big change though, so I don't expect that to happen. Plus, as someone else said, your solution would ruin dates prior to 1970 (which I'm sure some apps use).
I'm not talking about compiler errors, I'm talking about issues with pointer arithmetic (run-time errors), for example, or just off-by-one errors with pointers or memcpy's (again, another example). My point though is that since most compilers output classes (be it in C++ or Pascal/Delphi) they use VMT's that are just arrays of pointers-- if an entry (for example, the entry for the 'Reboot' method) were to be overwritten, then calling the function would either halt the system or (worse) call another function entirely.
I'm not saying OOP is evil, I use OOP everyday in my work, but for mission-critical embedded devices like the Osprey uses, I'd think a more direct approach would be suitable (read: strictly C or low level assembly language). With C or assembler, unless you're using function pointers, these types of things are a lot less likely to happen.
As for Java.. who'd use that in a mission critical environment or embedded device? =)
IMHO OOP will one of the leading contributors to errors in safety oriented software that's used in advanced hardware-- my reasoning being that most OOP software (like Borland Pascal or Borland C++, for example) use VMT that are basically just pointers to functions that correspond to virtual functions or static functions. One poorly used pointer or overwritten memory address and suddenly you're calling the wrong code.
Sure, memory protection afforded by protected mode (on Intel processors, anyway, others have their own 'protection') can help safeguard some of the data used by classes in OOP, but AFAIK most of these embedded products most likely use nothing more advanced than an 8086 or 80186 (really, how much processor power is needed to control rotors and other externally embedded devices?).
But more to the point again, I think it's only a matter of time before bugs like these are fixed and dealt with, it's just too bad it has to lead to the loss of human life before they're found.
...it appears that everything2 has been slashdotted. =)
On a related note though, and seriously, whenever I need a definition for something I either a) forgot or b) literally do not know, I usually find it in the dark recesses of everything2. I've never contributed, but it's definately an awesome service.
Look, I'm not going to engage you in some flamefest where you spit out random unprovable "facts" that you deem to be gospel in your attempt to distort the truth. Anyone who investigates what's out in the media and what's been reported can easily see that HP worked in VLIW before Intel came along, and that the two partnered on Merced. Merced was not completely "fucked up" when they teamed with HP, Merced wasn't even in any sort of development beyond the typical vaporware talk you see at all the large community shows. Your idea that Merced is Intel's own labor of love and that McKinley is HP's own design is also false, based on everything stated so far in the media and on Intel's press site.
Please, don't try to flame me with disjointed half-truths and "facts" that you can't prove. If you have some sort of evidence that can persaude me you're right and I'm wrong, I welcome it, but so far you're just fanning flames and offering no real insight.
Actually I won't-- Intel and HP co-designed the technology. That's not a big secret that somehow instantly obliterates my opinion. It's a fact that HP was working on VLIW technology before Intel came along, and it's also a fact that the same research into VLIW went into the design of IA-64. But for you to say IA-64 existed before Intel got involved is erroneous. It wasn't until after they allied themselves that IA-64 was designed using technology created by both entities that it took shape. Regardless, it's still innovative and a vast departure from the x86 platform we deal with today.
Cool, I never checked out the Black Book edition because I figured it was just a re-release of his Zen of Graphics Optimization; if it really has Zen of Code Optimization as well then it'll be a real treat for developers/students since that was really the best text demonstrating how effective careful and sensible code optimization really was.
I've got both books seperately though, the only one I didn't have was Zen of Assembly Language, a book that was later included in electronic format on one of his books CD-ROM's anyways..
I disagree, there are plenty of things that can be improved through assembly language, and through careful optimization of code. Especially with new instruction set enhancements such as MMX, 3DNow!, SSE and SSE2. Lest anyone reading here forget, Michael Abrash, already an accomplished developer, worked with id Software when they were working on the original DOS-based Quake. He talked about more than just graphics optimization, he talked about actually making the code DO less by arranging data intelligently. (Clearly something that can benefit developers to this day-- things like not rendering non-visible polygons are ideas that I got from Abrash's written works, and he has a whole treasure trove of good tips and ideas that can still be applied to todays work.)
Definately worth a good read, along with his 'Zen of Code Optimization'.
-- is an excellent author, and programmer. Even though I own it (and some of his other works) I sure hope they release 'Zen of Code Optimization' out to the public. A *very* nice book that covers the basics of code optimization that you'd be surprised most developers don't know or aren't thinking of while they code. Filled with more funny story lead-ins for each chapter as well, and a lot of personal information that kind of increases the interest overall in the topic at hand.
If you've never read this book, or his Zen of Code Optimization book, I definately suggest trying to pick it up from a library or (I'm sure it's out of print, but worth a shot) book store.
Intel's documentation describes the IA-64 environment as just another operating mode, albeit a totally alien mode (real mode and protected mode atleast have the luxury of sharing the same environment-- registers, stack, etc. IA-64 has completely different registers or aliases IA-32 registers to IA-64 registers). IA-64 also has 128 general purpose registers and 128 floating point registers-- far more than SSE/SSE2 provided (weren't SSE's registers just aliases of ST (the normal FPU reg's)? I know MMX registers were just aliased ST registers.).
If you ask me though, talking about IA-64 is more like questioning Intel's competency then complementing it's innovation. IA-64 is now over 3 years late (first planned release for the Itanium was 1997, with early '98 being the first published date), and it's beginning to look like it's performance is going to be competive with chips that were out 3 years ago! To be fair, though, the Itanium is dead anyway, even Intel's all but given up on it in favour of the McKinley.No disagreement here, you're right that Merced is WAY late, well beyond vaporware. The thing is though, Intel is starting to show the technology off and getting it into vendors hands in limited quantities. There's no doubt that the first iteration will flop as a processor in the market, but the thing is, atleast it's there and future iterations of the core will likely yield much better results. (EG: McKinley, as you stated.) How this relates to AMD vs. Intel as far as 'innovation' is again easy, Sledgehammer just extends IA-32-- IA-64 re-writes the whole mess and starts from scratch: new bytecode, new instructions, new environment, new everything, and an optimized (hopefully) core to run it all. Intel can't do much more with their IA-32 cores that they haven't already tried, the only way to make it run faster is to change the rules. (IMHO, of course.)
Some people got ahold of early test processors and ran some old code on it, big deal. I'd hardly say that's how the real thing will perform.
In comparison AMD has created an open standard allowing full backwards compatibality while advancing the architecture to do similiar functions as what Intel did... Same software runs just as fast (if not faster)...Uh, there's nothing closed about Intel's standards either-- or did you miss the part where I said they literally GIVE AWAY manuals with PAGES of information on both their assembly language mnemonics and the actual byte-code output by IA-64 compilers?
Hmm well I'm goign to choose AMD over Intel here... So it may not be "innovation" even if it is a new step up for x86 (similiar to when they went to using RISC-style core logic), it's still what makes sense to keep things runing without huge expenses... Heck do business users/home users need more than x86 anyways?I'm glad you think technology is at a stand-still and that the x86 architecture, which was designed in the 70's, should carry us through the new millenium. Thanks, but no thanks-- it's clear from the extensions that BOTH AMD and Intel have added (MMX, SSE, 3DNow! and so on) that the architecture was never intended to be used for the tasks that are being asked of it. CISC is reason enough to ditch it.
Well that is your opinion... I wouldn't agree completely... I think what we have works & works pretty well for most things...For most things.. right now. What are we supposed to use in 2-3 years or 5-10 years? More of the same, just smaller die and more transistors? The architecture was never meant to scale this far, and new architecures have been found since the original x86 that perform better and faster at a lower clock speed. This is why an 800 Mhz Itanium may well perform better than a 1.2 GHz Thunderbird when running native code.
We already complain about how coders & compiler writers can't seem to optimize code very well... This is just the worst thing possible when you think about it... Yes lets rely on peopel who don't have the time/desire to optimize for existing archs by requiring them to do so... Sure great 'innovation'...I said compiler, I never said coder. Compilers for IA-64 would be responsible for ordering instructions properly such that they can be executed in parallel (IA-64 makes this process much easier and actually encourages executing multiple paths of code at the same time, taking branch prediction to a whole new level). Compiler writers don't tend to make the same poor choices in instruction selection as your typical lazy C++ or Visual Basic coder will.
Um no, this is not who it really works... IA64 is a VLIW arch which isn't even somewhat compatible with x86 on a internal level... It's not a 'new mode' but a complete replacement that has a 'compatability mode' of sorts which is incredibly slow & obviously not native to the cpu's core instruction set...Actually you're wrong, and unfortunately not for the last time-- it **IS** just another operating mode as I described. You can freely switch (upon using CPUID to detect the presence of it anyways, unless you want to non-compatible with non-IA64 processors) between IA-64 code and IA-32 code (protected mode or real mode). This allows 32-bit OS's to take advantage of the new instructions without re-writing the entire thing from scratch as IA-64. It's a clear win for backwards compatibility because it gives software developers a chance to continue using their older IA-32 code whilst developing on an IA-64 platform, and vice versa.
frankly after reading this I don't believe your an 'assembly language programmer' or if you are you haven't finished reading those 'ver 1,000 pages!' of information on IA64...Frankly I don't care what you believe-- I enjoy my work and I enjoy developing software in multiple languages (x86 being something I particularly enjoy writing). You're right about not having read all 1,000 pages of the Intel documentation though-- my company doesn't develop IA-64 solutions yet because we obviously don't have the hardware to test and develop on! I've really only read Volume I and Volume II, Volume III, the instruction set reference, I've only skimmed through to see what kind of instructions the architecure provides and how it relates to what the previous volumes discussed. I'll finish it eventually though, rest assured.
I agree with you 100%-- but thankfully solutions are presenting themselves and eventually this will hopefully become a non-issue.
As a software engineer though, I tend to try to optimize my code wherever possible, hence why I'm usually the only developer here that reads x86 instruction reference manuals, or pours over assembler code like it's not big deal.
The thing is, most people just stick with what their compiler outputs and assume it's "good enough" and not worth optimizing-- never once bothering to throw their code under a profiler and see where the most CPU cycles are wasted. Merely doing that can lead to incredible speed increases, or atleast a better understanding of what code is eating up the most time. This can lead to more efficient re-writes, or better implementations. Here's my own personal example though--
I was given the task of writing something simple-- a UTF-8 decoder that would translate UTF-8 encoded strings to normal 8-bit ASCII strings (unicode characters would be left encoded). This was for Win32, so I tried three things--
MultiByteToWideChar (Win32 function)
Pascal/Delphi translation using shl, etc.
x86 assembler version (quickly, but carefully, written)
As it turned out, my results went something like this-- the x86 assembler code performed the task 3x - 4x faster than MultiByteToWideChar. The x86 code performed 1.5x - 2x faster than the Delphi code I wrote. Clearly the short time I spent writing it in assembler paid off, and considering how often this code is called inside our code, it was well worth it. Besides this, calling MultiByteToWideChar yielded a unicode result, not an ASCII result, so there was also the issue of memory use and the fact that Delphi had to silently translate the unicode characters back to 8-bit ASCII.
I think it's a good example of how developers can put the processor to use. People in IT, specifically developers and engineers, should quit dismissing x86 assembler as merely driver lore or as some black art. Sure, it's not as neatly portable as C or C++ or Java (although I argue that those aren't very portable as it is anyways), but with LITTLE work, most assembler functions (like the one I wrote for the task above) can be translated for use under any OS in almost any language that can link in external assembler code.
My point? There's hope out there yet for less bloatware and more screamware. ;)
Against the first run of Itanium's (IA-64), sure, I wouldn't be surprised if the Itanium got beat. You're not figuring in the fact that the Sledgehammer is running on a tried and true platform, just adding in new instructions and a few registers. IA-64/Itanium is an entirely different architecture, and will take time to mature (hence the huge delays since Merced/Itanium were originally announced many moons ago). Innovation doesn't occur overnight, and it doesn't always perform as planned right out of the gate. In the long term, IA-64 will eventually displace IA-32 in both the server sector and in the consumer sector; in the short term, IA-64 will be geared towards high-performance servers and workstations. The platform lends itself well to SMP, and it scales VERY well. I'd say in one and a half to two years from the date of first shipment of IA-64 CPU's we can expect to see some good numbers coming from that core.
No, I don't have it backwards. For the hobbyist, I won't deny for a second that AMD is kicking Intel's ass from here to [some city far from where you live]. In the RETAIL MARKET, AMD still hasn't got all of the OEM's and major PC manufacturers sewn up. It's all a matter of perspective I guess, I mean, I wouldn't mind if AMD beat the snot out of Intel, maybe it'd cause them to get their products out faster or be more competitive with their prices (especially for things like the Pentium 4, which performs worse but costs more than a Pentium III 1GHz). I think the competition is bringing some good things out, but I definately don't see AMD "owning" the retail sector.. that's just AMD evangelizing hard at work.
Go ahead, walk into Cicuit City, CompUSA, or any other computer store retailer and take a head count of Intel systems vs. AMD systems. That's what the non-tech saavy consumer sees. And that's what drives retail sales (that, and I've never seen an AMD television commercial, have you?).
AMD is definately on the right track with their Athlon product line, and the follow-ups they've made to it since, but they've still got a way to go with public relations.
Well, they have been innovative where it counts, new instructions. MMX, SSE and SSE2 are VERY well designed and suited to the tasks that are common-place now-- multimedia experiences. (Be it games, playing movies, working with audio or video, etc. these instructions are a singificant help if present. I think MMX got more of a beating from the popular media than it deserved, considering how well the instructions perform when used properly.)
Branch prediction, out of order execution and so on, I agree, nothing new really except that those philosophies had never been applied to the x86 core. But definately not new ideas.
You mock their use of the old Pentium Pro core, but I think of it as being proof of their excellent core design skills. For a core THAT old to still be giving birth to new products TODAY is a testament to how well designed it was. (And also gives reason as to why Intel is losing the coveted speed race-- the PPro core was never designed to go as far as it has, it just did simply because it was designed so well to begin with.) You'll receive no arguement from me about the Pentium 4, it was a big mistake to make the cuts they did (dropping their L3 cache entirely and cutting back on their L2 cache from the original specs). The final nail in the P4's coffin has got to be the lack of good FPU support-- SSE2 might be a great technology once it receives more adoption, but for older software or discontinued software, the P4 was a major blow.
You also ignore their laughably bad motherboard chipsets. Until recently, if you wanted top performance and stability, you went with the 440BX, which was designed years ago.I'm not a big fan of Intel chipsets, but the topic was processors, not core logic chipsets. Again, you'll get no arguement from me about their dealings with Rambus and their chipset problems (i820, etc). Although, to be fair, the i815e IS a nice chipset, it's just too bad Intel caved into what MUST have been pressure from Rambus to neuter the chipset to only accept 512MB PC133 max.
It's innovation-- take your own question and apply it back to the original x86 architecture. Was Intel locking anyone into their products then? The answer is yes, but as everyone here on /. is aware, emulation isn't illegal and nobodies stopping AMD from making their own compatible version of IA-64 (the specs are all out there for the taking, check out developer.intel.com, and Intel will even ship, FOR FREE, IA-64 manuals to you that weigh in at over 1,000 pages!).
So Intel has added as of yet unused and so far unnecessary registers to a new operating mode which can (will?) potentially lock consumers into their products as software gets written to take advantage of said (dubious and patented) innovations?Wrong. You clearly aren't an assembly language programmer-- the biggest problem with x86 CPU's is the LACK OF GENERAL PURPOSE REGISTERS. IA-64 addresses this problem using these methods--
128 General Registers (64-bit)
128 Floating-point Registers (82-bit)
As you can see, compared to the number of registers available in the 386 through to the Pentium 4, this is a HUGE number. (FYI: The Pentium III has 4 32-bit general purpose registers, 6 if you count ESI and EDI, 7 if you can safely use EBP. There is also a similarly low number of FPU registers, again, Intel has addressed this with IA-64.) These registers would not go unused, and they are VERY necessary. The kind of optimizations this will open up are mind-boggling to an assembly programmer.
While AMD has simply taken an existing operating mode, added a few general purpose and non-proprietary registers, and improved the overall design and performance of a tried-and-true architecture with known quantitative qualities?You're suggesting that Intel sticks with an admittedly broken and ancient architecture? Intel has stretched the x86 core as far as it's going to go, the only innovation that can occur now is with a changing of paradigms and a changing of actual instruction sequencing. IA-64 puts more of the burden on the compiler to figure out what code is trying to do, and puts less of the stress on the run-time architecture (not to belittle the IA-64's strong architecture, simply that it's taken a much more RISC approach than their x86 processors have).
All of your points about cost of innovation and so on are moot-- it wouldn't be innovation if Intel stuck with the status quo. AMD isn't innovating, AMD is copying and now trying to extend x86 to last a little longer. Intel wants to ditch the x86 architecture but still leave a migration path for older users (hence the 'IA-64 is just another mode of the processor' trick-- code can switch at will from IA-64 mode to protected mode to real mode and back, and real mode/protected mode code can take advantage of IA-64 if the mode exists without using an IA-64 OS). In the end, one is innovation and one is just an attempt to keep the x86 around that much longer.
I'm not anti-AMD, but to say that Intel isn't trying to innovate and is instead trying to force people to adopt some new hardware of theirs is just plain wrong. I don't think either company is trying to do that, or else we'd see a total dismissal of the x86 instruction sets-- but instead, we're seeing both AMD and Intel keep the x86 around in both their 64-bit implementations as legacy support.
I don't know if I think of AMD as a second class CPU maker/distributor, but I still hold Intel in a higher regard simply because they tend to offer more in the way of innovation.
Take a look at Itanium (or their IA-64 instruction set) vs. AMD's Sledgehammer core-- IA-64 is just another operating environment, like Protected Mode was to Real Mode, except that IA-64 processors start out in IA-64 mode instead of having to switch modes after being reset. Sledgehammer, AFAIK, is just new instructions without a new operating mode. IA-64 introduces a HUGE number of general purpose CPU registers (no more EAX, EBX, ECX, EDX, EDI, ESI limitations!) while (from an admittedly brief review) AMD adds a total of 8 general purpose registers.
AMD is definately a lot different from their start-up days, and it's nice to see them trying to innovate with technologies like 3DNow! (and even nicer to see adoption of their technology alongside Intel's own technology), but I still see some work to be done before they get the major acceptance Intel enjoys in the marketplace (and not the hobbyist).
(Before anyone flames me, I know Gateway and other companies offer AMD processors in some of their offerings, but in general you still see a much larger number of Intel processors out in the retail sector vs. AMD processors.)
Mini-Discs aren't a total flop, yet. I definately agree that they haven't met with the widespread acceptance of CD's, but then they came out at what was probably the height of CD's lifespan. I think if Sony was doing this as 'the big new thing' today and was starting all over, it might meet with better acceptance.
One thing that concerns me is DVD-Audio-- while the normal human (or one who doesn't listen to music that could take advantage of it) won't hear the difference between DVD-Audio and CD, for people who listen to classical or other appropriate kinds of music, this format will be a boon-- now I wonder if these formats can peacefully co-exist, or if the higher quality (but larger media) will lose out. I tend to think people will lean towards media that can fit in your pocket amongst your keys/change, but for home theatre-types, DVD-Audio should reign supreme.
BTW: What's so poor about the durability of CD media? If properly taken care of, the media can last almost indefinately-- compared to cassettes which will ALWAYS lose quality over the passage of time, and are MUCH more sensetive to mother nature than a CD is. (Both suffer from long durations in direct sunlight, but only cassettes suffer from being placed near a large magnetic source, AKA: a speaker.)
Actually I always thought the Gameboy Color looked more like a portable NES, and the Gameboy Advance looked more like a portable SNES (albeit with smaller screen and lower resolution-- it's got the mode-7 type scaling/rotating features though!).
I just hope Capcom's Super Street Fighter II looks good on this small of a screen. =)
Actually it's a lie-- it's not an updated Mario 3, it's an updated Super Mario Mario 2 (the lame filler one that had weird vegetable picking crap). I personally would rather that they had released a game that had the same look and feel as Super Mario World (Super Mario 4), especially since the hardware on this thing could have easily done it.
Oh well, maybe their next Mario game on the GBA will take advantage of that-- or mebbe Zelda on this thing will look like A Link To The Past did on the SNES.
I just hope Nintendo realizes that a large portion of gamers today are adults, and leaves the Pokemon crap off of this system.
You just KNOW Nintendo will dive right in with a Pokemon game at launch, or closely afterwards. I just hope 3rd parties jump on board for this system (which so far seems to be happening) more than they did for Nintendo's N64 console. Capcom appears to be porting their popular titles (Super Street Fighter II is listed as one of the games in development for the GBA), and I believe I saw some Konami titles further up on Nintendo's games list.
Will I buy one though-- **absolutely**. $99 is a little much (Japan is getting it for around $82), but it's still reasonable and well, I can't help it, I love the idea of playing 4-player Mario Kart Advance. =)
...that this story gets posted right after the 'micropayments vs. advertising' story.
It'd be REALLY nice if we could live with banners the size they are now, but unfortunately I can see their point of view on this:
The advertisers realize that screen sizes are increasing, the resolutions at which typical end users are increasing and thus their segment of the physical screen is decreasing. 19 inch monitors are becoming common-place, and 17 inch monitors are entering the low-end space formerly occupied by 15 inchers. What's an advertiser to do, faced with a smaller footprint on the screen? Insist on larger space of course!
Now, am I defending this move? No. I think the whole point of larger screens is so you have more space to do your actual work in, NOT so some dumbass advertiser can annoy me even more with Flash animations or larger and more distracting GIF animations (the former being particularly annoying to me now-- I never noticed them before, but recently when I've hit ESC in IE to stop the pages animations, I've noted that the Flash animations CONTINUE, eating up more CPU cycles than the GIF images did).
My suggestion to people who get as annoyed by this as me? Don't frequent sites that have this kind of "user-experience killing" advertising.. A prime example is C|Net-- I don't visit their site anymore, and haven't for months.