Don't forget the bloat in applications as well. Is OpenOffice 2.0 named that because of the relative size of the tarball compared to 1.2 or because of the relative startup time for the application compared to 1.2?;) The average Linux disto has used a lot more than the average Windows with equivalent software (Office suite and development suite) for some time for me. Heck, my Windows box with those plus WoW is smaller than this Linux box with just the distribution stuff.
Not really. I don't live in a large city and buses aren't economically feasible here. There are buses that run certain routes (mostly downtown) and there are none that run a route that has pickups anywhere near where I live or work. I would drive a car farther each day to get to a pickup and have to take a cab or something from a dropoff to work than just driving directly from home to work and back. Using the bus would cost me more in time, money, and resources (gas) than driving my own car.
The fact is that buses are only economically feasible where the population density is such that a bus will have a certain number of passengers all the time it is running its routes, which happen to be over sufficiently short distances. This pretty much occurs only in large cities, especially in the USA. New York, Chicago, Los Angeles, San Francisco, Miami, and the like. Elsewhere, we're just too spread out for them to be efficient. Europe/UK has a population density and distances between cities that work very well for trains and buses. Many large cities in Asia also are ideal for public transportation. Much of Japan is great for it, too. Most of the USA is not suited for it, unfortunately.
Well, you could read it and realize that it was a very well reasoned article heavy on original thought and not just the usual link-fest.
Give me a break...
From TFA:
A lot of these are marked as security updates, but almost all of the software they apply to has no place in an e-commerce configuration. With Windows servers you install everything you're licensed to because the dependencies are largely unknown, with Linux you install what you need -because what isn't there doesn't have vulnerabiliites, use resources, or require patching.
What would there be to patch on the disk of a certain package wasn't installed? I'm sure the patchers are smart enough to look at what you have installed and compare that to the list of available patches. So, in either case, you should only see a list of available patches with respect to your machine.
The second problem is something the author doesn't mention at all: "management" has clearly told these administrators to apply the patches directly to the "production" systems. In real life many people do this with Windows, but you don't do this with Linux.
I've never worked anywhere that used Windows that did this. It's a common practice in both the Windows and *nix worlds.
The problem with this is that the requirement that component upgrades run on both Windows and Linux looks like it's intended to level the playing field but has the opposite effect - taking the best open source applications out of consideration because these might run on Windows but not with ASP and SQL-Server, and limiting the number of vendors on the Windows side to one.... But that's not what they did: instead the Windows people were asked to load pre-integrated modules while the Linux administrators faced integration and interfacing problems on unrelated code bundles.
Call the waaaambulance. These are pretty typical production environments for both platforms. The fact that Linux gets components from multiple "vendors" is exactly the reason why many people like Linux and pretty much the only way there is to do things on Linux so it's also how it's done in the real world. In other words, YOU go find a Linux vendor (oops, there is only one... Linus Torvalds) who also provides a web server and web scripting modules as "pre-integrated modules" (woops, you can't).
I stopped reading at this point because it was obvious that the blog was just another crybaby post by some religious nut. I've been using Linux for well over a decade and we use it here at work as our primary development platform. That blog wasn't worth reading as long as I did.
Well... aside from marketing reasons and the like, Beta periods are longer these days because the software is typically more complex as well. You'd like a good beta audience to test your code breadth-wise and depth-wise, which may be difficult given some products (think about Microsoft Office and all the features and combinations of features you'd want tested).
Plus, there's always getting your product out in Beta form to let some air out of competitors' offerings. If you can get your game out in a pretty good beta, for instance, you might curb some of the fever for some other competing game has. Just look at the EQ2 and WoW Beta and release times, they were fighting who would release first to get a lot of initial sales.
Arguing that OSS is "better" without mentioning Microsoft could prove difficult indeed. "Better" is a word that takes two arguments-- the thing that is better, and the thing the first thing is better than. X is better than Y. If no argument is given for Y directly, we find one based on context. In a discussion wherein OSS is said to be "better", the logical inference is that it's being compared with its competition-- specifically, Microsoft.
Good point. I guess I should be more specific and say that objective comparison is reasonable. A guide that says "Microsoft Word has this feature and this is the corresponding feature in OSS Application Y. In addition, OSS Application Y can do this, which either isn't available or is very hard to use in Microsoft Word." would be appropriate. Just leave the "Microsoft is evil" junk out of it. For me, anyway, I already have my own opinions of Microsoft and do not care to read someone else's. Yes, I know Microsoft was declared a monopoly and all that but I've already weighed its importance to whether or not I can get my job done and how long it takes to do so.
I'll stand beside my original statement though. Leave the bashing out. Give me an objective argument as to why I should be using one application over the other. If the largest leg it has to stand on is "it's not Microsoft" then you're wasting my time.
I believe in free enterprise. I would like to think that you do too but I think you just believe in MS$ all mighty dollar and power at any cost.
Funny. I bet I spend more time daily using Linux than you do.... considering I get paid to develop on Linux as our only target platform and I use Linux at home and have been since the 0.9x kernel days. The only difference between our two posts seems to be that I've simply not made a religion out of it.
I agree completely. Writing a book that is full of crap like that just turns more people OFF. If you have a solid argument that OSS is better, you can make your argument without ever mentioning Microsoft. If you can't make your argument without mentioning Microsoft, then you are just a religious nut. Prove to me that OSS is better. Do not try to argue with me that Microsoft is evil therefore I must use OSS to save my soul.
Yeah, that's a good model if your app and is coarse grained and the entry points can be treated as remote procedure calls. Not all parallel computing can fall into that model. More fine grained applications may need communication among multiple programs, each performing partial computations of the whole on partial pieces of the whole dataset. While the upper layer may call Transform(), the lower level code (which also has to be debugged) may have lots of communication between multiple programs running on multiple processors (a program running on four SPUs, for example). It's not exactly like calling RPCs and getting an "answer", it's about sending/receiving partials, data partitioning, and parallel algorithms at those levels.
I guess when I read the above posts, the parts I think about debugging are exactly the parts the other posters are skipping over by saying "the PPC code has a nice beautiful interface to call prepackaged libraries written and well debugged by someone else". I'm talking about being that someone else who has to write those nice prepackaged libraries that will be called from the PPC. Even worse is a fine grained problem that has to incorporate multiple SPUs AND the PPC core in order to do the calculations. Those are the type problems that the Cell programmers face and are some of the problems that made the MAP1310 very difficult to program.
I think the Cell will certainly make one type of software popular among games and that's shared engine code, which will fit the model described in the top few posts. Much like various PC games use the Halflife or Doom engines (so they don't have to write an engine which is both time consuming and "difficult"), making their game not much more than a mod, I think the PS3 will increasingly make this a requirement as writing the various engines (physics, sound, visualization, etc.) on the Cells is not something that most game houses will have the time/skill to do. Unfortunately, to me at least, this means even more cookie-cutter games with even less innovation.... Oh look, this brand new game is just Game123 with different textures [joy].
Have you *ever* written/debugged a multi-threaded program? Debugging a multithreaded program on three homogenous processors is a ton easier than debugging (essentially) a multithreaded program on a heterogenous set of processors (1 of one type and up to 8 of another type) that have to be accessed by DMA engines and the like. It's basically debugging multiple programs because of the different instruction streams but with the added complexity of the same address space sharing issues of multi-threaded applications. They will effectively be different programs (must be since the PPC and the SPUs are not the same ISA) but all sharing the same address space, complicated by the fact that a lot of the interaction must be handled by DMA engines. This isn't much different from debugging embedded systems that have been around for decades (one such system I used was a board with an embedded PPC with eight DSPs all on the same board called the MAP1310 from CSPI - look it up on google). It was difficult to program and is basically the Cell in 3 chips instead of just 1.
Also, you say "are used by low level liberaries (well debugged)" and quickly polish over any idea that maybe those "well debugged low level libraries" will be a nightmare to debug. If any of those low level libraries are threads of execution in their own right, as opposed to simply being "load this subroutine into a SPU, call it just like another routine only use basically a RPC, then unload that subroutine from the SPU" then they will be a bit harder to debug. I image that at least some of those SPU "low level libraries" will most likely be programs that run independently of the PPC core and routinely synchronize with the PPC thread(s) and if the amount of interaction between them is much (which it may well be), then it will be far harder to debug than your typical Linux box running multiple threads (on homogenous processor(s)).
At least you said "a sense of humor" and didn't assume that they had "a good sense of humor".
You can watch David Letterman's show for the first five minutes and get the entire show. The rest of the show is just endlessly repeating some phrase that the audience laughed at once in that first five minutes.
I was thinking the same thing. Since the whole premise of quantum security is to be able to tell if someone had looked at the data sometime between when it was sent and when you got it, it seems like this new breakthrough has just invalidated an entire school of thought in quantum computing.
And that means that those universities are going to have rewrite their custom apps at great expense.
Doubtful... many (I would almost say "most") HPC apps are written in MPI and there are a number of MPI implementations on Windows. I've personally used one and the "rewrite" consisted of building a project in MSVC and compiling. I think it took about five minutes. For those not afraid of Windows, it isn't a difficult task.
Unfortunately, RedHat is one of my least favorite distributions. The fact that RedHat gave them a bunch of money is why they are using it, I'm sure. It would have been nice to have some other distribution on it. I guess an owner could always format and reinstall whatever distribution he/she prefers on it.
As far as the argument of having source code or not, I think it's a non-issue. 95% of computer users don't care about source code. They just care that the computer does what they want (plays games, mostly, and surfs the web, and lets them do email). For the other 5% (actually much less now, probably 0.1%) who *are* coders, very few of them will care about looking at the code either. For the people who will support these machines (provide updates and the like - basically RedHat), they care that they have the source because, in effect, it *is* their OS just like Windows *is* Microsoft's OS for when fixes need to be done. Sure, the OSS community will supply some fixes for RedHat but RedHat still has to examine each one and make sure it's right for their distribution.
Yeah, the one largest area I've heard that likes the tablets is medical. You can walk around with them and bring up charts and save the charts/notes after a visit easily.
As far as PDAs, I've actually worked with a group using ruggedized Newtons to download maintenance orders overnight and be available for the workers at shift start. The workers carry them around and use them all shift, making notes and such on the work orders, then after the shift is over, the work orders are downloaded and the databases updated. The next step was waiting on WiFi to be everywhere so they could send the work orders during the shift instead of downloading/uploading workflows.
I haven't looked at the actual timings, but the vast majority of memory operations are on cache lines. So, you have to use some math to determine how fast a cache line is filled using each technology to see what the difference is. It isn't all about the time to get the first byte in, it's about getting the cache line in (which is 256 bits - 2x128-bit reads on our favorite x86 machines). DDR will still be a little faster, I'm guessing, but the initial read latency is amortized over the two reads in a dual-channel memory configuration.
Besides, I think Sun is saying that they will be using faster than DDR2-533 memory *and* the system is more tollerant of latency issues than the AMD and Intel parts that we are more familiar with. Of course, I'm taking their word with a grain of salt because even four threads on a single core can easily all be stalled given that at 2GHz, a single cache load may be the equivalent of over 200 instructions. So, it's quite imaginable that all four contexts can be stalled for main memory accses simultaneously given the rather small caches it has. Also, IIRC, even the L1 caches have a 3-cycle penalty which seems to me like that alone will guarantee many short stalls (like every instruction/bundle fetch).
Compounded by the fact that many "by hand" implementations of reference counting is defective. I've seen many broken hand-tooled reference counting schemes.
It would still result in massive CPU usage, compounded with potentially lots of MOESI traffic on the caches. These are some of the reasons why it isn't used anymore. If it were the end-all, be-all as you claim then why wouldn't this be used everywhere? I mean, it's not like the algorithm hasn't been around since 1965 (as you also stated).
Basically, the reason is this: Polling, especially in a single CPU environment, is a BadThing(tm) if you want your machine to handle load well. If you have no load and have nothing else useful for your CPUs to be doing, then polling is about as good as anything else. Considering that all modern OSs are pre-emptive and are doing lots of things during any given second, few would meet that criteria.
Great post (no mod points to give you, unfortunately). However, the "modern breed" of application programmer doesn't know why/how/when transactions are a good thing (and thus, doesn't use them and will actively post about how they aren't needed) so, most likely, your great post will be ignored by them.
Eh, not really - first off, I could have implemented oracle on a two-way server instead of a four-way and gotten equiv performance (search engine queries). Secondly, I could probably have gotten the oracle licenses down to $20k a cpu.
Sadly, on identical x86 boxes (dual processor, 1G RAM, Windows 2000, etc), we were never able to get Oracle to even come close to SQLServer's performance and we spent a bit of time/money trying. Of course, the SQLServer was just set up as the default configuration out of the box so we didn't do anything at all to tweak it. I spent about a month optimizing an operation (many nasty SQL statements) on Oracle and couldn't ever get it close to SQLServer in performance either, when we had spent little time really tweaking the SQLServer version of the operation (SQLServer ran the operation in about 40m, the analog operation on Oracle after optimizing it went from DNF to about 1h40m on the same data - yeah, the original Oracle operation was bad. When I first tested it on the data, I let it run for over 29h before giving up and just killing it, after optimizing it, it was about 1h40m).
We did find out lots of fun stuff about Oracle though. My favorite was that if you declared an index on (col1, col2) but issued a query as "where (col2 = X) and (col1 = Y)", it would ignore the index (the optimizer was stupid, even though the coder should have been more careful coding the SQL statement) where, in the same scenario, SQLServer would recognize that an appropriate index was there, just reversed, and use it.
So in this respect, Microsoft does play an important role in the creation of commodity computing. But they did not create the market. And they certainly didn't create the market with Windows.
I agree with this statement. I don't think they created it either, but I do think they helped it along a lot.
And thanks for a good reply, it was a good read. It seems that you and I are "of an age". I, too, got my first computer before there was such a thing as an IBM PC.
It was there, somewhat, but not to what we know today.
Take graphics cards, for example, I thought about this some last night. Before there was a "standard" API, they spent time on performance, price, their own API, and wooing developers (games and applications such as AutoCAD) to use their API. When Microsoft said "use our API and we'll handle the developers", that freed up the graphics companies to concentrate on performance and price (freeing up the companies from the kickbacks and such allowed prices to drop even more). Microsoft handled getting the developers (games and other applications) onto Windows.
"Commodity computing came about during the time of DOS - far, far before Windows." Simply stating this over and over without definition does not make it true. Did you ever buy a DOS machine? I did... several, and they were not really commodity. Sure, they were mass produced but they were not cheap (which is the other side of the 'commodity' coin). The prices of the machines back there were roughly what they cost now. You could get a decent machine for $1200 or so (today, I'd say you could get a decent machine for $600 though), however, the economics of the time were that the $1200 of the machine was a lot more money relative to other costs (and paychecks) than today. If you don't believe me on the price, go look at advertisements from that time period (late 80s early 90s). I bought a machine that was "workstation" quality in/around 1994 for nearly $5000, which was a lot of money at the time (still is, but it was relatively more then). It wasn't the highest end CPU at the time even (only a Pentium-60, yes, with the bug, but the 90s were out) but it had 32M memory and the largest HDD available at the time (540M). Since 8M was the norm for the time, it'd be like getting a 4G machine today with a 300G HDD. What kind of machine can you put together for $5k today? What's the difference between having $5k in 1994 and having $5k today?
Providing a unifying platform (both hardware and software) that was on the vast majority of PCs allowed hardware vendors to benefit from economies of scale just like software.
Yes, PCs were starting to benefit from economies of scale (becoming commodity) during DOS (which... was MSDOS, btw, which was made by Microsoft as was Windows 3.1 and 95 and on) days but the full extent of commoditization hadn't been realized at the time. It took a unifying software architecture as well to complete the picture. So, Microsoft probably did help PCs to become commodities even, as DOS was Microsoft's thing.
GL did exist and was partially supported by Glide, for example, in the early '90s. OpenGL was ratified in 1992 but took a while for adoption. Not even all the Un*x vendors adopted OpenGL quickly. The amount of support vendors offered even differed (both on Un*x machines and PC video cards). It was hardly a "standard" on the PC side of the coin and never really was *the* standard. A number of cards delivered OpenGL libraries for their cards and OpenGL came close to being *the* standard with the Voodoo cards but DirectX came out and for various reasons, DirectX pretty much won. On the PCs, you had lots of choices... CGA, EGA, VGA, VESA (hopefully only if that was your only option), and others, in addition to a few cards like the Voodoo Glide cards that supported only a subset of OpenGL and some other cards that supported their own proprietary APIs. Also, Microsoft/Windows was defining graphics cards standards during the Windows 3.1 timeframe, which was quite a bit of time before Windows 95 and a bit of time before PCs were really commodity items.
The history of the PC and how it became a commodity is entertwined with Windows since Windows was delivered with PCs the whole time. Which caused which? I guess I'd have to think about it more.
Yes. I can write a blog and put whatever I want in it. A professional journalist knows that if he/she repeatedly publishes lies or inaccuracies, they'll be finding other ways of earning a paycheck (thus, providing food for their bellies and a bed to sleep in).
As always, it's the difference between just spouting stuff because you want to and basing your life/livelihood on something. In one, you have no risk. In the other, you most definitely have risk and a vested interest in being a professional.
Yeah, they're so afraid of the Internet that growth has been doubling every year since around the Windows'95 release timeframe. They are paranoid about being on the 'net and think it's normal to run anti-whatever ware as a basic acceptance (whether right or wrong) that computers are not infallible. In some ways, computers have evolved from being "magic" and "universally fantastic" to being "just another device" that has its share of problems and issues just as any other product. I think this has been good, overall, for the world. Holding something as being "magic" by the general populace leads to some bad things (worship, etc.).
Positive contribution my Microsoft: commoditized and standardized the personal computer products. An example of standardization is graphics cards (before Microsoft imposing standards, every card was different, etc.) Have you ever set up Glide? or had a game that ran against VESA (crappy) or Glide (proprietary but good)? The reason why graphics cards are like they are today is because of Microsoft. Derived from this is games on the PC. Software developers don't want to have to build against and test against several grahpics APIs. A standard graphics API has made making software (games) much easier to write to target a large market (all Windows PCs as opposed to PCs with Brand X or Y video cards). Commoditization of PCs can be seen in the fact that so many households around the world have PCs now.
Do not underestimate what benefits having (practically) a single platform to code against has had on the software industry. Being able to write one piece of software and have it runnable by 90%+ of the world's machines is a very strong benefit.
Not only this but Linux itself has benefitted. Not only did Microsoft give all those folks someone to hate (someone to motivate them) but the standardization and commoditization of PCs has directly enabled Linux to be successful. PCs are cheaper as well as have a number of features that Intel and Microsoft developed together.
His software is one of the temptations that we need to avoid if we're to obtain a fully free-software world.
Assuming that is your goal. I, for one, do not have that as a goal. I'm happy with having both open and closed source and see no reason why I should *desire* to eliminate one or the other type of software. In fact, the idea is somewhat hypocritical.... "I want people to be free to develop software, but only under the type of license that I like."
Slashdot Mirror
Don't forget the bloat in applications as well. Is OpenOffice 2.0 named that because of the relative size of the tarball compared to 1.2 or because of the relative startup time for the application compared to 1.2? ;) The average Linux disto has used a lot more than the average Windows with equivalent software (Office suite and development suite) for some time for me. Heck, my Windows box with those plus WoW is smaller than this Linux box with just the distribution stuff.
Not really. I don't live in a large city and buses aren't economically feasible here. There are buses that run certain routes (mostly downtown) and there are none that run a route that has pickups anywhere near where I live or work. I would drive a car farther each day to get to a pickup and have to take a cab or something from a dropoff to work than just driving directly from home to work and back. Using the bus would cost me more in time, money, and resources (gas) than driving my own car.
The fact is that buses are only economically feasible where the population density is such that a bus will have a certain number of passengers all the time it is running its routes, which happen to be over sufficiently short distances. This pretty much occurs only in large cities, especially in the USA. New York, Chicago, Los Angeles, San Francisco, Miami, and the like. Elsewhere, we're just too spread out for them to be efficient. Europe/UK has a population density and distances between cities that work very well for trains and buses. Many large cities in Asia also are ideal for public transportation. Much of Japan is great for it, too. Most of the USA is not suited for it, unfortunately.
Well, you could read it and realize that it was a very well reasoned article heavy on original thought and not just the usual link-fest.
...
Give me a break...
From TFA:
A lot of these are marked as security updates, but almost all of the software they apply to has no place in an e-commerce configuration. With Windows servers you install everything you're licensed to because the dependencies are largely unknown, with Linux you install what you need -because what isn't there doesn't have vulnerabiliites, use resources, or require patching.
What would there be to patch on the disk of a certain package wasn't installed? I'm sure the patchers are smart enough to look at what you have installed and compare that to the list of available patches. So, in either case, you should only see a list of available patches with respect to your machine.
The second problem is something the author doesn't mention at all: "management" has clearly told these administrators to apply the patches directly to the "production" systems. In real life many people do this with Windows, but you don't do this with Linux.
I've never worked anywhere that used Windows that did this. It's a common practice in both the Windows and *nix worlds.
The problem with this is that the requirement that component upgrades run on both Windows and Linux looks like it's intended to level the playing field but has the opposite effect - taking the best open source applications out of consideration because these might run on Windows but not with ASP and SQL-Server, and limiting the number of vendors on the Windows side to one.
But that's not what they did: instead the Windows people were asked to load pre-integrated modules while the Linux administrators faced integration and interfacing problems on unrelated code bundles.
Call the waaaambulance. These are pretty typical production environments for both platforms. The fact that Linux gets components from multiple "vendors" is exactly the reason why many people like Linux and pretty much the only way there is to do things on Linux so it's also how it's done in the real world. In other words, YOU go find a Linux vendor (oops, there is only one... Linus Torvalds) who also provides a web server and web scripting modules as "pre-integrated modules" (woops, you can't).
I stopped reading at this point because it was obvious that the blog was just another crybaby post by some religious nut. I've been using Linux for well over a decade and we use it here at work as our primary development platform. That blog wasn't worth reading as long as I did.
Well... aside from marketing reasons and the like, Beta periods are longer these days because the software is typically more complex as well. You'd like a good beta audience to test your code breadth-wise and depth-wise, which may be difficult given some products (think about Microsoft Office and all the features and combinations of features you'd want tested).
Plus, there's always getting your product out in Beta form to let some air out of competitors' offerings. If you can get your game out in a pretty good beta, for instance, you might curb some of the fever for some other competing game has. Just look at the EQ2 and WoW Beta and release times, they were fighting who would release first to get a lot of initial sales.
Arguing that OSS is "better" without mentioning Microsoft could prove difficult indeed. "Better" is a word that takes two arguments-- the thing that is better, and the thing the first thing is better than. X is better than Y. If no argument is given for Y directly, we find one based on context. In a discussion wherein OSS is said to be "better", the logical inference is that it's being compared with its competition-- specifically, Microsoft.
Good point. I guess I should be more specific and say that objective comparison is reasonable. A guide that says "Microsoft Word has this feature and this is the corresponding feature in OSS Application Y. In addition, OSS Application Y can do this, which either isn't available or is very hard to use in Microsoft Word." would be appropriate. Just leave the "Microsoft is evil" junk out of it. For me, anyway, I already have my own opinions of Microsoft and do not care to read someone else's. Yes, I know Microsoft was declared a monopoly and all that but I've already weighed its importance to whether or not I can get my job done and how long it takes to do so.
I'll stand beside my original statement though. Leave the bashing out. Give me an objective argument as to why I should be using one application over the other. If the largest leg it has to stand on is "it's not Microsoft" then you're wasting my time.
I believe in free enterprise. I would like to think that you do too but I think you just believe in MS$ all mighty dollar and power at any cost.
Funny. I bet I spend more time daily using Linux than you do.... considering I get paid to develop on Linux as our only target platform and I use Linux at home and have been since the 0.9x kernel days. The only difference between our two posts seems to be that I've simply not made a religion out of it.
I agree completely. Writing a book that is full of crap like that just turns more people OFF. If you have a solid argument that OSS is better, you can make your argument without ever mentioning Microsoft. If you can't make your argument without mentioning Microsoft, then you are just a religious nut. Prove to me that OSS is better. Do not try to argue with me that Microsoft is evil therefore I must use OSS to save my soul.
Yeah, that's a good model if your app and is coarse grained and the entry points can be treated as remote procedure calls. Not all parallel computing can fall into that model. More fine grained applications may need communication among multiple programs, each performing partial computations of the whole on partial pieces of the whole dataset. While the upper layer may call Transform(), the lower level code (which also has to be debugged) may have lots of communication between multiple programs running on multiple processors (a program running on four SPUs, for example). It's not exactly like calling RPCs and getting an "answer", it's about sending/receiving partials, data partitioning, and parallel algorithms at those levels.
I guess when I read the above posts, the parts I think about debugging are exactly the parts the other posters are skipping over by saying "the PPC code has a nice beautiful interface to call prepackaged libraries written and well debugged by someone else". I'm talking about being that someone else who has to write those nice prepackaged libraries that will be called from the PPC. Even worse is a fine grained problem that has to incorporate multiple SPUs AND the PPC core in order to do the calculations. Those are the type problems that the Cell programmers face and are some of the problems that made the MAP1310 very difficult to program.
I think the Cell will certainly make one type of software popular among games and that's shared engine code, which will fit the model described in the top few posts. Much like various PC games use the Halflife or Doom engines (so they don't have to write an engine which is both time consuming and "difficult"), making their game not much more than a mod, I think the PS3 will increasingly make this a requirement as writing the various engines (physics, sound, visualization, etc.) on the Cells is not something that most game houses will have the time/skill to do. Unfortunately, to me at least, this means even more cookie-cutter games with even less innovation.... Oh look, this brand new game is just Game123 with different textures [joy].
Have you *ever* written/debugged a multi-threaded program? Debugging a multithreaded program on three homogenous processors is a ton easier than debugging (essentially) a multithreaded program on a heterogenous set of processors (1 of one type and up to 8 of another type) that have to be accessed by DMA engines and the like. It's basically debugging multiple programs because of the different instruction streams but with the added complexity of the same address space sharing issues of multi-threaded applications. They will effectively be different programs (must be since the PPC and the SPUs are not the same ISA) but all sharing the same address space, complicated by the fact that a lot of the interaction must be handled by DMA engines. This isn't much different from debugging embedded systems that have been around for decades (one such system I used was a board with an embedded PPC with eight DSPs all on the same board called the MAP1310 from CSPI - look it up on google). It was difficult to program and is basically the Cell in 3 chips instead of just 1.
Also, you say "are used by low level liberaries (well debugged)" and quickly polish over any idea that maybe those "well debugged low level libraries" will be a nightmare to debug. If any of those low level libraries are threads of execution in their own right, as opposed to simply being "load this subroutine into a SPU, call it just like another routine only use basically a RPC, then unload that subroutine from the SPU" then they will be a bit harder to debug. I image that at least some of those SPU "low level libraries" will most likely be programs that run independently of the PPC core and routinely synchronize with the PPC thread(s) and if the amount of interaction between them is much (which it may well be), then it will be far harder to debug than your typical Linux box running multiple threads (on homogenous processor(s)).
At least you said "a sense of humor" and didn't assume that they had "a good sense of humor".
You can watch David Letterman's show for the first five minutes and get the entire show. The rest of the show is just endlessly repeating some phrase that the audience laughed at once in that first five minutes.
I was thinking the same thing. Since the whole premise of quantum security is to be able to tell if someone had looked at the data sometime between when it was sent and when you got it, it seems like this new breakthrough has just invalidated an entire school of thought in quantum computing.
And that means that those universities are going to have rewrite their custom apps at great expense.
Doubtful... many (I would almost say "most") HPC apps are written in MPI and there are a number of MPI implementations on Windows. I've personally used one and the "rewrite" consisted of building a project in MSVC and compiling. I think it took about five minutes. For those not afraid of Windows, it isn't a difficult task.
Unfortunately, RedHat is one of my least favorite distributions. The fact that RedHat gave them a bunch of money is why they are using it, I'm sure. It would have been nice to have some other distribution on it. I guess an owner could always format and reinstall whatever distribution he/she prefers on it.
As far as the argument of having source code or not, I think it's a non-issue. 95% of computer users don't care about source code. They just care that the computer does what they want (plays games, mostly, and surfs the web, and lets them do email). For the other 5% (actually much less now, probably 0.1%) who *are* coders, very few of them will care about looking at the code either. For the people who will support these machines (provide updates and the like - basically RedHat), they care that they have the source because, in effect, it *is* their OS just like Windows *is* Microsoft's OS for when fixes need to be done. Sure, the OSS community will supply some fixes for RedHat but RedHat still has to examine each one and make sure it's right for their distribution.
Yeah, the one largest area I've heard that likes the tablets is medical. You can walk around with them and bring up charts and save the charts/notes after a visit easily.
As far as PDAs, I've actually worked with a group using ruggedized Newtons to download maintenance orders overnight and be available for the workers at shift start. The workers carry them around and use them all shift, making notes and such on the work orders, then after the shift is over, the work orders are downloaded and the databases updated. The next step was waiting on WiFi to be everywhere so they could send the work orders during the shift instead of downloading/uploading workflows.
I haven't looked at the actual timings, but the vast majority of memory operations are on cache lines. So, you have to use some math to determine how fast a cache line is filled using each technology to see what the difference is. It isn't all about the time to get the first byte in, it's about getting the cache line in (which is 256 bits - 2x128-bit reads on our favorite x86 machines). DDR will still be a little faster, I'm guessing, but the initial read latency is amortized over the two reads in a dual-channel memory configuration.
Besides, I think Sun is saying that they will be using faster than DDR2-533 memory *and* the system is more tollerant of latency issues than the AMD and Intel parts that we are more familiar with. Of course, I'm taking their word with a grain of salt because even four threads on a single core can easily all be stalled given that at 2GHz, a single cache load may be the equivalent of over 200 instructions. So, it's quite imaginable that all four contexts can be stalled for main memory accses simultaneously given the rather small caches it has. Also, IIRC, even the L1 caches have a 3-cycle penalty which seems to me like that alone will guarantee many short stalls (like every instruction/bundle fetch).
Compounded by the fact that many "by hand" implementations of reference counting is defective. I've seen many broken hand-tooled reference counting schemes.
It would still result in massive CPU usage, compounded with potentially lots of MOESI traffic on the caches. These are some of the reasons why it isn't used anymore. If it were the end-all, be-all as you claim then why wouldn't this be used everywhere? I mean, it's not like the algorithm hasn't been around since 1965 (as you also stated).
Basically, the reason is this: Polling, especially in a single CPU environment, is a BadThing(tm) if you want your machine to handle load well. If you have no load and have nothing else useful for your CPUs to be doing, then polling is about as good as anything else. Considering that all modern OSs are pre-emptive and are doing lots of things during any given second, few would meet that criteria.
Great post (no mod points to give you, unfortunately). However, the "modern breed" of application programmer doesn't know why/how/when transactions are a good thing (and thus, doesn't use them and will actively post about how they aren't needed) so, most likely, your great post will be ignored by them.
Eh, not really - first off, I could have implemented oracle on a two-way server instead of a four-way and gotten equiv performance (search engine queries). Secondly, I could probably have gotten the oracle licenses down to $20k a cpu.
Sadly, on identical x86 boxes (dual processor, 1G RAM, Windows 2000, etc), we were never able to get Oracle to even come close to SQLServer's performance and we spent a bit of time/money trying. Of course, the SQLServer was just set up as the default configuration out of the box so we didn't do anything at all to tweak it. I spent about a month optimizing an operation (many nasty SQL statements) on Oracle and couldn't ever get it close to SQLServer in performance either, when we had spent little time really tweaking the SQLServer version of the operation (SQLServer ran the operation in about 40m, the analog operation on Oracle after optimizing it went from DNF to about 1h40m on the same data - yeah, the original Oracle operation was bad. When I first tested it on the data, I let it run for over 29h before giving up and just killing it, after optimizing it, it was about 1h40m).
We did find out lots of fun stuff about Oracle though. My favorite was that if you declared an index on (col1, col2) but issued a query as "where (col2 = X) and (col1 = Y)", it would ignore the index (the optimizer was stupid, even though the coder should have been more careful coding the SQL statement) where, in the same scenario, SQLServer would recognize that an appropriate index was there, just reversed, and use it.
So in this respect, Microsoft does play an important role in the creation of commodity computing. But they did not create the market. And they certainly didn't create the market with Windows.
I agree with this statement. I don't think they created it either, but I do think they helped it along a lot.
And thanks for a good reply, it was a good read. It seems that you and I are "of an age". I, too, got my first computer before there was such a thing as an IBM PC.
It was there, somewhat, but not to what we know today.
Take graphics cards, for example, I thought about this some last night. Before there was a "standard" API, they spent time on performance, price, their own API, and wooing developers (games and applications such as AutoCAD) to use their API. When Microsoft said "use our API and we'll handle the developers", that freed up the graphics companies to concentrate on performance and price (freeing up the companies from the kickbacks and such allowed prices to drop even more). Microsoft handled getting the developers (games and other applications) onto Windows.
"Commodity computing came about during the time of DOS - far, far before Windows." Simply stating this over and over without definition does not make it true. Did you ever buy a DOS machine? I did... several, and they were not really commodity. Sure, they were mass produced but they were not cheap (which is the other side of the 'commodity' coin). The prices of the machines back there were roughly what they cost now. You could get a decent machine for $1200 or so (today, I'd say you could get a decent machine for $600 though), however, the economics of the time were that the $1200 of the machine was a lot more money relative to other costs (and paychecks) than today. If you don't believe me on the price, go look at advertisements from that time period (late 80s early 90s). I bought a machine that was "workstation" quality in/around 1994 for nearly $5000, which was a lot of money at the time (still is, but it was relatively more then). It wasn't the highest end CPU at the time even (only a Pentium-60, yes, with the bug, but the 90s were out) but it had 32M memory and the largest HDD available at the time (540M). Since 8M was the norm for the time, it'd be like getting a 4G machine today with a 300G HDD. What kind of machine can you put together for $5k today? What's the difference between having $5k in 1994 and having $5k today?
Providing a unifying platform (both hardware and software) that was on the vast majority of PCs allowed hardware vendors to benefit from economies of scale just like software.
Yes, PCs were starting to benefit from economies of scale (becoming commodity) during DOS (which... was MSDOS, btw, which was made by Microsoft as was Windows 3.1 and 95 and on) days but the full extent of commoditization hadn't been realized at the time. It took a unifying software architecture as well to complete the picture. So, Microsoft probably did help PCs to become commodities even, as DOS was Microsoft's thing.
GL did exist and was partially supported by Glide, for example, in the early '90s. OpenGL was ratified in 1992 but took a while for adoption. Not even all the Un*x vendors adopted OpenGL quickly. The amount of support vendors offered even differed (both on Un*x machines and PC video cards). It was hardly a "standard" on the PC side of the coin and never really was *the* standard. A number of cards delivered OpenGL libraries for their cards and OpenGL came close to being *the* standard with the Voodoo cards but DirectX came out and for various reasons, DirectX pretty much won. On the PCs, you had lots of choices... CGA, EGA, VGA, VESA (hopefully only if that was your only option), and others, in addition to a few cards like the Voodoo Glide cards that supported only a subset of OpenGL and some other cards that supported their own proprietary APIs. Also, Microsoft/Windows was defining graphics cards standards during the Windows 3.1 timeframe, which was quite a bit of time before Windows 95 and a bit of time before PCs were really commodity items.
The history of the PC and how it became a commodity is entertwined with Windows since Windows was delivered with PCs the whole time. Which caused which? I guess I'd have to think about it more.
Yes. I can write a blog and put whatever I want in it. A professional journalist knows that if he/she repeatedly publishes lies or inaccuracies, they'll be finding other ways of earning a paycheck (thus, providing food for their bellies and a bed to sleep in).
As always, it's the difference between just spouting stuff because you want to and basing your life/livelihood on something. In one, you have no risk. In the other, you most definitely have risk and a vested interest in being a professional.
Yeah, they're so afraid of the Internet that growth has been doubling every year since around the Windows'95 release timeframe. They are paranoid about being on the 'net and think it's normal to run anti-whatever ware as a basic acceptance (whether right or wrong) that computers are not infallible. In some ways, computers have evolved from being "magic" and "universally fantastic" to being "just another device" that has its share of problems and issues just as any other product. I think this has been good, overall, for the world. Holding something as being "magic" by the general populace leads to some bad things (worship, etc.).
Positive contribution my Microsoft: commoditized and standardized the personal computer products. An example of standardization is graphics cards (before Microsoft imposing standards, every card was different, etc.) Have you ever set up Glide? or had a game that ran against VESA (crappy) or Glide (proprietary but good)? The reason why graphics cards are like they are today is because of Microsoft. Derived from this is games on the PC. Software developers don't want to have to build against and test against several grahpics APIs. A standard graphics API has made making software (games) much easier to write to target a large market (all Windows PCs as opposed to PCs with Brand X or Y video cards). Commoditization of PCs can be seen in the fact that so many households around the world have PCs now.
Do not underestimate what benefits having (practically) a single platform to code against has had on the software industry. Being able to write one piece of software and have it runnable by 90%+ of the world's machines is a very strong benefit.
Not only this but Linux itself has benefitted. Not only did Microsoft give all those folks someone to hate (someone to motivate them) but the standardization and commoditization of PCs has directly enabled Linux to be successful. PCs are cheaper as well as have a number of features that Intel and Microsoft developed together.
His software is one of the temptations that we need to avoid if we're to obtain a fully free-software world.
Assuming that is your goal. I, for one, do not have that as a goal. I'm happy with having both open and closed source and see no reason why I should *desire* to eliminate one or the other type of software. In fact, the idea is somewhat hypocritical.... "I want people to be free to develop software, but only under the type of license that I like."