In main-sequence stars, the fusion of elements stops at iron, because the fusion of iron atoms into heavier atoms yields no surplus energy -- therefore the reaction isn't sustainable.
Elements heavier than iron are produced in supernovae, where the incredible pressure wave created by the explosion causes the fusion of heavier atoms. Basically, since these fusion reactions don't have a net positive energy yield, they're sucking energy from that of the supernova explosion that precipitated the process in the first place. Now, as to where that energy comes from, that's a bit more complicated, and outside of the scope of this discussion, but you can read about it.
I covered this in my blog (no, I'm not gonna link to it because I don't want to be accused of pimping it -- and besides, I don't want it to be slashdotted), and I found a choice quote reported by Bloomberg:
"Nuclear fusion poses the exact problems of nuclear fission in the production of radioactive waste, the risks of accidents and proliferation," said Frederic Miller, head of Greenpeace France's nuclear campaign, in an e-mailed statement. "France seems hypnotized by this absurd project."
This is factually incorrect. The direct waste product of fusion is helium. Indirect waste products may include materials from the reactor that will become mildly radioactive over time due to neutron flux from the fusion reactions. Yet this nimrod from Greenpeace equates the amount and type of waste produced by fusion to the amount and type of waste produced by fission, and then goes on (incredibly) to bring up the specter of nuclear proliferation.
How a fusion reactor could possibly lead to nuclear proliferation is beyond me. Indeed, how can you portably weaponize the technology used for generating power from fusion reactions? We already have fusion bombs, but they are nothing like the tech needed for sustainable fusion reactions.
This is the worst kind of FUD -- it's based entirely on misinformation and outright ignorance, and preys upon the ignorance of the common man. It's idiocy like this that makes me question much beloved institutions such as freedom of speech. Individuals have the protection of laws which limit speech (e.g., laws against defamation, slander, and libel), but nothing prevents people from making wildly absurd claims that can torpedo funding for a project that will benefit humanity.
The only thing certain about Apple's use of a Pentium M derivative is that it will show up in lower-end desktops (Mac Mini) and laptops (iBook, PowerBook). For premium desktop systems, they'll use whatever the market demands for performance. Considering that a lot of bread-and-butter users of PowerMac hardware are Photoshop and digital video users, I don't think a Pentium M is in the cards for Apple's top-of-the-line desktop systems.
You also forgot one thing... The Xbox 360 CPU will have three VMX units.
I didn't forget. I consider the VMX (aka AltiVec) instructions to be part of the PowerPC instruction set, even though they are technically optional extensions to the instruction set. Furthermore, the VMX units are integrated, one per core, just like the floating point unit. You wouldn't make a modern CPU without a floating point unit, and you wouldn't make one without a vector processing unit either.
But in any cases, Apple was the one that used the Gx monicker, Moto and IBM had other names for their chips (though the G3 was really code-named G3).
Yes, the G4 and G5 designations are really marketing names. However, they are a lot more convenient to refer to classes of PowerPC chips than to start citing part numbers. (There are probably about a dozen varieties of Pentium 4 processor as well, and most people just talk about a P4 without giving specific details about which variant they are talking about unless there's a reason to.)
Microsoft just took the "G5" name prestige and ran with it.
More like they called the Xenon processor a "G5-class" processor, but even that is stretching the truth a bit. (That's more my opinion than fact.) But I challenge you to cite Microsoft marketing material that actually uses the "G5" designation. You'll only find material relating to their use of Apple's G5 PowerMac hardware as their development system, most likely.
Kinda like they used the IBM name in the 80's to sell licenses to make "IBM compatible" machines.
Microsoft never sold computer hardware, nor licenses to make "IBM compatible" hardware. (I'm sure someone will mention one of those ill-fated Microsoft ventures where they co-branded someone else's hardware, but last I checked, they only ever co-branded appliance devices, not general purpose personal computers.)
I guess they are also trying this with the "Xenon" name?
Highly doubtful, since it's not the same as Xeon (as I just pointed out), and it's hard to imagine that someone could confuse a triple-core PowerPC processor for a game console with an Intel processor for servers.
Let's see... the machine after the Xbox 360 will feature a processor called the G6?
Also highly doubtful, as it makes no sense for Microsoft to cash in on an Apple naming scheme (which may in fact be trademarked). Furthermore, I don't see Microsoft's marketing machine trumpeting that the Xbox 360 is a "G5" hardware platform.
This FAQ is generally good -- it assimilates a lot of information found elsewhere on the web. However, it contains some inaccuracies.
Meanwhile, Microsoft has announced that IBM will make 3.2 GHz triple-core G5 derivatives available to Microsoft for Xbox 360.
Actually, the Xenon processor in the Xbox 360 is not a G5 derivative at all, though it shares some pedigree in common with the G5. Each Xenon core most closely resembles the PPE from the Cell processor. The similarity between the G5 and the Xenon core is that they both support the PowerPC instruction set and they both are 64-bit capable. That's about it. The Xenon cores support SMT, whereas the G5 does not. The Xenon cores also lack out-of-order execution logic, which the G5 possesses. You can find out more about Xenon at ArsTechnica.
The PowerPC processor included the capability to emulate 68K instructions, allowing almost all 68K applications to run.
This is false. The PowerPC can't emulate the 680x0 instruction set on its own; the early PowerMacs were shipped with a sophisticated piece of emulation software which allowed "context switching" between running PowerPC native code and 680x0 code. (You may have heard the term CFM, or Code Fragment Manager.) This facility was necessary because many Mac toolbox routines had not been rewritten in PowerPC-native code, and many libraries and other pieces of the OS were similarly only available in 680x0 code. In fact, some toolbox routines were supplied in both PowerPC versions and 680x0 versions, because there were cases where emulated 680x0 code needed to call upon a toolbox routine, and the context switch from emulation to native PowerPC and back again was worse than just running the toolbox routine under emulation.
Anyway, bottom line, the PowerPC never had built-in 680x0 emulation. The design win with PowerPC was that it could be made with the same bus that the 680x0 processors used, allowing Apple to retain much of its existing hardware designs. It should be noted that before the PowerPC was decided upon, some folks wanted Apple to go with the Motorola 88000 series of chips -- these were Motorola's first stab at RISC, and had the virtue of being pin-compatible with the 68000 series. I've seen some Omron workstations that used 88000 processors, but I don't think they ever got a lot of traction in the general market. At least one history of the Mac that I've read indicated that the 88000 was seriously considered within Apple before PowerPC was decided upon.
Support is eventually dropped for all older hardware in the current OS (for example, for PowerPC G3-based systems).
Not all G3-based systems are unsupported in Tiger. I believe G3-based iBooks are still supported, for example. Of course, "supported" doesn't mean you get all the eye candy, but that's true for some lower-end G4 systems as well.
Yeah, saw your apology which you posted as a reply to this, so I'm going to take this rant with a grain of salt.
I fully understood the Gibson reference. Thanks for suggesting that I'm too dim to have gotten it. I read Neuromancer and Johnny Mnemonic (the Gibson novella, not the novelization of the atrocious movie by the same name).
To respond to your points:
Who cares if ECS is a technology company? A sweat shop is a sweat shop, regardless of what industry it services.
Not all sweat shops provide amenities like relaxing gardens next to factory housing, true. However, that doesn't mean that ECS is not a sweat shop just because they provide nice amenities. Evil really does wear a pleasant face sometimes. I would suggest that any company which has "factory housing" is suspect. I consider the practice dehumanizing.
You didn't say it was Gibson's original idea, but you did say "This is a very cyberpunk thing," which implies it's somehow a new idea. You talk about Gibson's concept of a zaibatsu, etc. The reality is, this is nothing new; these things have been with us since the Industrial Revolution. Some of us find truth in yet another aphorism: Those who do not study history are doomed to repeat it. (Speaking of which, it's interesting that you think I'm somehow riffing on Southern Reconstruction when in fact that has little to do with anything I'm talking about. The idea of cradle-to-grave company involvement in the lives of its workers got its start before the Civil War.)
As for your side note... you do realize that some people (like myself) grew up in a time and place where we learned about "slavery to the company store," etc., from listening to our parents and grandparents, not from a dry history book. Not quite the same as living through it yourself, but it's a hell of a lot more palpable when you talk to someone firsthand who did. Of course, my parents had me late in life, so between that and having access to three prior generations of relatives, I have a pretty different perspective from many of my peers. But I would still venture to say that I'm above the median age for Slashdot, and I doubt most people closer to that age would have the kind of perspective that I do.
The idea of a company providing everything for workers from the cradle to the grave predates William Gibson by about a century. Gibson didn't create anything new in his vision of the future -- he just recycled old ideas from the Industrial Revolution and updated them for a different age.
Seriously, haven't you ever heard the phrase "slave to the company store?" Or am I just showing my age?
Anyway, this sort of thing occurs a lot. Many mining and railroad companies in the United States in the late 19th century had similar practices. To this day, many companies around the world that employ "sweat shop labor," as we in the West now call it, provide similar amenities to their workers, rather than actually paying these people enough that they can better themselves.
Although Bit Torrent is a file format and not a P2P Network... [it] is the fastest growing protocol for file sharing online. Many top Bit Torrent sites such as SuprNova, Lokitorren and Bit Tower support millions of downloads daily
I love it! BitTorrent is a file format and not a P2P network! But wait, is it a file format or a protocol? I'm so confused now...
Any slimy company that produces malware and publishes blatantly idiotic statements like the above on its web site deserves some serious smack-down.
Do you have a URL for that? Because I had originally assumed that both of these chips were crippled versions of the 970 core and that accounted for the high clock speed... but when I suggested that in another discussion I wasn't able to find a reference.
Here you go, my friend.:-)
The most direct reference I have is in the middle of an ArsTechnica article. Take a gander at this page. The articles are good reading, though, so to get the full picture, start with part one of the Xbox 360 overview, and then check out part two which focuses more on the CPU.
IBM is showing you a 3-core 3.2 GHz "G5" and a "G5" with 8 integrated DSPs, either of which could have been used in a Powermac if Apple was actually interested in them.
The 3-core 3.2 GHz part you speak of is not a G5. It is a 64-bit PowerPC core, true, but it lacks things like out-of-order execution. It supports SMT (two threads per core, for a total of 6 threads in hardware simultaneously). However, it's not clear that this particular version of SMT will play nicely with Mach. Regardless, this chip is not designed for general purpose computing. It's fine for the Xbox 360, which it was intended for, but that's it.
The Cell processor is also not a G5. It has a 64-bit PowerPC core with SMT support (for a total of 2 threads), and eight SPE units surrounding that. But those SPE units are not DSPs, although they are "DSP-like." Furthermore, Sony will be disabling one of the eight SPEs in each Cell to improve chip yields. Like the other chip you mention, the Cell is not intended for general purpose computing.
Since neither chip is really suitable for a PowerMac, Apple couldn't use them. It wasn't for "lack of interest." There's been some talk of using the Cell for blades or specific embedded applications, but the vast majority of existing PPC Mac software would run poorly on such chips. I can see the Cell being used in a server farm of blades running a tweaked Linux, for very specific computational tasks (crypto, gene sequencing, etc.), but not for a personal computer. The software would have to be custom tailored to the chip's architecture.
Well, it's funny you should mention this, as Apple today published the Universal Binary Programming Guidelines on their developer site. I took a gander through this document, and noticed that a good percentage of it dealt with the differences between vector processing in the two architectures. Some choice quotes:
Before you start rewriting AltiVec instructions for the Intel instruction set architecture, read "Differences Between Instruction Set Architectures" (page 54). If the differences impact your code a great deal, you may want to consider simply rewriting your code to use the Accelerate framework.
To Apple's credit, they are providing a nice API to take the drudgery out of writing your own vector code; they call it the Accelerate framework, and it's been around since 10.3.
Speaking of differences between AltiVec and SSE/SSE2/SSE3:
Integer multiplication algorithms are not equivalent. AltiVec has 13 or so different flavors of integer multiplication with variations. The x86 architecturehas 3 with almost no variations. In certain cases, algorithms designed to showcase the AltiVec multiply-accumulate facility need to be rewritten to showcase the x86 multipliers.
There is no direct translation for vec_perm. There is no way to perform a permute operation on x86 for which the permute map is unknown at compile time. Some byte permutes are also not possible. Operations like byte swapping in an SIMD register, using the permute unit as a lookup table, and using the permute unit to handle alignment simply don't work, or require a prohibitive amount of computation. Vectorization may not be possible for AltiVec code such as small lookup tables that rely heavily on vec_perm(). There is a permute-like shuffle facility (SHUFPS, SHUFPD, PSHUFD, PSHUFLW, PSHUFHW) available. However, the permute map must be determined at compile time, meaning that no run time decisions can be made about how to shuffle the data.
There are no fused multiply-add operations.
There are no x86 counterparts to vec_splat_u8() and vec_lvsl() for generating vector constants. Most vector constants must be loaded from storage. A few such as 0 and -1 can be created with clever application of XOR and the vector compare instructions.
I haven't covered all the bulleted items, just the ones that were of interest to me. I also found the following interesting:
AltiVec only performs aligned loads and relies on a patented permute crossbar to extract a misaligned vector from the two bracketing aligned vectors. While x86 provides aligned vector loads, it doesn't have a permute operation. The long vector left and right shifts take immediate arguments that must be determined at compile time, as do the shuffle instructions. As a result, it is not easy to perform software alignment. The x86 architecture instead provides hardware support for misaligned vector loads and stores.
So, yeah, there are some of the big glaring differences between SSE/SSE2/SSE3 and AltiVec/VMX. Some of the differences are just that, differences. Others are a pain. I have a feeling more developers are going to rely on Apple's abstraction framework rather than hand-tweaking vectorized code, or else they'll rely on auto-vectorization from the compiler. For pre-existing code, though, it's going to be a bitter pill to swallow; nobody wants to throw out painstakingly hand-optimized vector code.
I fail to see how this can have a SIGNIFICANT impact to Apple's install-base in the short term, and only see good things in the long term.
The installed base is hovering around 16%, and will probably remain roughly the same for the next year or two. The market share is hovering around, what, 2%? I have a feeling it will drop to very nearly 0% within the next year. Why? Because no matter what you buy within the next year from Apple, it's obsolete hardware. That is assuming, of course, that Apple really waits until mid-2006 to ship Intel-based hardware.
OK, I'm exaggerating. Some businesses will scarf up PowerPC Macs, either because they've committed to buying them already, or because they have a need in the near-term that Wintel won't satisfy. But I can't imagine many consumers running out to buy Apple hardware, knowing that anything being sold in the next year that's PowerPC based is already obsolete before it even shipped out the door.
I'm saying this as a diehard Mac supporter and Apple lover. I was in the market for a new laptop in the next 6 months, and I was seriously considering a PowerBook to replace my aging iBook. Now? Screw it, I'll just buy an Athlon 64 based laptop and run Linux on it, the way I'm feeling right now. Why buy a PowerBook knowing that there won't be any appreciable hardware revs in the near future?
I'm sure I'll calm down in another couple days, but I don't think my assessment will change. I do, however, think that it would be dumb of me to put a top-flight (not to mention overpriced) video card in my G5 now, unless my Radeon 9600 takes a crap.
The only thing on an Apple Motherboard that isn't regular PC hardware is the PPC CPU. Other than the CPU there's almost nothing proprietary there. PCI, AGP, PC RAM, PC USB chips, PC firewire chips, PC everything.
Um, sorry, but no. There's one huge ASIC on every Apple motherboard, and it requires custom drivers which only Apple can supply. This ASIC would be called a "Northbridge" chip on any x86 PC. Apple makes several different system controller chips for different families of Mac. If Apple were to architect their own system controller chip for x86, as they already have done countless times for PowerPC, then they could lock out clones by simply not publishing the drivers for the ASIC in the Darwin source tree, or by refusing to license the ASIC to third party manufacturers.
Ask anyone who has tried to install certain versions of Windows (e.g., Windows 98) on a PC with certain VIA motherboard chipsets, and you begin to appreciate the need for good low-level motherboard chipset drivers.
Since Apple would almost certainly not build an x86 PC with a BIOS, so the one mechanism that PC hardware has to allow bootstrapping an OS on hardware that it might not have prior knowlege of goes out the window. Apple would likely stick with OpenFirmware, which does the same thing that a PC BIOS does, but in a totally different way.
Of course, this all presupposes that Apple is switching to the x86 architecture. I find it far more likely that Apple will license the PowerPC specs to Intel for producing PPC processors; the next most likely scenario is Apple switching to Itanium or some variant thereof. Since IBM missed some important contractual goals, Apple has acquired a lot of intellectual property rights from IBM pertaining to the PowerPC architecture and its manufacture. At any rate, the keynote is tomorrow morning; we'll know by then.
Yeah, you're right... Smitten, in the sense of being "awe-struck" or "marked by foolish or unreasoning fondness." Thus, the grandparent poster to whom you are referring was saying the exact opposite of what he meant. How... well, I don't know if that qualifies as irony, but it's damned funny.:-)
AFAIK, the Newton got discontinued because there was no demand for it. They weren't selling well, so Apple decided that it wouldn't make them anymore.
Not quite true. Prior to Jobs' return to Apple, the Newton was spun off into a subsidiary of Apple, Newton Inc. Jobs' first act was to reabsorb Newton and then kill the project. It's widely known that Jobs was displeased with the Newton, partly because it was a John Sculley initiative.
As a matter of fact, there was a fair bit of interest in the Newton technology for a whole variety of applications. They were, in fact, turning a profit in that division, which is one of the reasons Apple spun Newton off into a subsidiary. Several companies used Newton technology internally for proprietary applications where the device had benefits over the competition (Windows CE / PocketPC and Palm).
Though the Newton lacked color, it was more advanced than all the competition in every meaningful way. They even ported speech synthesis software to the device (which was never officially released, but I managed to get a copy for my MP2000). The object oriented language, NewtonScript, was designed specifically for low-memory-footprint devices; the inheritance model only required storing the "deltas" between the base class and the derived class. It's the only handheld platform I know of where you could write seamless extensions to the built-in applications and have the extensions behave as if they were meant to be there the whole time. No hacks or kludgery or unsupported patches required. The idea of pluggable "stationery" for the default note-taking app was genius!
I started reading this manifesto, and I was immediately struck by some of the brain damaged logic the writer employs. Here's an example, culled early on from the section on AI:
It has to do with the fact that both the XBox 360 and the PS3's Cell CPU use "in-order" processing, which, to greatly simplify, means they've intentionally crippled the ability to make clever A.I. and dynamic, unpredictable, wide-open games in favor of beautiful water reflections and explosion debris that flies through the air prettily.
This is not only a gross over-simplification, it's flat-out wrong. The "in-order processing" done by the PowerPC CPUs in the Xbox 360 and the Cell processor in the PS3 is simply that -- machine instructions are executed in the order that they are presented to the CPU. In other words, these processors don't do instruction reordering. What does this have to do with AI? Absolutely nothing, really. Sure, instruction reordering would probably improve the performance of unoptimized code -- but good compiler tools will do the instruction reordering at compile time and save the transistors on the chip for more useful things.
When I see drivel like this, I tend to tune out the rest of the message, because it's clear the messenger doesn't know what he's talking about.
Having said that, the author of this manifesto probably has a valid point about the patent issues, though. I would have liked some more citations to back up these claims. Just because someone says these things are true doesn't mean they are. Lots of misinformation gets repeated ad nauseum until people believe it's true, when it really isn't. (Remember the old chestnut about video game consoles being sold at a loss? The truth is, few consoles have been sold at a loss. Of the few that started out being sold at a loss, most became profitable as the economics of mass production came into play. I believe the Xbox is the only current-generation console that's still losing money. The last PS2 redesign made Sony's system ultra-cheap to produce.)
Oh, here's another gem from this "manifesto":
Well... our PC's have hard drives and they still have load times. It's a little thing we like to call copy protection, keeping us from installing the game on the hard drive and passing it on to a friend (especially if said "friend" works the return counter at the store we bought the game from).
Ah, yes, load times in PC games are only the result of copy protection! How silly of me to think that it should actually take time for a non-trivial amount of data to be moved from a hard disk into system memory... I mean, seriously, this manifesto was written by someone with near-zero understanding of how hardware actually works, how computers work.
I guess the G5 running at double the clock speeds of G4 suffers from this dimishing return. IBM should of [sic] said screw it and kept with the G4 mhz speeds.
Not exactly an apples-to-apples comparison, if you'll pardon the pun. The primary supplier of G4 chips is Motorola (now Freescale), not IBM. IBM had been producing G3 chips, and continued to produce them and supply them to Apple while Moto shifted its production focus to the G4. (Apple continued using the G3 in the iBook and eMac lines for quite some time.)
The G5 isn't just a "faster clocked" G4. It's architecturally improved in almost every way. And the bus that the G5 sits on is far more performant than the antiquated bus that the G4 is still saddled with. (Freescale supposedly will be producing dual-core G4 chips with a new and improved bus that will mitigate some of the performance problems with prior G4 bus designs. Those haven't found their way into shipping hardware from Apple. Yet.)
Increasing the clock speed does help. It's just obvious that clock speed isn't everything. The architectural tricks you need to employ to increase the clock speed on the CPU (e.g., deeper pipelines, which increase latency), coupled with the ever-widening gap between CPU speed and DRAM speed (which causes undesirably wait states as the CPU "starves"), mean that continually ramping up clock speed on a single CPU core really is a case of diminishing returns.
We're at the point now where we're running up against thermal problems, yield problems, photolithographic process issues, you name it. And once you realize that doubling a CPU's clock speed (if you're even able to at this stage of the game) won't give you double the real-world performance, where do you turn next for tangible performance benefits? Parallelism is the only other thing we have in our bag of tricks right now.
So, science is so good now that we can predict with 100% accuracy if someone will be able to contribute OR OR OR live a happy life?
The way you phrased this implies that you consider this an either-or (i.e., exclusive-or) proposition. Why?
I know so many people with IQ's over 110, well educated, well employed, good citizens who are miserable. I also know one girl who is in a wheel chair, she has some genetic disorder, and she lights up a room with her smiles and laughs.
Ah, yes, always good to see a reasoned debate filled with... argument by anecdote! (Argument by anecdote is a path to logical fallacy. Your anecdote does not automatically generalize, and therefore, is a poor foundation for inductive reasoning. Induction requires a hell of a lot more data points than one anecdote. And from a deductive standpoint, your analogy fails miserably to prove anything useful.)
Some philosophers have opined that greater intellect increases the capacity for misery, and judging from the other responses your post has generated, I'd say a lot of people who read Slashdot have bought this idea uncritically. However, even if this idea turns out to be correct, that doesn't mean that high intelligence causes misery.
If higher intelligence truly increases one's capacity for misery, what other emotions might also be enhanced by intellect? It seems to me that many geniuses find joy in things that more mundane people can't even fathom. Carl Sagan (perhaps not a genius, but definitely a smarter-than-average person, and a real scientist to boot) sold me on the romance of science with Cosmos. There were some sad chapters in the history of mankind -- the burning of the Library of Alexandria and the Dark Ages, for example -- but Sagan's message was one of cautious optimism. There was a real sense of Joy pervading his work.
Ultimately, the super-intelligent among us have to choose which emotional response to have to the world around them. Yes, high intelligence gives those people a greater capacity for misery and despair, because they realize just how bad some things are when others steadfastly refuse to even see or acknowledge certain problems/issues. But it also gives them reasons to exult that mundanes might not grasp or appreciate.
Many cravenly PC people were quick to jump on you for conflating "wheelchair-bound" with "mentally retarded," but you did mention "some genetic disorder" -- in the absence of more specific information, it's hard to know whether this is a disorder that affects cognition or not. I'll give you the benefit of the doubt and assume that there was some impact on the girl's intelligence. Maybe she's the stereotypical blissfully ignorant mental defective. Personally, I find such stereotypes offensive, not because they paint an inaccurate picture of the mentally retarded (although I feel they do), but because such stereotypes lead people to uncritically assume that stupidity is a blessing. It's not.
The degenerate case is that humanity devolves into a race of happy, rutting beasts whose population is kept in check by disease and available food. Personally, this seems like an awful waste of our potential. I'd rather see us become smart enough to solve our problems, not stupid enough to not be bothered by them.
And now it would appear that all that work on Cobalt, aka PalmOS 6, was squandered. With this new Linux focus, I wouldn't be surprised if what's left of BeOS/BeIA at PalmSource is jettisoned. *sigh*
I had been fervently hoping, as a former BeOS developer and BeBox owner, that the OS would survive in some form. I had some high hopes in the Palm acquisition of the Be intellectual property. Then I noticed that PalmOne kept using PalmOS 5 instead of releasing devices running PalmOS 6 / Cobalt. So I waited, and waited, and eventually stopped paying attention...
And now we have a Linux initiative, and Be's legacy seems to have truly died. Not that I don't like Linux -- I think Linux is a fabulous server OS, and it even has the potential to be a great desktop OS, but BeOS / BeIA had a lot of promise in the handheld arena. Fully object oriented development environment, lightweight threading and messaging, great speed, and modest resource requirements.
As a final note, just want to say that I'm sad to see that PalmSource sat on the Be IP to the point where it became impossible for people to acquire legitimate copies of BeOS for x86, and since development on that product was halted, it simply stopped working on more modern/recent hardware. I think BeOS on x86 was a fantastic hobbyist OS, and it could have survived in that niche with the right support.
This is a fair set of tradeoffs; don't let the marketing people and the kool-aide drinkers tell you different.
OK, jackass, you just crossed the line into insulting me. First off, I have a Master's Degree in Computer Science. Secondly, I have been a professional software engineer for well over a decade now. You, on the other hand, are coming across as an amateur, and probably one with a specific axe to grind.
I tried to be as polite as possible, to counter your "arguments" with facts and observations based on years of experience in the field. But you choose to believe your little fantasies. Fine.
Here's a postcard from reality: I've worked on projects where the scientific number crunching that you claim would never be present in a server app, was in fact present in a server app. Here's another postcard from reality: In a real production environment, you're lucky if you get a chance to profile your code once or twice to identify the top two or three areas with the most CPU utilization (or the biggest I/O bottlenecks, whatever). This is typically not done as part of automated testing, as it is time consuming, and automated testing is usually intended to handle QA issues and to insure that bugs stay fixed (i.e., regression testing).
You make a lot of unsubstantiated claims that further bolster my previous assertion that you're simply ignorant and talking out of your ass. For instance, you claim that the Java class libraries are "mostly shit," but that's a pretty broad blanket statement that actually flies in the face of years of experience to the contrary. Essentially unlimited time to optimize in static compilation? That's great, assuming that the optimizer is (a) guaranteed to generate equivalent code and not break your logic, and (b) actually has runtime knowledge of your code in order to make more effective optimizations. Neither of these is automatically true. The former is often not true -- even commercial compilers such as those offered by Microsoft can generate broken code in optimization, necessitating disabling the optimizer. The latter case is almost always untrue for C and C++ (and similar languages). Even if your compiler is designed to take profiling data as input, all that does is provide hints to the optimizer on where it should spend its time being the most aggressive. There are only so many tricks you can bring to bear in compile-time optimization.
Again, you're arguing in abstractions. I challenge you to put up or shut up, and by that, I mean show me definitive empirical tests. You don't like the paper I cited because it has lots of scientific computation? Fine. Pick your own test case. But you can't deny that there are always going to be some cases where I'm right, and Java will come out on top -- not because it's a better language, not because virtual machines are just that good, but simply because you can always come up with a few cases where Java simply will perform better.
Of course, I don't care about "performs better." I only care about "performs about as well as." And that's certainly the case almost 100% of the time, except for some very low-level bit banging type applications (e.g., video transcoding, audio processing, etc.)
But there's really no point in abusing this thread any further, since it's obvious that no matter what I say, you're going to insist that I'm wrong, even though I never claimed that Java was always faster than C/C++, or even most of the time; I only ever claimed that Java was roughly equally performant to natively compiled languages like C/C++, and that it could outperform such languages in certain cases. I proved my point by citing a research paper.
Your claim is that C/C++ is always more performant, and I proved that your claim is wrong because it is absolute. Your only response was to dismiss the research paper I cited because, to paraphrase you, "nobody does lots of scientific computation in the real world." That's also an
This is starting to get WAY off topic. However, I should point out that your point number 1 is attributable to many things, none of which are directly VM related. Poor programming is indeed to blame in some cases. You speak of "Java desktop apps," but realistically, this must be broken down into three sub-cases: AWT, Swing, and SWT, the three main GUI toolkits available to Java programmers these days. SWT has performance problems on every platform besides Windows, because SWT has only been optimized under MS Windows. AWT is no longer promoted, and seldom used, mainly because it looks clunky and doesn't provide much flexibility. Swing widgets are supposed to be 100% Pure Java, although Swing has been optimized on some platforms (notably OS X optimizes Swing drawing operations using Quartz 2D or similar, depending on version). Obviously, having GUI widgets that are written in an interpreted/JIT-compiled language is not a recipe for performance, especially for applications with rapid visual updates. But then again, a well-designed Swing app will intelligently handle redraw, something I've noticed is hard for some programmers to cope with. After all, when you can live in a Windows world and rely on hardware-acceleration to conceal the fact that your application redraws the same thing a dozen times, your programming techniques will fall flat in Swing. (I've been around long enough to see examples of GUI code in Java written by people who cut their teeth in Windows and X11, and almost invariably, profiling the code revealed cases where redraw was happening far more than it should have.)
Of course, this "desktop apps" argument is kind of a straw man argument, because these days, almost 100% of commercial Java development is on the server side, in J2EE environments like Websphere and WebLogic. Major corporations use J2EE (and JSP/Servlet engines like Tomcat) because this stuff works. It's easy to develop for, the performance is very good when using the Server VM (as opposed to the client VM, which is optimized for processes that don't run 24/7), and the toolset is very rich, which makes productivity very high.
Let's put it this way: Java wouldn't survive if it weren't performant in the server space. So obviously, for some applications, it's superior to the alternatives.
Your point number 2 is another straw man argument in disguise. The fact is that there is a lot of crap C/C++ code out there, and much of it is in libraries that are leveraged by user-written C/C++ applications. However, even ignoring this fact, you can empirically demonstrate with experiment (not so-called "intuition," which often gives incorrect answers -- ask any real scientist) that for some algorithms, a direct implementation in Java may in fact outperform a similar implementation in C/C++. The paper I cited in fact does this type of comparison -- it is an "apples to apples" comparison, implementing the same algorithms in each language and comparing the results.
Nice job on the straw man arguments, though. It's very easy to misrepresent someone else's argument and then tear it down, because you're not really addressing the other person at all; it only looks like you are.
Now, let's talk about your intuition. Most modern JVMs use what is called JIT (or Just-In-Time) compilation of the Java bytecodes. A VM that is tuned to run long-term, such as the server JVM that Sun ships, will cache the JIT-compiled bytecode for immediate retrieval and execution. As another poster pointed out, there are optimizations that can be performed at runtime by inspecting the running code's behavior; these optimizations can and do outperform compile-time optimizations, where the optimizer can only make assumptions about the run-time profile of the running code. Basically, in any case where a static compile-time optimization fails on the C/C++ side, a code implementation on the Java side will be more performant. So there's the counter-argument to your "intuition." Not that this is likely to conv
This "JVMs are ass-slow" argument gets repeated a lot. There have been multiple benchmarks published demonstrating definitively that this is not the case -- in fact, Java can outperform C and C++ in many applications. Here is one reference for you to ponder. Of course, it's easier for most people to parrot hearsay rather than actually rely on empirical evidence to support their opinions.
Note that I'm not saying JVMs are inherently superior for all, or even most, applications. I'm just saying that things are a little more complicated than your one-line zinger would imply. I'm also saying that virtual machines can be very performant, with the right code-translation and caching strategies. (See my other post in another branch of this thread.)
In fact, I worked for Informative Graphics when there was a project underway to get a native port of their Myriad software working under NT on the DEC Alpha processor. The native port worked, but it was substantially slower than the FX!32 emulator running the x86 version, at least after running the x86 version of the app under emulation a few times. (Like the grandparent poster speculated, the emulation cached the results of opcode translation for future reuse. Eventually, almost 100% of the original application was translated and stored in a disk cache.)
Then again, the Myriad code was pretty horribly written, and optimized to only compile well under Microsoft's Visual Studio environment. I was stuck on a horrid project porting the code to HPUX and Solaris using MainWin (which basically was a Win32 implementation on top of X11 / POSIX, a porting library for lazy companies that didn't want to invest time and effort in writing truly portable code or rewriting their UI code). Granted, HP's C++ compiler sucked -- it was AT&T Cfront based, and had to be told how to instantiate templates because it had dain-bramaged template support -- but even when we got this stuff working, it wasn't very performant.
Which brings me to another thought -- if Apple switches to x86 or Itanium, we might be in for similar performance surprises. Some code will obviously benefit from a native recompile, but other code might be more performant with a caching code translation mechanism.
Actually, that's pretty funny, because the specs I read on several web sites specifically mention that the PS3 supports DualDisc. See here, or here, or use Google yourself...
So, ah, it appears that the Blu-Ray drive on the PS3 is apparently engineered to handle thicker discs. Funny enough, the two DualDiscs that I own seem to play fine in the slot-loading head unit in my car. (Granted, it's one of the newest Alpine units, so maybe they engineered it with better tolerances.) I've not seen any slot-loading drives lately that bear any of the warnings you speak of.
Personally, I'd rather have Blu-Ray because it doesn't require a third layer (read as: kludge) the way HD-DVD does to get its capacity. As far as the codecs go, you may well be right that the two competing standards may both support the same codecs, but I'm sure there are some other details (e.g., file system) that further distinguish the two. So I doubt the issue is purely one of capacity.
Slashdot Mirror
In main-sequence stars, the fusion of elements stops at iron, because the fusion of iron atoms into heavier atoms yields no surplus energy -- therefore the reaction isn't sustainable.
Elements heavier than iron are produced in supernovae, where the incredible pressure wave created by the explosion causes the fusion of heavier atoms. Basically, since these fusion reactions don't have a net positive energy yield, they're sucking energy from that of the supernova explosion that precipitated the process in the first place. Now, as to where that energy comes from, that's a bit more complicated, and outside of the scope of this discussion, but you can read about it.
This is factually incorrect. The direct waste product of fusion is helium. Indirect waste products may include materials from the reactor that will become mildly radioactive over time due to neutron flux from the fusion reactions. Yet this nimrod from Greenpeace equates the amount and type of waste produced by fusion to the amount and type of waste produced by fission, and then goes on (incredibly) to bring up the specter of nuclear proliferation.
How a fusion reactor could possibly lead to nuclear proliferation is beyond me. Indeed, how can you portably weaponize the technology used for generating power from fusion reactions? We already have fusion bombs, but they are nothing like the tech needed for sustainable fusion reactions.
This is the worst kind of FUD -- it's based entirely on misinformation and outright ignorance, and preys upon the ignorance of the common man. It's idiocy like this that makes me question much beloved institutions such as freedom of speech. Individuals have the protection of laws which limit speech (e.g., laws against defamation, slander, and libel), but nothing prevents people from making wildly absurd claims that can torpedo funding for a project that will benefit humanity.
The only thing certain about Apple's use of a Pentium M derivative is that it will show up in lower-end desktops (Mac Mini) and laptops (iBook, PowerBook). For premium desktop systems, they'll use whatever the market demands for performance. Considering that a lot of bread-and-butter users of PowerMac hardware are Photoshop and digital video users, I don't think a Pentium M is in the cards for Apple's top-of-the-line desktop systems.
I didn't forget. I consider the VMX (aka AltiVec) instructions to be part of the PowerPC instruction set, even though they are technically optional extensions to the instruction set. Furthermore, the VMX units are integrated, one per core, just like the floating point unit. You wouldn't make a modern CPU without a floating point unit, and you wouldn't make one without a vector processing unit either.
Yes, the G4 and G5 designations are really marketing names. However, they are a lot more convenient to refer to classes of PowerPC chips than to start citing part numbers. (There are probably about a dozen varieties of Pentium 4 processor as well, and most people just talk about a P4 without giving specific details about which variant they are talking about unless there's a reason to.)
More like they called the Xenon processor a "G5-class" processor, but even that is stretching the truth a bit. (That's more my opinion than fact.) But I challenge you to cite Microsoft marketing material that actually uses the "G5" designation. You'll only find material relating to their use of Apple's G5 PowerMac hardware as their development system, most likely.
Microsoft never sold computer hardware, nor licenses to make "IBM compatible" hardware. (I'm sure someone will mention one of those ill-fated Microsoft ventures where they co-branded someone else's hardware, but last I checked, they only ever co-branded appliance devices, not general purpose personal computers.)
Highly doubtful, since it's not the same as Xeon (as I just pointed out), and it's hard to imagine that someone could confuse a triple-core PowerPC processor for a game console with an Intel processor for servers.
Also highly doubtful, as it makes no sense for Microsoft to cash in on an Apple naming scheme (which may in fact be trademarked). Furthermore, I don't see Microsoft's marketing machine trumpeting that the Xbox 360 is a "G5" hardware platform.
Actually, the Xenon processor in the Xbox 360 is not a G5 derivative at all, though it shares some pedigree in common with the G5. Each Xenon core most closely resembles the PPE from the Cell processor. The similarity between the G5 and the Xenon core is that they both support the PowerPC instruction set and they both are 64-bit capable. That's about it. The Xenon cores support SMT, whereas the G5 does not. The Xenon cores also lack out-of-order execution logic, which the G5 possesses. You can find out more about Xenon at ArsTechnica.
This is false. The PowerPC can't emulate the 680x0 instruction set on its own; the early PowerMacs were shipped with a sophisticated piece of emulation software which allowed "context switching" between running PowerPC native code and 680x0 code. (You may have heard the term CFM, or Code Fragment Manager.) This facility was necessary because many Mac toolbox routines had not been rewritten in PowerPC-native code, and many libraries and other pieces of the OS were similarly only available in 680x0 code. In fact, some toolbox routines were supplied in both PowerPC versions and 680x0 versions, because there were cases where emulated 680x0 code needed to call upon a toolbox routine, and the context switch from emulation to native PowerPC and back again was worse than just running the toolbox routine under emulation.
Anyway, bottom line, the PowerPC never had built-in 680x0 emulation. The design win with PowerPC was that it could be made with the same bus that the 680x0 processors used, allowing Apple to retain much of its existing hardware designs. It should be noted that before the PowerPC was decided upon, some folks wanted Apple to go with the Motorola 88000 series of chips -- these were Motorola's first stab at RISC, and had the virtue of being pin-compatible with the 68000 series. I've seen some Omron workstations that used 88000 processors, but I don't think they ever got a lot of traction in the general market. At least one history of the Mac that I've read indicated that the 88000 was seriously considered within Apple before PowerPC was decided upon.
Not all G3-based systems are unsupported in Tiger. I believe G3-based iBooks are still supported, for example. Of course, "supported" doesn't mean you get all the eye candy, but that's true for some lower-end G4 systems as well.
I fully understood the Gibson reference. Thanks for suggesting that I'm too dim to have gotten it. I read Neuromancer and Johnny Mnemonic (the Gibson novella, not the novelization of the atrocious movie by the same name).
To respond to your points:
As for your side note... you do realize that some people (like myself) grew up in a time and place where we learned about "slavery to the company store," etc., from listening to our parents and grandparents, not from a dry history book. Not quite the same as living through it yourself, but it's a hell of a lot more palpable when you talk to someone firsthand who did. Of course, my parents had me late in life, so between that and having access to three prior generations of relatives, I have a pretty different perspective from many of my peers. But I would still venture to say that I'm above the median age for Slashdot, and I doubt most people closer to that age would have the kind of perspective that I do.
The idea of a company providing everything for workers from the cradle to the grave predates William Gibson by about a century. Gibson didn't create anything new in his vision of the future -- he just recycled old ideas from the Industrial Revolution and updated them for a different age.
Seriously, haven't you ever heard the phrase "slave to the company store?" Or am I just showing my age?
Anyway, this sort of thing occurs a lot. Many mining and railroad companies in the United States in the late 19th century had similar practices. To this day, many companies around the world that employ "sweat shop labor," as we in the West now call it, provide similar amenities to their workers, rather than actually paying these people enough that they can better themselves.
I love it! BitTorrent is a file format and not a P2P network! But wait, is it a file format or a protocol? I'm so confused now...
Any slimy company that produces malware and publishes blatantly idiotic statements like the above on its web site deserves some serious smack-down.
Here you go, my friend.
The most direct reference I have is in the middle of an ArsTechnica article. Take a gander at this page. The articles are good reading, though, so to get the full picture, start with part one of the Xbox 360 overview, and then check out part two which focuses more on the CPU.
The 3-core 3.2 GHz part you speak of is not a G5. It is a 64-bit PowerPC core, true, but it lacks things like out-of-order execution. It supports SMT (two threads per core, for a total of 6 threads in hardware simultaneously). However, it's not clear that this particular version of SMT will play nicely with Mach. Regardless, this chip is not designed for general purpose computing. It's fine for the Xbox 360, which it was intended for, but that's it.
The Cell processor is also not a G5. It has a 64-bit PowerPC core with SMT support (for a total of 2 threads), and eight SPE units surrounding that. But those SPE units are not DSPs, although they are "DSP-like." Furthermore, Sony will be disabling one of the eight SPEs in each Cell to improve chip yields. Like the other chip you mention, the Cell is not intended for general purpose computing.
Since neither chip is really suitable for a PowerMac, Apple couldn't use them. It wasn't for "lack of interest." There's been some talk of using the Cell for blades or specific embedded applications, but the vast majority of existing PPC Mac software would run poorly on such chips. I can see the Cell being used in a server farm of blades running a tweaked Linux, for very specific computational tasks (crypto, gene sequencing, etc.), but not for a personal computer. The software would have to be custom tailored to the chip's architecture.
To Apple's credit, they are providing a nice API to take the drudgery out of writing your own vector code; they call it the Accelerate framework, and it's been around since 10.3.
Speaking of differences between AltiVec and SSE/SSE2/SSE3:
I haven't covered all the bulleted items, just the ones that were of interest to me. I also found the following interesting:
So, yeah, there are some of the big glaring differences between SSE/SSE2/SSE3 and AltiVec/VMX. Some of the differences are just that, differences. Others are a pain. I have a feeling more developers are going to rely on Apple's abstraction framework rather than hand-tweaking vectorized code, or else they'll rely on auto-vectorization from the compiler. For pre-existing code, though, it's going to be a bitter pill to swallow; nobody wants to throw out painstakingly hand-optimized vector code.
The installed base is hovering around 16%, and will probably remain roughly the same for the next year or two. The market share is hovering around, what, 2%? I have a feeling it will drop to very nearly 0% within the next year. Why? Because no matter what you buy within the next year from Apple, it's obsolete hardware. That is assuming, of course, that Apple really waits until mid-2006 to ship Intel-based hardware.
OK, I'm exaggerating. Some businesses will scarf up PowerPC Macs, either because they've committed to buying them already, or because they have a need in the near-term that Wintel won't satisfy. But I can't imagine many consumers running out to buy Apple hardware, knowing that anything being sold in the next year that's PowerPC based is already obsolete before it even shipped out the door.
I'm saying this as a diehard Mac supporter and Apple lover. I was in the market for a new laptop in the next 6 months, and I was seriously considering a PowerBook to replace my aging iBook. Now? Screw it, I'll just buy an Athlon 64 based laptop and run Linux on it, the way I'm feeling right now. Why buy a PowerBook knowing that there won't be any appreciable hardware revs in the near future?
I'm sure I'll calm down in another couple days, but I don't think my assessment will change. I do, however, think that it would be dumb of me to put a top-flight (not to mention overpriced) video card in my G5 now, unless my Radeon 9600 takes a crap.
Um, sorry, but no. There's one huge ASIC on every Apple motherboard, and it requires custom drivers which only Apple can supply. This ASIC would be called a "Northbridge" chip on any x86 PC. Apple makes several different system controller chips for different families of Mac. If Apple were to architect their own system controller chip for x86, as they already have done countless times for PowerPC, then they could lock out clones by simply not publishing the drivers for the ASIC in the Darwin source tree, or by refusing to license the ASIC to third party manufacturers.
Ask anyone who has tried to install certain versions of Windows (e.g., Windows 98) on a PC with certain VIA motherboard chipsets, and you begin to appreciate the need for good low-level motherboard chipset drivers.
Since Apple would almost certainly not build an x86 PC with a BIOS, so the one mechanism that PC hardware has to allow bootstrapping an OS on hardware that it might not have prior knowlege of goes out the window. Apple would likely stick with OpenFirmware, which does the same thing that a PC BIOS does, but in a totally different way.
Of course, this all presupposes that Apple is switching to the x86 architecture. I find it far more likely that Apple will license the PowerPC specs to Intel for producing PPC processors; the next most likely scenario is Apple switching to Itanium or some variant thereof. Since IBM missed some important contractual goals, Apple has acquired a lot of intellectual property rights from IBM pertaining to the PowerPC architecture and its manufacture. At any rate, the keynote is tomorrow morning; we'll know by then.
Yeah, you're right... Smitten, in the sense of being "awe-struck" or "marked by foolish or unreasoning fondness." Thus, the grandparent poster to whom you are referring was saying the exact opposite of what he meant. How ... well, I don't know if that qualifies as irony, but it's damned funny. :-)
Not quite true. Prior to Jobs' return to Apple, the Newton was spun off into a subsidiary of Apple, Newton Inc. Jobs' first act was to reabsorb Newton and then kill the project. It's widely known that Jobs was displeased with the Newton, partly because it was a John Sculley initiative.
As a matter of fact, there was a fair bit of interest in the Newton technology for a whole variety of applications. They were, in fact, turning a profit in that division, which is one of the reasons Apple spun Newton off into a subsidiary. Several companies used Newton technology internally for proprietary applications where the device had benefits over the competition (Windows CE / PocketPC and Palm).
Though the Newton lacked color, it was more advanced than all the competition in every meaningful way. They even ported speech synthesis software to the device (which was never officially released, but I managed to get a copy for my MP2000). The object oriented language, NewtonScript, was designed specifically for low-memory-footprint devices; the inheritance model only required storing the "deltas" between the base class and the derived class. It's the only handheld platform I know of where you could write seamless extensions to the built-in applications and have the extensions behave as if they were meant to be there the whole time. No hacks or kludgery or unsupported patches required. The idea of pluggable "stationery" for the default note-taking app was genius!
This is not only a gross over-simplification, it's flat-out wrong. The "in-order processing" done by the PowerPC CPUs in the Xbox 360 and the Cell processor in the PS3 is simply that -- machine instructions are executed in the order that they are presented to the CPU. In other words, these processors don't do instruction reordering. What does this have to do with AI? Absolutely nothing, really. Sure, instruction reordering would probably improve the performance of unoptimized code -- but good compiler tools will do the instruction reordering at compile time and save the transistors on the chip for more useful things.
When I see drivel like this, I tend to tune out the rest of the message, because it's clear the messenger doesn't know what he's talking about.
Having said that, the author of this manifesto probably has a valid point about the patent issues, though. I would have liked some more citations to back up these claims. Just because someone says these things are true doesn't mean they are. Lots of misinformation gets repeated ad nauseum until people believe it's true, when it really isn't. (Remember the old chestnut about video game consoles being sold at a loss? The truth is, few consoles have been sold at a loss. Of the few that started out being sold at a loss, most became profitable as the economics of mass production came into play. I believe the Xbox is the only current-generation console that's still losing money. The last PS2 redesign made Sony's system ultra-cheap to produce.)
Oh, here's another gem from this "manifesto":Ah, yes, load times in PC games are only the result of copy protection! How silly of me to think that it should actually take time for a non-trivial amount of data to be moved from a hard disk into system memory... I mean, seriously, this manifesto was written by someone with near-zero understanding of how hardware actually works, how computers work.
Cripes, I need a toothbrush for my eyeballs...
Not exactly an apples-to-apples comparison, if you'll pardon the pun. The primary supplier of G4 chips is Motorola (now Freescale), not IBM. IBM had been producing G3 chips, and continued to produce them and supply them to Apple while Moto shifted its production focus to the G4. (Apple continued using the G3 in the iBook and eMac lines for quite some time.)
The G5 isn't just a "faster clocked" G4. It's architecturally improved in almost every way. And the bus that the G5 sits on is far more performant than the antiquated bus that the G4 is still saddled with. (Freescale supposedly will be producing dual-core G4 chips with a new and improved bus that will mitigate some of the performance problems with prior G4 bus designs. Those haven't found their way into shipping hardware from Apple. Yet.)
Increasing the clock speed does help. It's just obvious that clock speed isn't everything. The architectural tricks you need to employ to increase the clock speed on the CPU (e.g., deeper pipelines, which increase latency), coupled with the ever-widening gap between CPU speed and DRAM speed (which causes undesirably wait states as the CPU "starves"), mean that continually ramping up clock speed on a single CPU core really is a case of diminishing returns.
We're at the point now where we're running up against thermal problems, yield problems, photolithographic process issues, you name it. And once you realize that doubling a CPU's clock speed (if you're even able to at this stage of the game) won't give you double the real-world performance, where do you turn next for tangible performance benefits? Parallelism is the only other thing we have in our bag of tricks right now.
The way you phrased this implies that you consider this an either-or (i.e., exclusive-or) proposition. Why?
Ah, yes, always good to see a reasoned debate filled with... argument by anecdote! (Argument by anecdote is a path to logical fallacy. Your anecdote does not automatically generalize, and therefore, is a poor foundation for inductive reasoning. Induction requires a hell of a lot more data points than one anecdote. And from a deductive standpoint, your analogy fails miserably to prove anything useful.)
Some philosophers have opined that greater intellect increases the capacity for misery, and judging from the other responses your post has generated, I'd say a lot of people who read Slashdot have bought this idea uncritically. However, even if this idea turns out to be correct, that doesn't mean that high intelligence causes misery.
If higher intelligence truly increases one's capacity for misery, what other emotions might also be enhanced by intellect? It seems to me that many geniuses find joy in things that more mundane people can't even fathom. Carl Sagan (perhaps not a genius, but definitely a smarter-than-average person, and a real scientist to boot) sold me on the romance of science with Cosmos. There were some sad chapters in the history of mankind -- the burning of the Library of Alexandria and the Dark Ages, for example -- but Sagan's message was one of cautious optimism. There was a real sense of Joy pervading his work.
Ultimately, the super-intelligent among us have to choose which emotional response to have to the world around them. Yes, high intelligence gives those people a greater capacity for misery and despair, because they realize just how bad some things are when others steadfastly refuse to even see or acknowledge certain problems/issues. But it also gives them reasons to exult that mundanes might not grasp or appreciate.
Many cravenly PC people were quick to jump on you for conflating "wheelchair-bound" with "mentally retarded," but you did mention "some genetic disorder" -- in the absence of more specific information, it's hard to know whether this is a disorder that affects cognition or not. I'll give you the benefit of the doubt and assume that there was some impact on the girl's intelligence. Maybe she's the stereotypical blissfully ignorant mental defective. Personally, I find such stereotypes offensive, not because they paint an inaccurate picture of the mentally retarded (although I feel they do), but because such stereotypes lead people to uncritically assume that stupidity is a blessing. It's not.
The degenerate case is that humanity devolves into a race of happy, rutting beasts whose population is kept in check by disease and available food. Personally, this seems like an awful waste of our potential. I'd rather see us become smart enough to solve our problems, not stupid enough to not be bothered by them.
And now it would appear that all that work on Cobalt, aka PalmOS 6, was squandered. With this new Linux focus, I wouldn't be surprised if what's left of BeOS/BeIA at PalmSource is jettisoned. *sigh*
I had been fervently hoping, as a former BeOS developer and BeBox owner, that the OS would survive in some form. I had some high hopes in the Palm acquisition of the Be intellectual property. Then I noticed that PalmOne kept using PalmOS 5 instead of releasing devices running PalmOS 6 / Cobalt. So I waited, and waited, and eventually stopped paying attention...
And now we have a Linux initiative, and Be's legacy seems to have truly died. Not that I don't like Linux -- I think Linux is a fabulous server OS, and it even has the potential to be a great desktop OS, but BeOS / BeIA had a lot of promise in the handheld arena. Fully object oriented development environment, lightweight threading and messaging, great speed, and modest resource requirements.
As a final note, just want to say that I'm sad to see that PalmSource sat on the Be IP to the point where it became impossible for people to acquire legitimate copies of BeOS for x86, and since development on that product was halted, it simply stopped working on more modern/recent hardware. I think BeOS on x86 was a fantastic hobbyist OS, and it could have survived in that niche with the right support.
OK, jackass, you just crossed the line into insulting me. First off, I have a Master's Degree in Computer Science. Secondly, I have been a professional software engineer for well over a decade now. You, on the other hand, are coming across as an amateur, and probably one with a specific axe to grind.
I tried to be as polite as possible, to counter your "arguments" with facts and observations based on years of experience in the field. But you choose to believe your little fantasies. Fine.
Here's a postcard from reality: I've worked on projects where the scientific number crunching that you claim would never be present in a server app, was in fact present in a server app. Here's another postcard from reality: In a real production environment, you're lucky if you get a chance to profile your code once or twice to identify the top two or three areas with the most CPU utilization (or the biggest I/O bottlenecks, whatever). This is typically not done as part of automated testing, as it is time consuming, and automated testing is usually intended to handle QA issues and to insure that bugs stay fixed (i.e., regression testing).
You make a lot of unsubstantiated claims that further bolster my previous assertion that you're simply ignorant and talking out of your ass. For instance, you claim that the Java class libraries are "mostly shit," but that's a pretty broad blanket statement that actually flies in the face of years of experience to the contrary. Essentially unlimited time to optimize in static compilation? That's great, assuming that the optimizer is (a) guaranteed to generate equivalent code and not break your logic, and (b) actually has runtime knowledge of your code in order to make more effective optimizations. Neither of these is automatically true. The former is often not true -- even commercial compilers such as those offered by Microsoft can generate broken code in optimization, necessitating disabling the optimizer. The latter case is almost always untrue for C and C++ (and similar languages). Even if your compiler is designed to take profiling data as input, all that does is provide hints to the optimizer on where it should spend its time being the most aggressive. There are only so many tricks you can bring to bear in compile-time optimization.
Again, you're arguing in abstractions. I challenge you to put up or shut up, and by that, I mean show me definitive empirical tests. You don't like the paper I cited because it has lots of scientific computation? Fine. Pick your own test case. But you can't deny that there are always going to be some cases where I'm right, and Java will come out on top -- not because it's a better language, not because virtual machines are just that good, but simply because you can always come up with a few cases where Java simply will perform better.
Of course, I don't care about "performs better." I only care about "performs about as well as." And that's certainly the case almost 100% of the time, except for some very low-level bit banging type applications (e.g., video transcoding, audio processing, etc.)
But there's really no point in abusing this thread any further, since it's obvious that no matter what I say, you're going to insist that I'm wrong, even though I never claimed that Java was always faster than C/C++, or even most of the time; I only ever claimed that Java was roughly equally performant to natively compiled languages like C/C++, and that it could outperform such languages in certain cases. I proved my point by citing a research paper.
Your claim is that C/C++ is always more performant, and I proved that your claim is wrong because it is absolute. Your only response was to dismiss the research paper I cited because, to paraphrase you, "nobody does lots of scientific computation in the real world." That's also an
This is starting to get WAY off topic. However, I should point out that your point number 1 is attributable to many things, none of which are directly VM related. Poor programming is indeed to blame in some cases. You speak of "Java desktop apps," but realistically, this must be broken down into three sub-cases: AWT, Swing, and SWT, the three main GUI toolkits available to Java programmers these days. SWT has performance problems on every platform besides Windows, because SWT has only been optimized under MS Windows. AWT is no longer promoted, and seldom used, mainly because it looks clunky and doesn't provide much flexibility. Swing widgets are supposed to be 100% Pure Java, although Swing has been optimized on some platforms (notably OS X optimizes Swing drawing operations using Quartz 2D or similar, depending on version). Obviously, having GUI widgets that are written in an interpreted/JIT-compiled language is not a recipe for performance, especially for applications with rapid visual updates. But then again, a well-designed Swing app will intelligently handle redraw, something I've noticed is hard for some programmers to cope with. After all, when you can live in a Windows world and rely on hardware-acceleration to conceal the fact that your application redraws the same thing a dozen times, your programming techniques will fall flat in Swing. (I've been around long enough to see examples of GUI code in Java written by people who cut their teeth in Windows and X11, and almost invariably, profiling the code revealed cases where redraw was happening far more than it should have.)
Of course, this "desktop apps" argument is kind of a straw man argument, because these days, almost 100% of commercial Java development is on the server side, in J2EE environments like Websphere and WebLogic. Major corporations use J2EE (and JSP/Servlet engines like Tomcat) because this stuff works. It's easy to develop for, the performance is very good when using the Server VM (as opposed to the client VM, which is optimized for processes that don't run 24/7), and the toolset is very rich, which makes productivity very high.
Let's put it this way: Java wouldn't survive if it weren't performant in the server space. So obviously, for some applications, it's superior to the alternatives.
Your point number 2 is another straw man argument in disguise. The fact is that there is a lot of crap C/C++ code out there, and much of it is in libraries that are leveraged by user-written C/C++ applications. However, even ignoring this fact, you can empirically demonstrate with experiment (not so-called "intuition," which often gives incorrect answers -- ask any real scientist) that for some algorithms, a direct implementation in Java may in fact outperform a similar implementation in C/C++. The paper I cited in fact does this type of comparison -- it is an "apples to apples" comparison, implementing the same algorithms in each language and comparing the results.
Nice job on the straw man arguments, though. It's very easy to misrepresent someone else's argument and then tear it down, because you're not really addressing the other person at all; it only looks like you are.
Now, let's talk about your intuition. Most modern JVMs use what is called JIT (or Just-In-Time) compilation of the Java bytecodes. A VM that is tuned to run long-term, such as the server JVM that Sun ships, will cache the JIT-compiled bytecode for immediate retrieval and execution. As another poster pointed out, there are optimizations that can be performed at runtime by inspecting the running code's behavior; these optimizations can and do outperform compile-time optimizations, where the optimizer can only make assumptions about the run-time profile of the running code. Basically, in any case where a static compile-time optimization fails on the C/C++ side, a code implementation on the Java side will be more performant. So there's the counter-argument to your "intuition." Not that this is likely to conv
This "JVMs are ass-slow" argument gets repeated a lot. There have been multiple benchmarks published demonstrating definitively that this is not the case -- in fact, Java can outperform C and C++ in many applications. Here is one reference for you to ponder. Of course, it's easier for most people to parrot hearsay rather than actually rely on empirical evidence to support their opinions.
Note that I'm not saying JVMs are inherently superior for all, or even most, applications. I'm just saying that things are a little more complicated than your one-line zinger would imply. I'm also saying that virtual machines can be very performant, with the right code-translation and caching strategies. (See my other post in another branch of this thread.)
In fact, I worked for Informative Graphics when there was a project underway to get a native port of their Myriad software working under NT on the DEC Alpha processor. The native port worked, but it was substantially slower than the FX!32 emulator running the x86 version, at least after running the x86 version of the app under emulation a few times. (Like the grandparent poster speculated, the emulation cached the results of opcode translation for future reuse. Eventually, almost 100% of the original application was translated and stored in a disk cache.)
Then again, the Myriad code was pretty horribly written, and optimized to only compile well under Microsoft's Visual Studio environment. I was stuck on a horrid project porting the code to HPUX and Solaris using MainWin (which basically was a Win32 implementation on top of X11 / POSIX, a porting library for lazy companies that didn't want to invest time and effort in writing truly portable code or rewriting their UI code). Granted, HP's C++ compiler sucked -- it was AT&T Cfront based, and had to be told how to instantiate templates because it had dain-bramaged template support -- but even when we got this stuff working, it wasn't very performant.
Which brings me to another thought -- if Apple switches to x86 or Itanium, we might be in for similar performance surprises. Some code will obviously benefit from a native recompile, but other code might be more performant with a caching code translation mechanism.
Actually, that's pretty funny, because the specs I read on several web sites specifically mention that the PS3 supports DualDisc. See here, or here, or use Google yourself...
So, ah, it appears that the Blu-Ray drive on the PS3 is apparently engineered to handle thicker discs. Funny enough, the two DualDiscs that I own seem to play fine in the slot-loading head unit in my car. (Granted, it's one of the newest Alpine units, so maybe they engineered it with better tolerances.) I've not seen any slot-loading drives lately that bear any of the warnings you speak of.
Personally, I'd rather have Blu-Ray because it doesn't require a third layer (read as: kludge) the way HD-DVD does to get its capacity. As far as the codecs go, you may well be right that the two competing standards may both support the same codecs, but I'm sure there are some other details (e.g., file system) that further distinguish the two. So I doubt the issue is purely one of capacity.