Since/. is likely interested in a few more details:
There is no fundamental hardware difference between "gaming cards" (GeForce, Radeon) and "professional cards" (Quadro, FireGL/FirePro). Historically the pro cards had more memory, but even that is now not universal.
The difference is, and almost always has been, in the drivers. Gaming drivers prioritize "get the frame rendered on time", while pro drivers prioritize "get the frame rendered perfectly".
The best way to demonstrate this is this: how does each draw a line? The gaming drivers use an algorithm that is crazy-fast, using all-integer math. It gives ugly results, which are normally cleaned up either by anti-aliasing, or (more recently) by running every frame through a selective blur filter. The pro drivers use a slightly different algorithm that gives near-perfect results, but is much slower because it uses all-floating-point math.
That's hardly the only difference, but it's the most easily explained. The pro drivers do all kinds of things to make the results as accurate as possible, while the gaming drivers do all kinds of things to render as quickly as possible.
Another difference, at least for Windows, is OpenGL. Most games tend to use Direct3D, so that code path is much better tested and optimized than OpenGL on the gaming drivers. But OpenGL is *the* API used by pro-grade programs, so that's much more functional in the pro drivers.
Back in the day, it was possible to make the drivers for either work on either - you could run the pro drivers on your gaming card and get a cheap professional card (although this was when the extra 128MB of VRAM would have justified at least half the price increase), or you could even run the gaming drivers on a pro card and get the fastest system around.
Nowadays there's too much stuff restricting you from doing that. Which is kind of sad, actually, because every so often on gaming forums you'll find a guy with more $$ than IQ who bought "the most expensive card on the market" and is wondering why he's getting only 15FPS in Battlefield when a card costing a tenth as much runs ten times as fast. At least if the drivers were unlocked we could tell them to use the GeForce drivers instead of the Quadro drivers...
I, for instance, am an ordained minister in Norse Paganism (Reformed), a registered card-carrying Communist, a decorated veteran of the Third Punic War, the true heir to the throne of Emperor Norton I, and the true assassin of Archduke Ferdinand (you'd be surprised the kind of questions telemarketers ask!).
I also brought the sexy back, but nobody's asked that yet, unfortunately.
Previously, I have done as the GGP described. Lost the plugin and converter in a reformat (curse you, Windows!), and you know what? It was less of a hassle to just use a website to convert it on those rare occasions that I actually *did* want to download a Youtube video as an MP3, than it would have been to reinstall and configure the special software to do it. I don't do it that often, so I don't need the sort of instant capabilities of a browser plugin.
Modern GPUs are essentially thousands of very simple, low-speed cores. Think of a thousand 486s. They use driver software to make it do the graphics calculations, because that means they can be more flexible. There are no fixed-function pipelines anymore - it's all software, either in the drivers, or in the customizable shaders.
Intel's plan was to make a GPU that has a few dozen (32 or so) more complex cores, that were x86 compatible. They added some specialized extra-wide SIMD stuff and some fast-blitting texture units, but it was still x86 compatible. And they had some very impressive drivers to make it function as a "graphics card" - they even demonstrated real-time raytracing in 2009, something nVidia only demonstrated their cards doing this year (and Intel did it in an actual game, not a tech demo).
However, that flexibility made it a bit underwhelming at the things most games actually do, so it really couldn't compete in that marketplace, at least not at the prices they expected to need to be profitable. But that highly-flexible but also highly-parallel architecture seems perfectly suited to supercomputing.
You commit several severe logical errors during this (to say nothing of your grammar). Let's look at it in depth.
Your first fallacy is assuming all cores are equal. Notably, that PowerPC A2 is running at half, maybe even a third, the clock speed of the i7. That gives it much better efficiency, yes - but it also gives much higher latency. In a supercomputer processor, that's no problem - throughput is the only important factor. But for a desktop? Latency matters.
Had you read more, you would also know that one of those 18 cores is reserved for the OS and interrupt handling, and does not contribute to actual programs. Another core is disabled for yield purposes - they expect one core to be defective, and plan for it.
You're also comparing unlike processors. The A2 targets efficiency and parallel throughput - it does not need to deal with "what if the program being run is only single-threaded, and we can't throw cores at it?". Meanwhile, the i7 has to consider what a "regular user's" workload is, and how it can best accommodate it. With tricks like turbo boost, or even the various sleep modes - the i7 only draws that much power under full load; under light use, it draws far less; the A2 does not have to worry about sleep-mode power draw or low-load power consumption, as it's intended to run at full-throttle at all times.
May I also ask which specific i7 you were referencing? 22nm implies it's an Ivy Bridge series, but none that have yet been released are 8-core processors, nor do any of those use 135W. Some of the slightly-older Sandy Bridge-E series have specs more similar to what you specified (8 cores, but only 130W), but those are built at 32nm and are not exactly "latest", although they remain "greatest".
At least for desktop processors, and there is your next error. The i7 is a desktop/workstation processor. Costs about $300 for a low-end one, and maybe $1000 for a top-of-the-line my-dick-is-bigger-than-yours overcompensator. I cannot find pricing on the A2, but I would easily bet that it's closer to $3000 than $300. It's a server chip - if you wanted a fair comparison, you would have compared it to a Xeon E7. Which, as an aside, seems due for a refresh - the newest E7 was released over a year ago, and was based on the truly-outdated Westmere architecture.
You go on to argue *against* yourself. If 18,000 Intel processors gets you 2.9 petaflops, that comes out to about 6200 processors/petaflop. The AMD system runs at an absurd 132,000 processors/petaflop, and the IBM 4,300 processors/petaflop. To me, that looks more like "Intel and IBM are neck-and-neck" than "IBM is far and away the best". Especially as we've not seen Intel's response, although a newer story on Slashdot is about Intel's MIC project - fifty cores per processor, and power consumption in kilowatts, not megawatts.
You then make the grave error of comparing products that have not even been announced yet (we've no guarantee an Xbox 720 or a Playstation 4 will even *exist*, much less use PowerPC chips).
Oh, and now you go beyond comparing server chips to desktop chips. Now you're treating game console chips as server chips as well. Which, granted, is true for the PS3's Cell (it *must* have been some non-technical marketing droid who decided on that, because that was one of the dumbest technical moves they could have made). But the Wii? A deliberately-pathetic, low-power chip chosen mostly for backwards compatibility.
Let's also look at the *other* consoles. The ones you *didn't* reference. The PS2? A heavily-modded MIPS. The Dreamcast? A Super-H. The original Xbox? Why, our old friend Mr. Intel x86! And yet those were in the heyday of the PowerPC, when it seemed a genuine competitor on the desktop and server front.
Oh, and one more thing: the Mac. Apple quite famously switched *away* from PowerPC. And say what you will, but Apple is not an idiot. They could see that, at the time, IBM was going nowhere with it. Too much power usage for laptops and smaller desktops, and not enough computational po
Larrabee, essentially, was never released. It was demonstrated, and a few were even given/lent to researchers for testing, but it was never used in an actual product.
That's why it's *still* known only by its codename. You don't need a real name until you're actually planning to put it on shelves.
That's why it's "news". It's transitioning from a *fascinating* research project to a real, commercial product.
Yeah, I guess I did sort of misrepresent that. I was a bit rushed at the end there, boss was looking over my shoulder.
For an analogy/. would understand, think of a game engine as Webkit, except in full 3D, rendering millions of elements every frame (and if you EVER dip below 30FPS there will be hell to pay). Oh, and half the elements have to think for themselves, and you have to run on everything more powerful than a wristwatch, and you have to have an integrated IDE that handles large-scale level geometry, high-detail models, textures (diffuse, normal, and specular maps, for starters), and code.
And you'll need to rewrite it from scratch every 4-8 years because the new consoles came out.
For another analogy/. would enjoy, think of a game engine as being sort of like a car engine...
Input. Input is the big one, because, as far as I can tell, EVERY operating system does it differently. Sure, for stuff like a web browser or text editor, you might be able to rely on relatively common stuff, but for low-latency and especially for gamepad/joystick input, there's really no good way.
Linux has SDL. Which is a bit crap, actually, so you don't use it for big-name games unless you have no better option.
Windows has DirectInput, which I believe is also used on the X360.
OS X is apparently a mess of small libraries; I wouldn't know myself, as I've had a royal bitch of a time just trying to get an IDE working on OS X.
Andoid has it's own system. iOS has it's own system. Every console has it's own, incompatible, system.
Oh, and if you're thinking the consoles give you a POSIX interface, I'd like to know what you're smoking and who your dealer is, because that must be some great stuff.
One last thing: OpenGL may *run* on Windows, but it doesn't run *well*. You generally get a 10% performance decrease just because the drivers are much worse at OpenGL than they are at Direct3D (mainly because far more games use the latter than the former (mainly because the drivers are much worse at OpenGL than they are at Direct3D (mainly because far more games use the latter than the former (ERROR: INFINITE RECURSION DETECTED)))).
It's not the kernel, it's the libraries. That's really all a game engine does - it takes all the libraries and presents a simple interface to them, while integrating the asset tools (ie. model file formats, etc.)
On Windows, almost everything you need is in DirectX. Same for the XBox - it's pretty much the same library. Graphics, audio, networking, input, it's all there except a basic AI library and physics simulation.
On OS X, there's a bunch of less integrated APIs. OpenGL for the graphics, some proprietary library for input, and so on. iOS uses mostly the same libraries.
Android also uses OpenGL, but has it's own, different libraries for pretty much everything else. The same is true for the non-Microsoft consoles - either OpenGL or the OpenGL ES, and custom proprietary crap for everything else.
Linux, again, uses OpenGL. But that's about it as far as "common code". Want to tell if Mouse3 has been pressed? Need new code. Want to play a sound? New code.
Now, it's not quite as bad as it seems - most of the engine is, in fact, the "turn basic libraries into something that does all the work for you", and the renderer *is* the biggest library bit, but it's still quite a bit of work to go from Android to Linux.
Re:How much effort is needed by the developer now?
on
Unity 4 Adds Linux Support
·
· Score: 3, Insightful
Depends. I've never used Unity, but I have used UnrealEngine, Source and idTech, and I've done some light reading on it before.
The most common scenario will probably be "needs some shaders re-written to work with Linux's outdated drivers", assuming, of course, that they'd already written GL shaders (and not just D3D). Best-case, all they need to do is check the "Export for Linux" box right next to the "Export for Android" and "Export for XBLA" boxes.
However, it should be *possible* to make a Unity game that requires a ton of work to port. Either because you actively tried, or because you didn't use the engine to it's full potential and instead re-implemented half the functionality in system-specific ways. Think of Android - you *can* write native apps that don't run on non-ARM (or even only specific ARM) processors, but that's not exactly common.
Of course, engine support historically hasn't translated into game support. UnrealEngine 2 supported Linux (think 3 does as well), as did several idTechs (even before being open-sourced), and yet we only rarely see games using those released for Linux. Although it may be a matter of how *good* the Linux support is - many of those may have required far more work than more modern engines.
RISC and CISC are no longer really meaningful distinctions. The new POWER systems have a lot of non-RISCy SIMD extensions and such, as do the SPARCs used in the K supercomputer. Likewise, the modern CISC processors (read: x86) have become more RISC-like, at least internally.
I actually think the modern x86 way is a really good compromise (although the x86 implementation of the idea ranges from terrible to tolerable). Internally, use a simple, efficient RISC-like micro-op processor, while presenting a CISC-like interface to the rest of the system. You get most of the advantages of both (the speed of RISC, the instruction density of CISC) as well as some unique ones (as long as you keep the CISC layer the same, you can change the internals all you want while keeping full software compatibility). The only significant downside is a small loss of die space for the translator (usually only a few percent of the die (half of which is usually a massive L3 cache anyways)).
Now if only that CISC layer wasn't the mess known as x86-64...
I did the math a while ago - a 20-year-old supercomputer is about as powerful as a modern 1U server, or maybe a really high-end workstation (at least going by Dhrystone benchmarks). But still using the supercomputer-sized room and supercomputer-sized power consumption.
I can't be assed to do the precise research, but I would estimate that a 10-year-old supercomputer would be about as powerful as a small cluster. But, again, a small cluster that sucks down several megawatts and takes up a small building. There's not really much you can do with it that you can't do better with a smaller number of modern computers. Eventually the cost of building a new, same-performance but lower-power system is less than your annual power budget.
The new MBP screen may have a physical resolution of 2880x1800, but the OS presents this to applications as the same old 1440x900 and automatically pixel-doubles them, unless they specifically flag themselves as "Retina-Capable" (and those that do normally just render at twice the size, so you get sharper text and lines, but no change in size). So you basically get a really sharp 1440x900 display - you don't get any extra screen space from it, which is the main reason we *want* high-res screens.
If you set it to give you the most space, you can set it to 1900x1200 (or something like that) and get a decent amount of screen space, but not a revolutionary amount.
Just a little interesting thing I noticed while reading up on this.
Most American media refers to it as an "American" supercomputer first and foremost, and an "IBM" supercomputer second. Most non-American media refers to it as an "IBM" supercomputer first, and an "American" supercomputer second.
Not really wrong either way - it's a big win for both the US and for IBM - but it's interesting to see the little differences.
I'd actually heard of it. Mostly from people bitching about how a) very little junk on there is actually funny, and b) they seem to slap big watermarks on anything uploaded. I'm not surprised that their management/legal counsel are morons - their main userbase consists of people who find outdated, misused memes and "lol so random!" "humor" to be funny.
It does a lot, but the Constitution does not protect *every* right (like the Right to Privacy - not in there). It's a man-made document - it will never be perfect. That's why it can be amended. At one point it allowed slavery, a rather gross violation of "fundamental human rights".
The point isn't to keep the "terrorists" from getting access to Ebola. Hell, that might be a good thing - given how many suicide bombers manage to kill no-one but themselves, I'd laugh to think how badly they'd handle biological safety. They'd probably just kill themselves.
No, the point is to keep the diseases from escaping back into the wild. As it turns out, Ebola is not native to the United States. Neither is Lassa, or Marburg, or Q, or any of the other BSL-4 diseases. Hell, smallpox is now native to nowhere. The point of these measures is to keep it that way.
Bubonic plague really isn't weaponizeable - it's transmitted by *fleas*, and curable with modern antibiotics. West Nile also wouldn't work well as a weapon - almost all infections are asymptomatic. You could have it right now and not know. Of those who do develop symptoms, most suffer only a pretty bad flu - it's only in the 1% of cases where it enters the brain that it's really dangerous.
The anthrax letters? They were sent by an anthrax researcher who feared his job was about to be lost.
Ebola, Lassa and Dengue, at least in their natural forms, make for poor bioweapons as well. They simply cannot transmit well enough - one of the most common causes of Ebola infection is *eating* an infected carcass. The best bioweapons are air-transmittable or aerosol-transmittable. Now, there's a definite risk that a weapons researcher could breed a more transmittable hemorrhagic fever, but the wild cases? You'd *maybe* get a few infections, cause a massive media panic, but you'd see a death toll in the single digits, not in the millions.
Methinks you have been reading too many Clancy novels.
Actually, they answer that in the article. He claims that, even if Intel chips *are* more expensive, a) the price of the processor is pretty much negligible compared to the price of the full unit (particularly the screen), and b) the performance advantage is worth the cost.
And he kind of has a point. The Raspberry Pi has been described as "a smartphone minus the screen". It's $25-$35. A smartphone is in the range of $300-$600. Order of magnitude difference, and that's not because of the processor.
Ebola research, at least in the US and Europe, can *only* be performed at Biosafety Level 4 labs - literally the highest there is.
The labs are fully isolated. Any air or water going in or out will be subjected to enough UV light to kill any virus, followed by extreme heat and powerful chemicals. The lab areas are kept at a lower atmospheric pressure, so if there *is* a leak, air flows in, not out.
Humans going in require multiple chemical showers, going through several airlocks including a vacuum chamber, and wearing a full positive-pressure suit with an *isolated* air supply, not filtered. And even then, all work is done inside Class II or III biosafety cabinets (the boxes with gloves in them).
There are less than fifty active BSL-4 labs in the entire planet, and only fifteen in the United States. These are specifically designed for the worst of the worst - Smallpox, Ebola, Lassa, and the like.
In the United States, BSL-4 labs that contain potential biological weapons, such as the smallpox lab, are guarded by the US Army. I believe Ebola is one of those diseases.
Trust me. They know how to keep diseases contained.
That's sort of how Valve games work. Their anti-cheat system is called VAC, pretty sure it stands for Valve Anti-Cheat or something dull like that, but I can't be assed to check.
If you are detected as a cheater and banned, you can no longer play on VAC-enabled servers. But, server admins are able to disable VAC. It's not common, probably because they get overrun with cheaters (wouldn't know myself - I've never played on one). And any cheating performed on a non-VAC server "doesn't count" - since the anti-cheat isn't running, you can't be banned.
Valve also has a no-excuse policy on ban appeals. The only times, to my knowledge, that they overturn a ban is when for false positives, which are generally pretty rare.
And yeah, now that I think about it, it could be fun for a bit. Some of the best fun I had in TF2 was when the players ignored the rules of the game. Doing something where, for instance, *everyone* has wallhacks, might be fun.
Slashdot Mirror
Since /. is likely interested in a few more details:
There is no fundamental hardware difference between "gaming cards" (GeForce, Radeon) and "professional cards" (Quadro, FireGL/FirePro). Historically the pro cards had more memory, but even that is now not universal.
The difference is, and almost always has been, in the drivers. Gaming drivers prioritize "get the frame rendered on time", while pro drivers prioritize "get the frame rendered perfectly".
The best way to demonstrate this is this: how does each draw a line? The gaming drivers use an algorithm that is crazy-fast, using all-integer math. It gives ugly results, which are normally cleaned up either by anti-aliasing, or (more recently) by running every frame through a selective blur filter. The pro drivers use a slightly different algorithm that gives near-perfect results, but is much slower because it uses all-floating-point math.
That's hardly the only difference, but it's the most easily explained. The pro drivers do all kinds of things to make the results as accurate as possible, while the gaming drivers do all kinds of things to render as quickly as possible.
Another difference, at least for Windows, is OpenGL. Most games tend to use Direct3D, so that code path is much better tested and optimized than OpenGL on the gaming drivers. But OpenGL is *the* API used by pro-grade programs, so that's much more functional in the pro drivers.
Back in the day, it was possible to make the drivers for either work on either - you could run the pro drivers on your gaming card and get a cheap professional card (although this was when the extra 128MB of VRAM would have justified at least half the price increase), or you could even run the gaming drivers on a pro card and get the fastest system around.
Nowadays there's too much stuff restricting you from doing that. Which is kind of sad, actually, because every so often on gaming forums you'll find a guy with more $$ than IQ who bought "the most expensive card on the market" and is wondering why he's getting only 15FPS in Battlefield when a card costing a tenth as much runs ten times as fast. At least if the drivers were unlocked we could tell them to use the GeForce drivers instead of the Quadro drivers...
go big.. be an outlier.
Indeed!
I, for instance, am an ordained minister in Norse Paganism (Reformed), a registered card-carrying Communist, a decorated veteran of the Third Punic War, the true heir to the throne of Emperor Norton I, and the true assassin of Archduke Ferdinand (you'd be surprised the kind of questions telemarketers ask!).
I also brought the sexy back, but nobody's asked that yet, unfortunately.
Indeed.
Previously, I have done as the GGP described. Lost the plugin and converter in a reformat (curse you, Windows!), and you know what? It was less of a hassle to just use a website to convert it on those rare occasions that I actually *did* want to download a Youtube video as an MP3, than it would have been to reinstall and configure the special software to do it. I don't do it that often, so I don't need the sort of instant capabilities of a browser plugin.
It was, sort of.
Modern GPUs are essentially thousands of very simple, low-speed cores. Think of a thousand 486s. They use driver software to make it do the graphics calculations, because that means they can be more flexible. There are no fixed-function pipelines anymore - it's all software, either in the drivers, or in the customizable shaders.
Intel's plan was to make a GPU that has a few dozen (32 or so) more complex cores, that were x86 compatible. They added some specialized extra-wide SIMD stuff and some fast-blitting texture units, but it was still x86 compatible. And they had some very impressive drivers to make it function as a "graphics card" - they even demonstrated real-time raytracing in 2009, something nVidia only demonstrated their cards doing this year (and Intel did it in an actual game, not a tech demo).
However, that flexibility made it a bit underwhelming at the things most games actually do, so it really couldn't compete in that marketplace, at least not at the prices they expected to need to be profitable. But that highly-flexible but also highly-parallel architecture seems perfectly suited to supercomputing.
You commit several severe logical errors during this (to say nothing of your grammar). Let's look at it in depth.
Your first fallacy is assuming all cores are equal. Notably, that PowerPC A2 is running at half, maybe even a third, the clock speed of the i7. That gives it much better efficiency, yes - but it also gives much higher latency. In a supercomputer processor, that's no problem - throughput is the only important factor. But for a desktop? Latency matters.
Had you read more, you would also know that one of those 18 cores is reserved for the OS and interrupt handling, and does not contribute to actual programs. Another core is disabled for yield purposes - they expect one core to be defective, and plan for it.
You're also comparing unlike processors. The A2 targets efficiency and parallel throughput - it does not need to deal with "what if the program being run is only single-threaded, and we can't throw cores at it?". Meanwhile, the i7 has to consider what a "regular user's" workload is, and how it can best accommodate it. With tricks like turbo boost, or even the various sleep modes - the i7 only draws that much power under full load; under light use, it draws far less; the A2 does not have to worry about sleep-mode power draw or low-load power consumption, as it's intended to run at full-throttle at all times.
May I also ask which specific i7 you were referencing? 22nm implies it's an Ivy Bridge series, but none that have yet been released are 8-core processors, nor do any of those use 135W. Some of the slightly-older Sandy Bridge-E series have specs more similar to what you specified (8 cores, but only 130W), but those are built at 32nm and are not exactly "latest", although they remain "greatest".
At least for desktop processors, and there is your next error. The i7 is a desktop/workstation processor. Costs about $300 for a low-end one, and maybe $1000 for a top-of-the-line my-dick-is-bigger-than-yours overcompensator. I cannot find pricing on the A2, but I would easily bet that it's closer to $3000 than $300. It's a server chip - if you wanted a fair comparison, you would have compared it to a Xeon E7. Which, as an aside, seems due for a refresh - the newest E7 was released over a year ago, and was based on the truly-outdated Westmere architecture.
You go on to argue *against* yourself. If 18,000 Intel processors gets you 2.9 petaflops, that comes out to about 6200 processors/petaflop. The AMD system runs at an absurd 132,000 processors/petaflop, and the IBM 4,300 processors/petaflop. To me, that looks more like "Intel and IBM are neck-and-neck" than "IBM is far and away the best". Especially as we've not seen Intel's response, although a newer story on Slashdot is about Intel's MIC project - fifty cores per processor, and power consumption in kilowatts, not megawatts.
You then make the grave error of comparing products that have not even been announced yet (we've no guarantee an Xbox 720 or a Playstation 4 will even *exist*, much less use PowerPC chips).
Oh, and now you go beyond comparing server chips to desktop chips. Now you're treating game console chips as server chips as well. Which, granted, is true for the PS3's Cell (it *must* have been some non-technical marketing droid who decided on that, because that was one of the dumbest technical moves they could have made). But the Wii? A deliberately-pathetic, low-power chip chosen mostly for backwards compatibility.
Let's also look at the *other* consoles. The ones you *didn't* reference. The PS2? A heavily-modded MIPS. The Dreamcast? A Super-H. The original Xbox? Why, our old friend Mr. Intel x86! And yet those were in the heyday of the PowerPC, when it seemed a genuine competitor on the desktop and server front.
Oh, and one more thing: the Mac. Apple quite famously switched *away* from PowerPC. And say what you will, but Apple is not an idiot. They could see that, at the time, IBM was going nowhere with it. Too much power usage for laptops and smaller desktops, and not enough computational po
It's more of "they're actually RELEASING it".
Larrabee, essentially, was never released. It was demonstrated, and a few were even given/lent to researchers for testing, but it was never used in an actual product.
That's why it's *still* known only by its codename. You don't need a real name until you're actually planning to put it on shelves.
That's why it's "news". It's transitioning from a *fascinating* research project to a real, commercial product.
Yeah, I guess I did sort of misrepresent that. I was a bit rushed at the end there, boss was looking over my shoulder.
For an analogy /. would understand, think of a game engine as Webkit, except in full 3D, rendering millions of elements every frame (and if you EVER dip below 30FPS there will be hell to pay). Oh, and half the elements have to think for themselves, and you have to run on everything more powerful than a wristwatch, and you have to have an integrated IDE that handles large-scale level geometry, high-detail models, textures (diffuse, normal, and specular maps, for starters), and code.
And you'll need to rewrite it from scratch every 4-8 years because the new consoles came out.
For another analogy /. would enjoy, think of a game engine as being sort of like a car engine...
Input. Input is the big one, because, as far as I can tell, EVERY operating system does it differently. Sure, for stuff like a web browser or text editor, you might be able to rely on relatively common stuff, but for low-latency and especially for gamepad/joystick input, there's really no good way.
Linux has SDL. Which is a bit crap, actually, so you don't use it for big-name games unless you have no better option.
Windows has DirectInput, which I believe is also used on the X360.
OS X is apparently a mess of small libraries; I wouldn't know myself, as I've had a royal bitch of a time just trying to get an IDE working on OS X.
Andoid has it's own system. iOS has it's own system. Every console has it's own, incompatible, system.
Oh, and if you're thinking the consoles give you a POSIX interface, I'd like to know what you're smoking and who your dealer is, because that must be some great stuff.
One last thing: OpenGL may *run* on Windows, but it doesn't run *well*. You generally get a 10% performance decrease just because the drivers are much worse at OpenGL than they are at Direct3D (mainly because far more games use the latter than the former (mainly because the drivers are much worse at OpenGL than they are at Direct3D (mainly because far more games use the latter than the former (ERROR: INFINITE RECURSION DETECTED)))).
Look, zombie or not, if Teddy Roosevelt wants your phone, HE WILL GET IT.
It's not the kernel, it's the libraries. That's really all a game engine does - it takes all the libraries and presents a simple interface to them, while integrating the asset tools (ie. model file formats, etc.)
On Windows, almost everything you need is in DirectX. Same for the XBox - it's pretty much the same library. Graphics, audio, networking, input, it's all there except a basic AI library and physics simulation.
On OS X, there's a bunch of less integrated APIs. OpenGL for the graphics, some proprietary library for input, and so on. iOS uses mostly the same libraries.
Android also uses OpenGL, but has it's own, different libraries for pretty much everything else. The same is true for the non-Microsoft consoles - either OpenGL or the OpenGL ES, and custom proprietary crap for everything else.
Linux, again, uses OpenGL. But that's about it as far as "common code". Want to tell if Mouse3 has been pressed? Need new code. Want to play a sound? New code.
Now, it's not quite as bad as it seems - most of the engine is, in fact, the "turn basic libraries into something that does all the work for you", and the renderer *is* the biggest library bit, but it's still quite a bit of work to go from Android to Linux.
Depends. I've never used Unity, but I have used UnrealEngine, Source and idTech, and I've done some light reading on it before.
The most common scenario will probably be "needs some shaders re-written to work with Linux's outdated drivers", assuming, of course, that they'd already written GL shaders (and not just D3D). Best-case, all they need to do is check the "Export for Linux" box right next to the "Export for Android" and "Export for XBLA" boxes.
However, it should be *possible* to make a Unity game that requires a ton of work to port. Either because you actively tried, or because you didn't use the engine to it's full potential and instead re-implemented half the functionality in system-specific ways. Think of Android - you *can* write native apps that don't run on non-ARM (or even only specific ARM) processors, but that's not exactly common.
Of course, engine support historically hasn't translated into game support. UnrealEngine 2 supported Linux (think 3 does as well), as did several idTechs (even before being open-sourced), and yet we only rarely see games using those released for Linux. Although it may be a matter of how *good* the Linux support is - many of those may have required far more work than more modern engines.
RISC and CISC are no longer really meaningful distinctions. The new POWER systems have a lot of non-RISCy SIMD extensions and such, as do the SPARCs used in the K supercomputer. Likewise, the modern CISC processors (read: x86) have become more RISC-like, at least internally.
I actually think the modern x86 way is a really good compromise (although the x86 implementation of the idea ranges from terrible to tolerable). Internally, use a simple, efficient RISC-like micro-op processor, while presenting a CISC-like interface to the rest of the system. You get most of the advantages of both (the speed of RISC, the instruction density of CISC) as well as some unique ones (as long as you keep the CISC layer the same, you can change the internals all you want while keeping full software compatibility). The only significant downside is a small loss of die space for the translator (usually only a few percent of the die (half of which is usually a massive L3 cache anyways)).
Now if only that CISC layer wasn't the mess known as x86-64...
I did the math a while ago - a 20-year-old supercomputer is about as powerful as a modern 1U server, or maybe a really high-end workstation (at least going by Dhrystone benchmarks). But still using the supercomputer-sized room and supercomputer-sized power consumption.
I can't be assed to do the precise research, but I would estimate that a 10-year-old supercomputer would be about as powerful as a small cluster. But, again, a small cluster that sucks down several megawatts and takes up a small building. There's not really much you can do with it that you can't do better with a smaller number of modern computers. Eventually the cost of building a new, same-performance but lower-power system is less than your annual power budget.
Just a point of fact:
The new MBP screen may have a physical resolution of 2880x1800, but the OS presents this to applications as the same old 1440x900 and automatically pixel-doubles them, unless they specifically flag themselves as "Retina-Capable" (and those that do normally just render at twice the size, so you get sharper text and lines, but no change in size). So you basically get a really sharp 1440x900 display - you don't get any extra screen space from it, which is the main reason we *want* high-res screens.
If you set it to give you the most space, you can set it to 1900x1200 (or something like that) and get a decent amount of screen space, but not a revolutionary amount.
Well, this one is intended for simulating nuclear weaponry. Basically testing nukes in a way that doesn't involve nuking ourselves.
Just a little interesting thing I noticed while reading up on this.
Most American media refers to it as an "American" supercomputer first and foremost, and an "IBM" supercomputer second.
Most non-American media refers to it as an "IBM" supercomputer first, and an "American" supercomputer second.
Not really wrong either way - it's a big win for both the US and for IBM - but it's interesting to see the little differences.
A few hundred miles inland is a hell of a commute.
I'd actually heard of it. Mostly from people bitching about how a) very little junk on there is actually funny, and b) they seem to slap big watermarks on anything uploaded. I'm not surprised that their management/legal counsel are morons - their main userbase consists of people who find outdated, misused memes and "lol so random!" "humor" to be funny.
It does a lot, but the Constitution does not protect *every* right (like the Right to Privacy - not in there). It's a man-made document - it will never be perfect. That's why it can be amended. At one point it allowed slavery, a rather gross violation of "fundamental human rights".
Ignore printers.
Most printers ought to die in a fire anyways. Now he might actually get to see it happen!
You're missing the point.
The point isn't to keep the "terrorists" from getting access to Ebola. Hell, that might be a good thing - given how many suicide bombers manage to kill no-one but themselves, I'd laugh to think how badly they'd handle biological safety. They'd probably just kill themselves.
No, the point is to keep the diseases from escaping back into the wild. As it turns out, Ebola is not native to the United States. Neither is Lassa, or Marburg, or Q, or any of the other BSL-4 diseases. Hell, smallpox is now native to nowhere. The point of these measures is to keep it that way.
Bubonic plague really isn't weaponizeable - it's transmitted by *fleas*, and curable with modern antibiotics. West Nile also wouldn't work well as a weapon - almost all infections are asymptomatic. You could have it right now and not know. Of those who do develop symptoms, most suffer only a pretty bad flu - it's only in the 1% of cases where it enters the brain that it's really dangerous.
The anthrax letters? They were sent by an anthrax researcher who feared his job was about to be lost.
Ebola, Lassa and Dengue, at least in their natural forms, make for poor bioweapons as well. They simply cannot transmit well enough - one of the most common causes of Ebola infection is *eating* an infected carcass. The best bioweapons are air-transmittable or aerosol-transmittable. Now, there's a definite risk that a weapons researcher could breed a more transmittable hemorrhagic fever, but the wild cases? You'd *maybe* get a few infections, cause a massive media panic, but you'd see a death toll in the single digits, not in the millions.
Methinks you have been reading too many Clancy novels.
Actually, they answer that in the article. He claims that, even if Intel chips *are* more expensive, a) the price of the processor is pretty much negligible compared to the price of the full unit (particularly the screen), and b) the performance advantage is worth the cost.
And he kind of has a point. The Raspberry Pi has been described as "a smartphone minus the screen". It's $25-$35. A smartphone is in the range of $300-$600. Order of magnitude difference, and that's not because of the processor.
Ebola research, at least in the US and Europe, can *only* be performed at Biosafety Level 4 labs - literally the highest there is.
The labs are fully isolated. Any air or water going in or out will be subjected to enough UV light to kill any virus, followed by extreme heat and powerful chemicals. The lab areas are kept at a lower atmospheric pressure, so if there *is* a leak, air flows in, not out.
Humans going in require multiple chemical showers, going through several airlocks including a vacuum chamber, and wearing a full positive-pressure suit with an *isolated* air supply, not filtered. And even then, all work is done inside Class II or III biosafety cabinets (the boxes with gloves in them).
There are less than fifty active BSL-4 labs in the entire planet, and only fifteen in the United States. These are specifically designed for the worst of the worst - Smallpox, Ebola, Lassa, and the like.
In the United States, BSL-4 labs that contain potential biological weapons, such as the smallpox lab, are guarded by the US Army. I believe Ebola is one of those diseases.
Trust me. They know how to keep diseases contained.
That's sort of how Valve games work. Their anti-cheat system is called VAC, pretty sure it stands for Valve Anti-Cheat or something dull like that, but I can't be assed to check.
If you are detected as a cheater and banned, you can no longer play on VAC-enabled servers. But, server admins are able to disable VAC. It's not common, probably because they get overrun with cheaters (wouldn't know myself - I've never played on one). And any cheating performed on a non-VAC server "doesn't count" - since the anti-cheat isn't running, you can't be banned.
Valve also has a no-excuse policy on ban appeals. The only times, to my knowledge, that they overturn a ban is when for false positives, which are generally pretty rare.
And yeah, now that I think about it, it could be fun for a bit. Some of the best fun I had in TF2 was when the players ignored the rules of the game. Doing something where, for instance, *everyone* has wallhacks, might be fun.