They had likely-cost per card as well (if you'd read the article). The previous poster was saying that Tom one-upped the simple price point.
In fact, I was checking pricewatch and his numbers are pretty much on the mark - you could find cheaper no-names, or more expensive top-tier name-brands.
Most casual/avid gamers are very interested in price-performance (e.g. value), so this new metric is very useful. Of course, we gamers had long been able to assess this comparative "value" metric heuristically.
One final point, he provides two price-performance metrics, "raw performance/$", and "graphics-quality performance/$". I often switch back and forth between the two modes.. When I'm just casually playing I like the quality settings to be on high. But when I'm playing against other people (and every FPS counts), I switch to the performant settings.
Personally I like setting limits like $100. This in fact use to be the sweet-spot for price-perf. Unfortunately graphics card manufacturers are REALLY trying to raise the bar.. Currently it looks like $150 is the new price-perf region, and all reviews are sitting in the $200<->$300 range (with sub $200 cards occasionally getting spot-light)
Anymore, the vid-card, sound-card and high-perf ethernets are the only things I care about. MB + CPU + Mem + Case become an old Linux machine / firewall / vncserver (for aim).
Considering that the average MB+CPU is only $200, this isn't a bad deal.
IANAL Not withstanding the other poster's comments (which I don't think would stand up in court.. phone companies are regulated and thereby recognized. End users are not).
This is one of my biggest concerns; cover your own ass. Thus I recommend if using such a network to apply filters (you should be able to hack the source if this doesn't already happen). If you receive a broadcast discovery packet for some filtered-out info, just drop the request; don't pass it along.
It's sort of a free-rider system.. I'll happily make requests to peers for any data, but I wont pass along requests for most forms of data.. To be safe, you'd have to limit yourself to things like non mp3, etc.
If there are specific legitimate files that are being thwarted by the system, then a manual override of the trust-tree can be accomplished (allowing a specific matching rule to pass). Since this requires human interaction, this can be very innefficient, but ultimately through refinement (and abuse) it would produce a legitimate network; out of fear.. But many would say, "it's not likely that my friends have gotten caught", so many would still participate fully.. It would be something akin to speeding.. Many speed, many do not, and most go back and forth between the two.
Not sure, but there was a discovery channel special on the prospects of building a super-bridge across that channel (obviously a scrapped idea by now). In the design specs, they referred to VERY deep portions of the channel. Sorry that I don't have more specifics, but this is definitely an undertaking if there ever was one.
My biggest fear for things like this are war-time. How easily could rivalry bring terrorists to blow the tunnels.
I find that open source is not so valueable in that people inspect my code and provide feedback. Instead I find the following realizable benifits:
A) I can build apon other people's code.. It's effectively stealing their ideas, BUT since I'm GPLing my code as well, there is no net loss, and they are free to resteal my ideas back (if they are so inclined). I do often refer original authors to my new code.
B) I recognize that people MIGHT secretly build apon my code, so I get a warm fuzzy.
C) I can fix problems with open source drivers (postgres jdbc driver, GNU file-utils, etc. are some of my examples). Moreover, my debugger can jump straight to the line of maliscious code.
D) When I am about to release code publicly, I feel self conscious, and thus I put a TREMENDOUS amount of effort into cleaning up the code.. Making sure various platforms work, making sure there is no embarrasing spagetti-code, etc. Thus the mere possibility of people reading my code causes me to exert effort that I wouldn't otherwise. The end positive is a lower propensity for bugs, AND more modular/reusable code (especially with anything in perl).
The end-end result is therefore that Open source facilitates greater code reuse; less re-inventing of the wheel.. And more importantly code extensibility.
Now this begs a question of the distinction between modules and out-right applications. Open source is great for producing millions of reusable modules, but we often get chastized about the availibility of abundant QUALITY applications. Well, in my view, the merging of these two is two fold:
A) Open source applications tend to be more "plugagable"
B) Commercial sites will often pay developers to use open source modules and customize them to the particular needs of the corporation.. In doing so, serious feedback is provided to the various open source projects (because it is in their mutual interest to refine the modules). I as part of such a corp, have contributed (in various small ways) to several open source projects on the corp's dime, and with full authorization. This is of course, a completely unreliable source of income for a project, of course, but it is definitely a facilitator.
Re:A nit on the "dead white males" section...
on
Human Accomplishment
·
· Score: 1
I like in the movie "Bueatiful Mind" where John Nash conflicts with this mentor on a colleague recieves the distinguishing honor of the pens. John said that he saw "recognition", while his mentor said that he saw "achievement".
What this book is measuring is recognition; primiarly because it was easier to measure. By this metric, women should still maintain very low scores. True achievement measurement would have to complexly associate the utility of life before and after a contribution. Since we can't really poll peoples' life-styles thousands of years ago.
I don't know what point you are trying to make about blowing up stars.
You can't synthesize fuel indefinitely in breeder reactors. That's the idealized perpetual motion machine (keep itself going forever and extract energy from it in the process with no additional input). So if you produce enough [breeder] reactors world-wide, you will eventually deplete the world's supply of this already rare material in no time at all. While the reactors may last for some time with the fuel you give them, that time is most certainly finite.
The only reason that nuclear generated electricity is not cheap and plentiful is because of artificial constraints on the market.
Nuclear power is cheaper, cleaner, and safer than the alternatives. I liken nuclear-power being safer than ? to the misleading comment that air-travel is statistically safer than driving. If you include that most car-drivers are morons, and few pilots are morons, then I might agree.
Take this little factoid.. Statistically, the concord jet was the safest method of travel of all types of travel ever experienced.. Why? Because there were zero accidents.. And zero / {small-number} ~ zero accidents / unit. Then when the concord DID eventually crash, it became the least safe airplane in the world. (Because the DC-10, with it's bad record, had MANY MANY total flights). Since 1 / {small number} compared to {small number} / {very large number} happened to not work in the concords favor (heard this on NPR; don't know the actual numbers).
I would believe the statistic of air-planes being safer than driving a car if there were as many flights are cars driven on a daily basis. "not a fair comparison" you might say? Well, I suggest that it is the volume across such a diversity that is the problem, and that if you are as skillfull as a pilot, then you'll be as safe as an airplane while driving; if not more. Note that it's less the skill and more the ability to concentrate while performing a life-threatening task (as opposed to fiddling with the radio/make-up/conversations/etc).
Likewise, look at the number of nuclear reactors in the world.. Now look at the number of dams. How many dams have failed; killing hundreds/thousands of people? Maybe a couple a long time ago, but I haven't heard of any recently. Moreover, I haven't even heard of dam-scares (though I'd probably be more scared living beneath a dam, than living near a reactor).
Alterantively, look at coal-fired plants.. How often does its boiler room risk the lives of neighboring town/ countries? Sure there is long-term damage done by coal-plants, but the same is the case for nuclear reactors.. spent-fuel leaks, improper disposal, neighboring land of both the plant and disposal site being un-inhabitable.
As for the cost.. I don't know where you're getting that nuclear power is cheaper. For countries that wish to be self-sufficient, and are willing to accept the ENORMOUS cost of waste disposal, it might be over-all a better solution.
The reason it's so expensive in America is not that it's held back, but that we are very concerned with safety both before, during and after usage. Skepticism is a good thing, in my opinion.
Perhaps there are some other reasons I'm not aware of for America's expensive nuclear reactors.. But this is the first time I'm hearing someone suggest Nuclear is, in fact, cheaper.
I'm fine with nuclear personally. And I wish we'd ramp up investment dollars to develop more modern / efficient reactors. I'm just not convinced that nuclear is the panacea that you're making it out to be.
There is plenty of energy to go around, just look at the sun!
But energy isn't the problem.. Power is the problem.. Power is energy consumed per unit of time.
For example, We have a thousand watt micro-wave, but our electric bill is in "kilo-watt-hours". If we divide the electric bill by the fractional number of hours we used the microwave, we'd see how much power the microwave consumed on average (which should be near 1,000 watts).
Look at how we cooked food several hundred years ago. It was by wood-fire or coal-fire. Thus a single tree could feed a family for quite a while. Now we use a microwave for 10 minutes per family member (or an oven for half an hour).. So let's say it's a kilowatt-hour of energy. Solar-cells which are (lets say) 25% efficient, and only produce a couple watts of energy over a decent period of time (don't have numbers in front of me), mean that the raw energy from the sun is not enough to feed our current appetite.
The sun IS enough to feed us.. We could use a magnifier and focus it on our raw food for only a few minutes and heat it up nicely. But it's not convinient.. Thus the "convinence" is what drives us to use more powerful mechanisms.. And thus require larger amounts of energy than we really need.
Look at a 3 cylinder geo metro.. Or a 1975 volkswagon desel. They have hardly any horse power. But consume their energy slower and more efficiently.. Likewise, coal-burning steam engines have very little power.. But use weaker wood/coal fuels. (Where a wood burner only uses a couple years-old-tree worth of sun-shine).
Driving 45 is a near optimum speed for most vehicles.. It can use a high enough gearing that allows "some" acceleration, and isn't at a speed that allows rolling resistance / air-resistance to dramatically affect efficiency... Driving any speed faster than 45 mph has a dramatic effect on fuel efficiency..
And aside from the highways, 45mph is the speed limit... Yet, we drive 80/90 mph all the time.. This can drop our milage almost in half.. Moreoever, in a traffic jam, we "floor-it" to prevent people from cutting us off.. This requires an enormous amount of power (even though it's only over a short period of it). Why? The bursts of speed don't even get us there any faster.. It's the social issue not wanting to be taken advantage of (being constantly cut off).
Likewise, we get gas guzzling vehicles today, not because they go any faster, and often not even because they accelerate faster. But because we are competative.
Likewise, for a short while, people took the concord instead of more efficient, cheaper, more luxurious flights. On the outset you might say because it is faster. But in reality, an air-port's wait-time is comparable to it's flight-time. What's 3 hours saved if you have a random possibility of getting a 2 hour delay. Sure the concord's price meant short lines, but that too is part of the point (socio-devisions of energy-consumption).
Given the rise of electic-ovens, then microwaves, then air-conditioners, then computer/home-entertainment-centers. I feel it's highly likely that we'll invent more power-hungry "normal-use" items.
Imagine the discovery of teleportation.. Lets assume that it consumes mega or giga watts of power. How useful would this be? And therefore, how much power would it consume? You think our current spending habbits are bad?
Now, about the sun having enough energy. Just look at the enormous amounts of power we achieve from solar cells.. This is a direct realization of the energy ebbing through our solar system.. You might scoff and say our solar cells are currently too innefficient.. But we're talking about 25% efficient cells... We can only get 4 times better.
How about large mirror-array power plants? Well, if you look they are enormous in scale. And they still take time to boil their target water.
How about our fossil fuels? Well, they took millions of acres of space and compressed them over dozens
Unless the environmentatlists let us start building nuclear powerplants again.
How does this solve the problem? Now you exchange the abundant low-energy organic fuel for scarse high-power solar(nova)-generated fuel.
We can always burry a couple continents worth of trees.. Can't exactly detonate a star yet.
I think the answer is in more efficient consumption, and more efficient energy-extraction. We're always going to find ever more power-hungry uses of fuel, so simply expanding our extraction of a particular rare resources isn't much progress.
Thanks to economics/capitalism, what's going to happen is that people will extract from what-ever resource is cheapest.. Until that resource becomes more expensive than competitors (natural gas, renuable, nuclear, etc). Each competator in turn will be depleated until the next most expensive option can compete..
This goes on until it's cheaper to research alternate/exotic forms of energy.. All along the way, each consumer experiences higher prices and thus is inclined to be more conscientious about their consumption habbits. Right now fuel/electricity/heating are the cheapest elements of our life-styles. It's what's enabling us to grow in socio-technological respects. But as we start to struggle to maintain our life-styles; we'll find the motivation..
In summary; there are no cheap/easy solutions our fuel/pollution problems.
Well, I agree, but you're making the wrong impression. x86-64 and the G5 BOTH utilize 32bit instructions; they merely add on new instructions. So their ability to run 32bit code is paramount.. Plus not every part of every program needs 32bitness (for same reason why we still have 8bit instructions (e.g. character manipulation) or 16bit instructions (wanting integer modulation)).
Also, there are proven benchmarks that show that the opteron indeed runs faster, though due to the many differences between the opteron and the K7/P4, it's hard to narrow down exactly where the performance increase derives. The key feature, as stated is the doubling of the number of registers... The x86 has NEVER been able to perform register optimizations (like loop unrolling, etc) because there just arn't enough registers for even trivial book-keeping operations. The only way of really speeding up such apps is to have smart CPU's which rename explicit registers into remappable internal registers while instructions are running in parallel.. It's very hard however (and EXTREMELY cpu-specific) to have the compiler write code that can take advantage of this.
So having more regs means at least all the book-keeping can be explicitly stated by the compiler, and MANY explicit memory load/stores can be avoided (including CISC: add [mem], [mem], [mem] operations).
BUT, here's the misleading part.. The G5 has been RISC for a LONG time.. And one of the key tenents is 32+ registers. So while the x86-64 nicely ups the anti to a whopping 16 registers, don't get too excited, we're still living in the dark ages.
The main reason is that we're still doing register renaming, so to have 32 explicitly named regs you'd have to have nearly a thousand renamable registers.. This means slower addressing time (more propagation levels for a greater power-of two number of addressable registers). Is this additional cost warrented? The alternative is removing the power of the existing renaming facility, which may hurt more than help. So, given that CISC operations can still efficiently use memory addresses as virtual registers (e.g. the CPU keeps them in high-speed caches), it's a cheaper / faster over-all solution to just stick with 16 registers.
It still doesn't solve the problem of loop-unrolling however, so I'm not particularly happy with the decision (Being a compiler whore myself). AMD's not going to get another opportunity to radically alter the x86 line.. Intel is going to do this next and AMD will have to play catch up again.. And it's possible that the x86 won't last another major iteration (e.g. x86-64-AI?)
Don't underestimate the advantage Apple has in setup & maintenance due to the fact that it builds the hardware AND the software together.
How often do you get custom server application software (that you wrote) pre-installed on a server? Ok, rhetoric question.. How about, how often do you accept factory-defauls of hardware? A friend of mine that kept OS X on his recent mac still spent weeks finding / installing OS X varients of Linux software to enhance productivity / work with our product cycle.
Ok, so lets say you're seasoned and you've got this down to a science. Then what about patches? Upgrades? cluster configuration?
Well, since we're talkign about clusters it's highly likely that a single machine will be set up and a CD will be made to batch install/configure/boot the machine (boot in the case of disk-less machines which requires zero per machine maintanance). This batching process is trivial compared to the time it'll take to physically mount all the machines, so the difference in "maintanance" of two differing pre-built machines styles is largely irrelevant for said clusters.
So now we're back down to power requirements, physical space requirements, per-machine costs, and per-machine performance.
And for those claiming that G5's perform faster than P4's, I'm not convinced that "gcc compiled" custom cluster apps running at either 3.2GHZ with hyper-threading (gack, I mean CPU-threading), or AMD's quad proc'd opterons can't outpace the G5s. While the G5 is RISC and has fewer stages than a P4, it doesn't have the clock speed of the raw integer pipe (running at 6.4GHZ if I'm not mistaken). When it comes down to it, P4's / Xeons are faster than opterons, and in many cases faster than G5s. But you need to see the particularly compiled apps to really know which platform is going to run quicker. And my bet is that the opteron/G5 running a full GHZ slower than P4's isn't going to offer tremendous additional overall value.
Too bad the Itanium isn't catching on (and thereby getting economies of scale discounts); it's really a bargain when you get into $5k+ machines (which we're talking here).
POSIX is an API. When we say "UNIX" we generally refer to the POSIX API. An API's whole point is to abstract the particulars of an implementation. For example, Perl actually implements fork on windows through the use of independent interpreters runing in a threaded environment. Java, also is an API which facilitates things like graphics and asynchronous file access (strangely similar to UNIX IO selection btw).
To say that GNU's Not Unix with a straight face is to miss the point.
Likewise is to differentiate the implementation details of clone v.s. the front-end API "fork". "clone" is only significant because it allows the kernel to have a single entry point to handle process creation; both threading and forking, differentiated only by a memory mapping flag. Is it any less significant that some primitive implementations of POSIX concepts delegate inter-process pipes as physical temporary files?
Granted lack of full POSIX compliance exists in things such as signal delivery to threads. But it's rare to find a fully POSIX complaint OS.
Remeber in 1984 how it was somebody's job to go back and modify all public records of an old "inconvinient" fact. Just imagine being able to control dictionary.com / cnn and a few other heavily hit sites. You'll be able to remove any record that something existed.
I am not suggesting we would see a WW2 type atrocity happening in America.
I'll one further your general argument by disagreeing with this line.
Though somewhat of a rambler, "Gore Vidal" has written interesting books on the imperialistic nature of the United states. "perpetual war for perpetual peace", for example, supposedly lists hundreds of "mini wars" that most American's aren't even aware of.
WW2 was an issue because germany wanted to extend it's influence on neighboring countries. The only difference between the US and that is the size of the countries we "enforce control over". It's essentially 1700's imperialism all over again. We sophisticated Americans bringing "third world countries" (a more PC version of the old phrase "savages") back into alignment... Read: "You're either helping us prosper, or you're our competition".
The sick irony is that this is exactly what we accused communist countries of doing throughout the cold war.. "We must fight this slightly immoral war, for fear that communism MIGHT spread"; pre-emptive killing being the letter of the day.
It's only in high profile cases such as Iraq that any Americans ever care. Other countries (especially those affected by our policies) have been crying fowl about this for decades.
Unfortunately I can't imagine any way of preventing this.. "absolute power corrupts absolutely". Even if we were to "shake things up" on capitol hill, the successors would faced with the daunting task of "giving up political influence". Would you be willing to give up your biggest bargaining chips merely for a good cause? Would you cast the ring into mount doom?
The best I can figure is one of my favorite phrases, "A little revolution every now and again..." - Thomas Jefferson
Itanium / x86 instructions sets are ALREADY merged. That was the whole point (originally).. There is a "jump-to-x86-instruction" itanium op-code which allows you to run "legacy" subroutines/libraries. The original Itanium simply emulated x86 instructions though (poorly at that).
So what you're really suggesting is to take a Pentium 4 core, and "emulate" IA-64, via a "jump-to-ia64-instruction".
This is a highly non-trivial task, because IA-64 has COMPLETELY different assumptions about hardware resources (128 regs of both int/fp), as well as rotating registers (a la sparc), which means more than 1k total registers (all 64bits). While many of the registers can be reused as castrated x86 register-renameables, it's not likely to be possible to optimize register access for BOTH reg-renaming and direct reg-access.
Intel had the option of trying to optimize x86-32 for upcoming itaniums, but last I heard, they were merely going to throw a P4 onto the motherboard to run legacy apps (a la co-processors).
Frankly, I think that's the correct solution; they should have worked co-processor instructions into IA-64 from the beginning. At the prices of these systems, heterogenousness isn't going to be a major additional factor.
That being said, I don't see a viable Itanium -> x86 merge.
Electro-statics implies non time-varying electric behavior. This involves the full collection of time-varying electric and thereby magnetic interactions. Which are too complex to even model for individual atoms. To give you an idea of the complexity. Imagine the gravitational field of 3 massive bodies. Knowing their mass is not enough; you must also know their initial velocities. Even then, you pretty much have to solve the system numerically with a particular margin of error.
The problem grows unbounded as you add more massive bodies into the system.
Now imagine an entire nucleus of such rotating relatively-similar massive bodies, surrounded by electric satilites which are massive enough to affect trajectories.
As far as I understand, mozilla has A) a tremendous set of abstraction layers B) A javascript Virtual Machine.
VM's mean lazy garbage collection which means a HUGE heap.
For me (on Linux), mozilla takes up roughly 100M, swaps 230M and shares about 12M. That 12M shared suggests a lot of the shared libraries, which each will want a decent sized chunk of writable memory (which can be swapped if not in use).
In fact you DON'T want mozilla to always stay in memory, since much of that shared library stuff is never going to be used (for the reasons discussed in this thread). The only problem is that Virtual Memory pagers will discard read-only pages before dirty pages, so if you leave mozilla running for some time, then it's very likely that some critical "core" executable code won't be there. The problem is exacerbated by the VirtualMachine which is constantly loading and dirtying pages for the purposes of garbage collection. The OS will try and evenly distribute available pages between actively running programs.. So if mozilla is consuming 50% of your available non-cached/buffered memory, then if four other apps are competing for the same memory, non-dirty least-recently-used mozilla pages will be invalidated (and require subsequent reloading from disk).
So the only way to avoid swapping / invalidating-r/o-pages is to have enough memory to A) Allow all running apps to run (evident by having > 10Meg free, since 6Meg and less cause conservative page-flushing) B) Making sure that all your normally used files can be fully cached into memory (add size of your normally accessed mail-boxes, your full database+journal, you common/usr/bin files, etc) C) There is plenty of room left to build to like 100Meg of buffers.
We're talking at least half a gig of memory so that you can run a 100Meg app like mozilla.
I have hardly any experience with light or worse chromatic computation; only what I've read on slashdot really. But two challenges immediately occur to me.
1) Injecting multiple colors down the same fiber (wave-guide) at the same time will not allow all the colors to appear at the other end at the same time. There are non-linear impedences (attentuations and phase-shifts). So we're trading regions of stability and noise-rejection with the technological challenge of working with synchronizing multiple signals. It's actually the same problem as SCSI/IDE ribbons.. Manufacturers are going to serial buses to avoid this exact problem. But the serial bus is only a transport; not part of the computation.. So I don't know how well this problem maps into the low-level computation.
2) There is the problem of processing in a purely chromatic space.. I've read rumors that various company's have achieved 100% light-based computation (especially useful in networking, to avoid transcieving the data). I'm not aware if their computation is monochromatic or not. I would agree, if this were indeed possible, then it would be remarkable. But again, I must bring up the plausibility of making a pure-light based system denser than a binary electric one. Just as with electric, unless you achieve a digit density of no less than $numDigVals or so times weaker, you're not gaining much. (though in the case of light computation, there is the possibility of faster computation or less power consumption / heat dessipation). And, again, I definitely acknowledge light-based computation has been extremely useful in communications, where latency is removed by not having to convert back and forth to electric at each repeater/router. But I push this into the fringe of specialization, just like electric modems.
No capitalist corporation does something, especially something that costs money, unless there is a benefit involved.
If your premise were true, no company would ever go bankrupt since everything they did would be to their benefit, involving "undoubtable profit".
You interpret his comment incorrectly. To say that a capitalist takes no venture not prone to benifit is a far cry from meaning that businesses need garunteed returns on investment. It is more tau-istic, than anything; a pessimistic view that in any apparent good deed a corporation does, they have an ulterior profit-minded motive.
Take NPR (National Public Radio), companys make grand donations all the time. Isn't that altruistic? Is that great for the public good? Well, I only know this fact because I hear the advertisments that acknowledge these grants to the individual companys.. Oh, and I get to hear the company's tag-line right after hearing about their generous donation.
Ok, so this is merely a thinly disguised commercial, and they're paying for it as they would a non "grant-based" commercial. What's the point? The point is that you could interpret this pessimisticly as corporations trying to subdue a class of audience (those that think they're not having to listen to commericals). Subdue? Yes, commercials are not meant to "get the message out"; to let people know that a service exists, but to indoctrinate various slogans into peoples head through repetition. "I need a light bulb". "Oh yeah, G.E., we bring good things to lite".. They must make better light bulbs than westing house (or who-ever else non-pathmark brand makes lightbulbs.. see it already works).
Now, it's possible that some company's make anonymous grants to NPR, and thus can't attain such commercial dredgery. And we'll even neglect the tax benifit. We'll even neglect the fact that stock holders might demand that the otherwise undonated money should be distributed to share-holders. Incidently, how could this simple common sence act be considered bad? They're share-holders, don't they have a right to collect on profits if they wish? How could this be interpreted pessimisticly? Well, just take a look at current stock-scandles. American Corporations have written the book on how to manipulate their own stocks. If you allow for a greater than average dividend or profit realization one year, then you've set expectations for subsequent years. Exceeding expectations gives you very little beneifit.. Maybe a few temporary points higher stock. But woe is the company that misses a projection by even a fraction of a point. Better pretend that we had a bad year (by donating some of the excess), then to risk not doing as well later.
The previous poster's comment was merely a reflection that MS is a modern industrous company who is very evidently willing and able to use every dirty trick in the book.. Hell, they invented a whole new generation of dirty tricks.
Does this mean company's are bad? Absolutely not. Does it mean we should give them an inch.. Hell no!! Fight the bastards every step of the way.
This current IM debackle means competition to AIM. That means squelching Open Source environment's use of instant messanging to our non-geek peers. Whether they care about hurting open source instant messenging is frankly irrelevent.. This WILL be the effect of their actions.
Hence, making such transistors would allow chip makers to make huge strides in speed without having to handle the engineering problem of packing in more transistors.
No, they'd just trade the engineering problem of packing more bits into once space with finding ways of unambiguously interpreting a value.
See the whole power of binary (pardon the pun) has always been it's wonderful noise-suppression ability. Imagine a copper wire running 2 miles with either a 5V or a 0V signal on it. You can apply a simple analog device (say a BJT transistor amplifier) that utilizes an exponential function switching at some precisely known voltage (we'll call it 2.5Volts). Voltages before and beneath this voltage are amplified to either zero or 5V exponentially, such that only voltages within a small delta of the threshold voltage have any ambiguity.
Thus you can determine the likelyhood of noise on a line, then put digital amplifiers every so often such that no amount of noise will be sufficient to raise or lower the voltage to the ambiguous region.
The same is true even on micro-scopic wires; Fanning transistor outputs out to too many transistor inputs introduces noise on the wire. CPU's not surprisingly utilize "buffers" which are trivial 2 transistor logic gates which pass the output to the input. This cleans the signal just as the higher-powered digital amplifiers do.
While I'm not sure which particular technologies are being considered in this trinary/quatrinary logic system, if it is nothing more than a sub-division of voltages, then it's doomed to failure for general processing, and possibly even simple memory storage. First of all, you introduce another whole region of voltage ambiguity. The only way to maintain your safety zone is to up the voltage or provide more amplification stages to garuntee a cleaner signal. But the trend has been to decrease, not increase voltages (lower power consumption, smaller devices, whatever), and adding additional logical devices merely to interpret a signal means that your bit-density is going to suffer.. Exactly impeeding it's whole point.
Likewise for denser bit-storage, since the probability of bit-error necessarily increases (all else being equal), then you're not as likely to achieve as small or as dense a physical digit. So unless you can at least achieve less than 1.5x logical-digit spacial expansion (due to error-compensating material), you haven't gained anything by going to a trinary system.
Lastly, the concept of >2 digit computing already has a particular niche where it's trade-offs are acceptible.. Think of 56k modems which encorporate dozens of thousands of "values" for a single digit. They utilize a full 256 voltages for each anticipated time-slice. Of course the analog modem can't anticipate the exact sampling point where the analog phone line gets digitized (happening to transition at that point can be bad), and there is usually a tremendous amount of line noise. But what modems wind up having to do is group several time-slices together and produce a macro-digit with a but-load of error-correcting pad-values. And that's not even enough; the entire packet is still likely to have misrepresented digits, so CRCing and thereby retransmission is often necessary.
All this effort is worth it because we physically realize extra bandwidth.. But such a "probabalistic" solution (prone to bit-error) is unacceptable at the lowest level of computation. You can't get any less error prone than binary (given the above discussion), and mathmeticians have shown that base-e (2.717) is the optimal number to balance complexity of the number of combinations with the number of digits in a given number. (analogously demonstrated by considering an automated phone system where you have to wait to hear 10 possible choices per menu (the base-10), and you have to go through k menu levels to achieve what you want. The metric is the average wait-time using different bases, and mathmatically the shortest wait time was the
Well, Athlons typically want 350W. There were 128 machines.
Thats 44.8kW
Now take into account at 120V that's 373Amps rms. With all the surge supressors/power-strips, we're talking a serious amount of impedence (fwi, not resistance).
Not to mention, the typical circuit breaker clamps at 20amps. You'd have to have 36 separate circuits in a typical office environment (a circuit usually services several outlets).
To boot, the impedence at such high currents running off the same master power cables could cause serious power level fluxuations; especially at boot time.
Now this is a university; they're likely to have very clean power signals, and possibly each plug runs a seperate voltage-regulated power line. And they definately can sustain high power (look at the cables). But don't expect that sort of power center to run cheaply at your local ISP.
In a fit of coincidence, I've recently tasked out the problem of power distribution, and the solution I came up with was gutted DC AVR'd UPS's (with the DC->AC component gutted) that directly connect to the motherboard; bypassing the switching powersupply and any external drives. Given enough external cooling, you could even resort to passive heat-sinks (albeit large/copper/expensive). You could probably get the power dessipation down to 100W (75W for cpu, 25W for MB+passive periferals). It might be cheaper to get ahold of laptop style power batteries, but I don't know of an easy way of getting them off-the-shelf without just buying laptops outright (more expensive proposition)
The battery-operated systems gives you two things.. Lower total power dessipation, and greater power stability under non-uniform loads. Due to the AVR, it's also possible to use very long power cables to stretch across sides of a building (as a short term solution; avoiding rewiring the master power distribution)..
This is why some organizations do not allow their employee's to have root/administrative access to their own machines. Unfortunately even that isn't enough to prevent installing home-directory applications, but typically those are free software anyway.
Couldn't say personally how effective this policy is; I've only ever been on the recieving side of it.
I have seen software crash both Windows and Linux, MySQL has eaten any and all available memory on Linux
Dude, use ulimit. Out of memory is not an excuse on a unix platform. Likewise with forking-to-death or disk space.
mysql, postgres, httpd, etc all have provisions to limit the number of connections and in some instances memory foot-print (postgres). But all of that can be backed by ulimit.
Disk space a problem? Use disk quotas, or simply sym-link to a separate partition to prevent one overzellous application from hogging too much disk space (killing either/tmp or/var/). Not to mention that root apps get that last 5-15% of disk space all to themselves, and don't even discuss running a service as root anymore (including mail).
The key to UNIX is building apon trusted concepts instead of re-inventing the wheel every 3 years.
I will say in both Linux and MS's defense, however, that making a server robust is a lot easier than making a front-end robust. Servers typically don't require interrupts (disk and network can often be offloaded for most of their activity), and usually don't require any hard-to-protect application-spaces. The services have well defined interfaces which are relatively easy to detect (especially with over-flow exploits).
The trouble is when you're writing interactive applications, or computer-interfacing devices: USB/serial/parallel/video/sound, all with really creative/ambitious drivers that need kernel access. Hell, the fact that a GUI can be hardware accelerated makes this limitation as well. However, using a client-server model allows that the data be kept safe even in the event of a front-tear-down. If you application-space and your GUI space are separate (a la X), then a GUI-lock can still allow a back-end access to gracefully kill the server-applications (word processor, checkbook, code-editors, databases, etc). I love the fact that I can almost ALWAYS go to an mgetty'd text-prompt or ssh in from a remote machine to recover from a GUI crash.. And I almost never lose my data (except in non-persistable data like HTML-forms; mozilla RFC anyone?). X is not necessarily part of the OS; it's just a regular application (barring optional hardware acceleration). Likewise X-apps don't have to crash when X crashes.
This is the model that I'd like to see facilitated, not the COM/DCOM-like CORBA/GNORBA/RMI/KDE-distributed-computing, where each application is dependent on ALL peer applications behaving well. So what if you can embed a spread-sheet in a word processor.. Just freaking directly link to the source code. I don't buy that the benifits of such peer-computing warrent the TREMENDOUS loss of robustness it afford (I run KDE apps under a gnome interface so that WHEN the KDE backend crashes, my GUI is still alive).
It's this complete lack of robust-design principles which have made MS a laughing stock when compared to stability, even though they invest millions/billions(?) of dollars into code-review/quality-control.
That's true for any two chips that run the same architectures; why is it better to have to compile for x86 and MIPS then to compile for x86 and (possibly) x86-64 and have the choice of running the x86 binary on the x86-64?J
If I understand your question well enough, then that's easy. You don't have a choice about compiling different binaries for different "platforms", where a platform is both an OS and a particular piece of hardware. Linux distributions, for example, simply must compile their entire software line for each and every platform they wish to support (with a few source-only distro's as the exception).
When you have a 100% compatible platform, however, the added cost of producing a completely separate distribution with archetectural flags fine tuned to each varient is too high.. To say nothing of the confusion of having 5 or six different boxes on the shelves.. People can barely find the difference between mac and PC logos, to say nothing of a pentium v.s. AMD. Then think of the administrative overhead of having to lug around 3 or 4 sets of Linux distro's to administer the likely diverse computer pool.
Same applys to windows software; while it's not too hard to swap out dlls for the appropriately platform-dependent compiler optimizations, it costs money to do so.
Again if they choose to market to differing platforms, that's a choice that says, "get these additional customers".. When optimizing for compatible varients, what are you gaining? A 5-20% increase in performance and thus a slightly happier person... It's much easier to say "optimized for Pentium 4" (with a stupid audiable logo).
So now back to your statement.. What's so special about x86-64? Why should we bother differentiating it?
Well, in Linux we have to recompile the kernel suite for the 64bit kernel anyway.. So there is a clear need for SOME differentiation.. Moreoever, given that x86-64 owners are somewhat sophisticated, packaging isnt necessary; only downloads.. Thus the cost is merely reduced to setting up the configuration and building the ISO and allocating disk space on the mirrors.
Of course I say all of this as a lay person's speculation.
Ugh. 64bit != faster In fact there is no imperical evidence that any 64bit implementation is faster at doing <=32bit calculations.
What 64bit means is a radical archetectural shift, which affords (both to compiler writers and to the CPU designer's management) an excuse to add other radically new technology that is independent of bit-depth. Namely, we're spending the money, might as well pack-the-punch.
AMD64, for example uses a new CPU-mode which gives them cart-blanche ability to deprecate / add instructions (within practical reason). Further, they encorporated more registers..
The Unreal xxx (don't remember which flavor) game was recompiled for the x86-64 and achieved a 15% performance boost, but even they admited that most of this was due to the extra registers.. Note, explicit register-count augmentation is now like a 20 year old concept (see RISC).
And just to further the point, the AMD Hammer encorporates a memory controller which is bound to provide a few percentage point boosts.
The real pratical benifit of 64bit requires a 64bit native OS.. Namely the API calls to and from the OS should allow full 64bit ints by default.. Failing to do so requires clunky code which splits the address space into gig-sized segments. I'm specifically thinking of Linux >4Gig file access as an example.. To randomly access such a file, you first specify the page-number, then a relative position within that page.. That's extra required calculations.. Which was the whole thing avoided by going 64bit.
Yes we're starting to see more and more true-64bit API elements, but the vast majority of library code still assumes 32bit limitations. (think tar,gzip when not using stream-modes).
Slashdot Mirror
They had likely-cost per card as well (if you'd read the article). The previous poster was saying that Tom one-upped the simple price point.
In fact, I was checking pricewatch and his numbers are pretty much on the mark - you could find cheaper no-names, or more expensive top-tier name-brands.
Most casual/avid gamers are very interested in price-performance (e.g. value), so this new metric is very useful. Of course, we gamers had long been able to assess this comparative "value" metric heuristically.
One final point, he provides two price-performance metrics, "raw performance/$", and "graphics-quality performance/$". I often switch back and forth between the two modes.. When I'm just casually playing I like the quality settings to be on high. But when I'm playing against other people (and every FPS counts), I switch to the performant settings.
Personally I like setting limits like $100. This in fact use to be the sweet-spot for price-perf. Unfortunately graphics card manufacturers are REALLY trying to raise the bar.. Currently it looks like $150 is the new price-perf region, and all reviews are sitting in the $200<->$300 range (with sub $200 cards occasionally getting spot-light)
Anymore, the vid-card, sound-card and high-perf ethernets are the only things I care about. MB + CPU + Mem + Case become an old Linux machine / firewall / vncserver (for aim).
Considering that the average MB+CPU is only $200, this isn't a bad deal.
IANAL
Not withstanding the other poster's comments (which I don't think would stand up in court.. phone companies are regulated and thereby recognized. End users are not).
This is one of my biggest concerns; cover your own ass. Thus I recommend if using such a network to apply filters (you should be able to hack the source if this doesn't already happen). If you receive a broadcast discovery packet for some filtered-out info, just drop the request; don't pass it along.
It's sort of a free-rider system.. I'll happily make requests to peers for any data, but I wont pass along requests for most forms of data.. To be safe, you'd have to limit yourself to things like non mp3, etc.
If there are specific legitimate files that are being thwarted by the system, then a manual override of the trust-tree can be accomplished (allowing a specific matching rule to pass). Since this requires human interaction, this can be very innefficient, but ultimately through refinement (and abuse) it would produce a legitimate network; out of fear.. But many would say, "it's not likely that my friends have gotten caught", so many would still participate fully.. It would be something akin to speeding.. Many speed, many do not, and most go back and forth between the two.
Not sure, but there was a discovery channel special on the prospects of building a super-bridge across that channel (obviously a scrapped idea by now). In the design specs, they referred to VERY deep portions of the channel. Sorry that I don't have more specifics, but this is definitely an undertaking if there ever was one.
My biggest fear for things like this are war-time. How easily could rivalry bring terrorists to blow the tunnels.
I find that open source is not so valueable in that people inspect my code and provide feedback. Instead I find the following realizable benifits:
A) I can build apon other people's code.. It's effectively stealing their ideas, BUT since I'm GPLing my code as well, there is no net loss, and they are free to resteal my ideas back (if they are so inclined). I do often refer original authors to my new code.
B) I recognize that people MIGHT secretly build apon my code, so I get a warm fuzzy.
C) I can fix problems with open source drivers (postgres jdbc driver, GNU file-utils, etc. are some of my examples). Moreover, my debugger can jump straight to the line of maliscious code.
D) When I am about to release code publicly, I feel self conscious, and thus I put a TREMENDOUS amount of effort into cleaning up the code.. Making sure various platforms work, making sure there is no embarrasing spagetti-code, etc. Thus the mere possibility of people reading my code causes me to exert effort that I wouldn't otherwise. The end positive is a lower propensity for bugs, AND more modular/reusable code (especially with anything in perl).
The end-end result is therefore that Open source facilitates greater code reuse; less re-inventing of the wheel.. And more importantly code extensibility.
Now this begs a question of the distinction between modules and out-right applications. Open source is great for producing millions of reusable modules, but we often get chastized about the availibility of abundant QUALITY applications. Well, in my view, the merging of these two is two fold:
A) Open source applications tend to be more "plugagable"
B) Commercial sites will often pay developers to use open source modules and customize them to the particular needs of the corporation.. In doing so, serious feedback is provided to the various open source projects (because it is in their mutual interest to refine the modules). I as part of such a corp, have contributed (in various small ways) to several open source projects on the corp's dime, and with full authorization. This is of course, a completely unreliable source of income for a project, of course, but it is definitely a facilitator.
I like in the movie "Bueatiful Mind" where John Nash conflicts with this mentor on a colleague recieves the distinguishing honor of the pens. John said that he saw "recognition", while his mentor said that he saw "achievement".
What this book is measuring is recognition; primiarly because it was easier to measure. By this metric, women should still maintain very low scores. True achievement measurement would have to complexly associate the utility of life before and after a contribution. Since we can't really poll peoples' life-styles thousands of years ago.
I don't know what point you are trying to make about blowing up stars.
You can't synthesize fuel indefinitely in breeder reactors. That's the idealized perpetual motion machine (keep itself going forever and extract energy from it in the process with no additional input). So if you produce enough [breeder] reactors world-wide, you will eventually deplete the world's supply of this already rare material in no time at all. While the reactors may last for some time with the fuel you give them, that time is most certainly finite.
The only reason that nuclear generated electricity is not cheap and plentiful is because of artificial constraints on the market.
Nuclear power is cheaper, cleaner, and safer than the alternatives.
I liken nuclear-power being safer than ? to the misleading comment that air-travel is statistically safer than driving. If you include that most car-drivers are morons, and few pilots are morons, then I might agree.
Take this little factoid.. Statistically, the concord jet was the safest method of travel of all types of travel ever experienced.. Why? Because there were zero accidents.. And zero / {small-number} ~ zero accidents / unit. Then when the concord DID eventually crash, it became the least safe airplane in the world. (Because the DC-10, with it's bad record, had MANY MANY total flights). Since 1 / {small number} compared to {small number} / {very large number} happened to not work in the concords favor (heard this on NPR; don't know the actual numbers).
I would believe the statistic of air-planes being safer than driving a car if there were as many flights are cars driven on a daily basis. "not a fair comparison" you might say? Well, I suggest that it is the volume across such a diversity that is the problem, and that if you are as skillfull as a pilot, then you'll be as safe as an airplane while driving; if not more. Note that it's less the skill and more the ability to concentrate while performing a life-threatening task (as opposed to fiddling with the radio/make-up/conversations/etc).
Likewise, look at the number of nuclear reactors in the world.. Now look at the number of dams. How many dams have failed; killing hundreds/thousands of people? Maybe a couple a long time ago, but I haven't heard of any recently. Moreover, I haven't even heard of dam-scares (though I'd probably be more scared living beneath a dam, than living near a reactor).
Alterantively, look at coal-fired plants.. How often does its boiler room risk the lives of neighboring town/ countries? Sure there is long-term damage done by coal-plants, but the same is the case for nuclear reactors.. spent-fuel leaks, improper disposal, neighboring land of both the plant and disposal site being un-inhabitable.
As for the cost.. I don't know where you're getting that nuclear power is cheaper. For countries that wish to be self-sufficient, and are willing to accept the ENORMOUS cost of waste disposal, it might be over-all a better solution.
The reason it's so expensive in America is not that it's held back, but that we are very concerned with safety both before, during and after usage. Skepticism is a good thing, in my opinion.
Perhaps there are some other reasons I'm not aware of for America's expensive nuclear reactors.. But this is the first time I'm hearing someone suggest Nuclear is, in fact, cheaper.
I'm fine with nuclear personally. And I wish we'd ramp up investment dollars to develop more modern / efficient reactors. I'm just not convinced that nuclear is the panacea that you're making it out to be.
There is plenty of energy to go around, just look at the sun!
But energy isn't the problem.. Power is the problem.. Power is energy consumed per unit of time.
For example, We have a thousand watt micro-wave, but our electric bill is in "kilo-watt-hours". If we divide the electric bill by the fractional number of hours we used the microwave, we'd see how much power the microwave consumed on average (which should be near 1,000 watts).
Look at how we cooked food several hundred years ago. It was by wood-fire or coal-fire. Thus a single tree could feed a family for quite a while. Now we use a microwave for 10 minutes per family member (or an oven for half an hour).. So let's say it's a kilowatt-hour of energy. Solar-cells which are (lets say) 25% efficient, and only produce a couple watts of energy over a decent period of time (don't have numbers in front of me), mean that the raw energy from the sun is not enough to feed our current appetite.
The sun IS enough to feed us.. We could use a magnifier and focus it on our raw food for only a few minutes and heat it up nicely. But it's not convinient.. Thus the "convinence" is what drives us to use more powerful mechanisms.. And thus require larger amounts of energy than we really need.
Look at a 3 cylinder geo metro.. Or a 1975 volkswagon desel. They have hardly any horse power. But consume their energy slower and more efficiently.. Likewise, coal-burning steam engines have very little power.. But use weaker wood/coal fuels. (Where a wood burner only uses a couple years-old-tree worth of sun-shine).
Driving 45 is a near optimum speed for most vehicles.. It can use a high enough gearing that allows "some" acceleration, and isn't at a speed that allows rolling resistance / air-resistance to dramatically affect efficiency... Driving any speed faster than 45 mph has a dramatic effect on fuel efficiency..
And aside from the highways, 45mph is the speed limit... Yet, we drive 80/90 mph all the time.. This can drop our milage almost in half.. Moreoever, in a traffic jam, we "floor-it" to prevent people from cutting us off.. This requires an enormous amount of power (even though it's only over a short period of it). Why? The bursts of speed don't even get us there any faster.. It's the social issue not wanting to be taken advantage of (being constantly cut off).
Likewise, we get gas guzzling vehicles today, not because they go any faster, and often not even because they accelerate faster. But because we are competative.
Likewise, for a short while, people took the concord instead of more efficient, cheaper, more luxurious flights. On the outset you might say because it is faster. But in reality, an air-port's wait-time is comparable to it's flight-time. What's 3 hours saved if you have a random possibility of getting a 2 hour delay. Sure the concord's price meant short lines, but that too is part of the point (socio-devisions of energy-consumption).
Given the rise of electic-ovens, then microwaves, then air-conditioners, then computer/home-entertainment-centers. I feel it's highly likely that we'll invent more power-hungry "normal-use" items.
Imagine the discovery of teleportation.. Lets assume that it consumes mega or giga watts of power. How useful would this be? And therefore, how much power would it consume? You think our current spending habbits are bad?
Now, about the sun having enough energy. Just look at the enormous amounts of power we achieve from solar cells.. This is a direct realization of the energy ebbing through our solar system.. You might scoff and say our solar cells are currently too innefficient.. But we're talking about 25% efficient cells... We can only get 4 times better.
How about large mirror-array power plants? Well, if you look they are enormous in scale. And they still take time to boil their target water.
How about our fossil fuels? Well, they took millions of acres of space and compressed them over dozens
Unless the environmentatlists let us start building nuclear powerplants again.
How does this solve the problem? Now you exchange the abundant low-energy organic fuel for scarse high-power solar(nova)-generated fuel.
We can always burry a couple continents worth of trees.. Can't exactly detonate a star yet.
I think the answer is in more efficient consumption, and more efficient energy-extraction. We're always going to find ever more power-hungry uses of fuel, so simply expanding our extraction of a particular rare resources isn't much progress.
Thanks to economics/capitalism, what's going to happen is that people will extract from what-ever resource is cheapest.. Until that resource becomes more expensive than competitors (natural gas, renuable, nuclear, etc). Each competator in turn will be depleated until the next most expensive option can compete..
This goes on until it's cheaper to research alternate/exotic forms of energy.. All along the way, each consumer experiences higher prices and thus is inclined to be more conscientious about their consumption habbits. Right now fuel/electricity/heating are the cheapest elements of our life-styles. It's what's enabling us to grow in socio-technological respects. But as we start to struggle to maintain our life-styles; we'll find the motivation..
In summary; there are no cheap/easy solutions our fuel/pollution problems.
Well, I agree, but you're making the wrong impression. x86-64 and the G5 BOTH utilize 32bit instructions; they merely add on new instructions. So their ability to run 32bit code is paramount.. Plus not every part of every program needs 32bitness (for same reason why we still have 8bit instructions (e.g. character manipulation) or 16bit instructions (wanting integer modulation)).
Also, there are proven benchmarks that show that the opteron indeed runs faster, though due to the many differences between the opteron and the K7/P4, it's hard to narrow down exactly where the performance increase derives. The key feature, as stated is the doubling of the number of registers... The x86 has NEVER been able to perform register optimizations (like loop unrolling, etc) because there just arn't enough registers for even trivial book-keeping operations. The only way of really speeding up such apps is to have smart CPU's which rename explicit registers into remappable internal registers while instructions are running in parallel.. It's very hard however (and EXTREMELY cpu-specific) to have the compiler write code that can take advantage of this.
So having more regs means at least all the book-keeping can be explicitly stated by the compiler, and MANY explicit memory load/stores can be avoided (including CISC: add [mem], [mem], [mem] operations).
BUT, here's the misleading part.. The G5 has been RISC for a LONG time.. And one of the key tenents is 32+ registers. So while the x86-64 nicely ups the anti to a whopping 16 registers, don't get too excited, we're still living in the dark ages.
The main reason is that we're still doing register renaming, so to have 32 explicitly named regs you'd have to have nearly a thousand renamable registers.. This means slower addressing time (more propagation levels for a greater power-of two number of addressable registers). Is this additional cost warrented? The alternative is removing the power of the existing renaming facility, which may hurt more than help. So, given that CISC operations can still efficiently use memory addresses as virtual registers (e.g. the CPU keeps them in high-speed caches), it's a cheaper / faster over-all solution to just stick with 16 registers.
It still doesn't solve the problem of loop-unrolling however, so I'm not particularly happy with the decision (Being a compiler whore myself). AMD's not going to get another opportunity to radically alter the x86 line.. Intel is going to do this next and AMD will have to play catch up again.. And it's possible that the x86 won't last another major iteration (e.g. x86-64-AI?)
Don't underestimate the advantage Apple has in setup & maintenance due to the fact that it builds the hardware AND the software together.
How often do you get custom server application software (that you wrote) pre-installed on a server? Ok, rhetoric question.. How about, how often do you accept factory-defauls of hardware? A friend of mine that kept OS X on his recent mac still spent weeks finding / installing OS X varients of Linux software to enhance productivity / work with our product cycle.
Ok, so lets say you're seasoned and you've got this down to a science. Then what about patches? Upgrades? cluster configuration?
Well, since we're talkign about clusters it's highly likely that a single machine will be set up and a CD will be made to batch install/configure/boot the machine (boot in the case of disk-less machines which requires zero per machine maintanance). This batching process is trivial compared to the time it'll take to physically mount all the machines, so the difference in "maintanance" of two differing pre-built machines styles is largely irrelevant for said clusters.
So now we're back down to power requirements, physical space requirements, per-machine costs, and per-machine performance.
And for those claiming that G5's perform faster than P4's, I'm not convinced that "gcc compiled" custom cluster apps running at either 3.2GHZ with hyper-threading (gack, I mean CPU-threading), or AMD's quad proc'd opterons can't outpace the G5s. While the G5 is RISC and has fewer stages than a P4, it doesn't have the clock speed of the raw integer pipe (running at 6.4GHZ if I'm not mistaken). When it comes down to it, P4's / Xeons are faster than opterons, and in many cases faster than G5s. But you need to see the particularly compiled apps to really know which platform is going to run quicker. And my bet is that the opteron/G5 running a full GHZ slower than P4's isn't going to offer tremendous additional overall value.
Too bad the Itanium isn't catching on (and thereby getting economies of scale discounts); it's really a bargain when you get into $5k+ machines (which we're talking here).
-Michael
Actually linus implemented clone() instead. Please learn.
POSIX is an API. When we say "UNIX" we generally refer to the POSIX API. An API's whole point is to abstract the particulars of an implementation. For example, Perl actually implements fork on windows through the use of independent interpreters runing in a threaded environment. Java, also is an API which facilitates things like graphics and asynchronous file access (strangely similar to UNIX IO selection btw).
To say that GNU's Not Unix with a straight face is to miss the point.
Likewise is to differentiate the implementation details of clone v.s. the front-end API "fork". "clone" is only significant because it allows the kernel to have a single entry point to handle process creation; both threading and forking, differentiated only by a memory mapping flag. Is it any less significant that some primitive implementations of POSIX concepts delegate inter-process pipes as physical temporary files?
Granted lack of full POSIX compliance exists in things such as signal delivery to threads. But it's rare to find a fully POSIX complaint OS.
Remeber in 1984 how it was somebody's job to go back and modify all public records of an old "inconvinient" fact. Just imagine being able to control dictionary.com / cnn and a few other heavily hit sites. You'll be able to remove any record that something existed.
I am not suggesting we would see a WW2 type atrocity happening in America.
I'll one further your general argument by disagreeing with this line.
Though somewhat of a rambler, "Gore Vidal" has written interesting books on the imperialistic nature of the United states. "perpetual war for perpetual peace", for example, supposedly lists hundreds of "mini wars" that most American's aren't even aware of.
WW2 was an issue because germany wanted to extend it's influence on neighboring countries. The only difference between the US and that is the size of the countries we "enforce control over". It's essentially 1700's imperialism all over again. We sophisticated Americans bringing "third world countries" (a more PC version of the old phrase "savages") back into alignment... Read: "You're either helping us prosper, or you're our competition".
The sick irony is that this is exactly what we accused communist countries of doing throughout the cold war.. "We must fight this slightly immoral war, for fear that communism MIGHT spread"; pre-emptive killing being the letter of the day.
It's only in high profile cases such as Iraq that any Americans ever care. Other countries (especially those affected by our policies) have been crying fowl about this for decades.
Unfortunately I can't imagine any way of preventing this.. "absolute power corrupts absolutely". Even if we were to "shake things up" on capitol hill, the successors would faced with the daunting task of "giving up political influence". Would you be willing to give up your biggest bargaining chips merely for a good cause? Would you cast the ring into mount doom?
The best I can figure is one of my favorite phrases, "A little revolution every now and again..." - Thomas Jefferson
Itanium / x86 instructions sets are ALREADY merged. That was the whole point (originally).. There is a "jump-to-x86-instruction" itanium op-code which allows you to run "legacy" subroutines/libraries. The original Itanium simply emulated x86 instructions though (poorly at that).
So what you're really suggesting is to take a Pentium 4 core, and "emulate" IA-64, via a "jump-to-ia64-instruction".
This is a highly non-trivial task, because IA-64 has COMPLETELY different assumptions about hardware resources (128 regs of both int/fp), as well as rotating registers (a la sparc), which means more than 1k total registers (all 64bits). While many of the registers can be reused as castrated x86 register-renameables, it's not likely to be possible to optimize register access for BOTH reg-renaming and direct reg-access.
Intel had the option of trying to optimize x86-32 for upcoming itaniums, but last I heard, they were merely going to throw a P4 onto the motherboard to run legacy apps (a la co-processors).
Frankly, I think that's the correct solution; they should have worked co-processor instructions into IA-64 from the beginning. At the prices of these systems, heterogenousness isn't going to be a major additional factor.
That being said, I don't see a viable Itanium -> x86 merge.
Electro-statics implies non time-varying electric behavior. This involves the full collection of time-varying electric and thereby magnetic interactions. Which are too complex to even model for individual atoms. To give you an idea of the complexity. Imagine the gravitational field of 3 massive bodies. Knowing their mass is not enough; you must also know their initial velocities. Even then, you pretty much have to solve the system numerically with a particular margin of error.
The problem grows unbounded as you add more massive bodies into the system.
Now imagine an entire nucleus of such rotating relatively-similar massive bodies, surrounded by electric satilites which are massive enough to affect trajectories.
Oh well
As far as I understand, mozilla has
/usr/bin files, etc)
A) a tremendous set of abstraction layers
B) A javascript Virtual Machine.
VM's mean lazy garbage collection which means a HUGE heap.
For me (on Linux), mozilla takes up roughly 100M, swaps 230M and shares about 12M. That 12M shared suggests a lot of the shared libraries, which each will want a decent sized chunk of writable memory (which can be swapped if not in use).
In fact you DON'T want mozilla to always stay in memory, since much of that shared library stuff is never going to be used (for the reasons discussed in this thread). The only problem is that Virtual Memory pagers will discard read-only pages before dirty pages, so if you leave mozilla running for some time, then it's very likely that some critical "core" executable code won't be there. The problem is exacerbated by the VirtualMachine which is constantly loading and dirtying pages for the purposes of garbage collection. The OS will try and evenly distribute available pages between actively running programs.. So if mozilla is consuming 50% of your available non-cached/buffered memory, then if four other apps are competing for the same memory, non-dirty least-recently-used mozilla pages will be invalidated (and require subsequent reloading from disk).
So the only way to avoid swapping / invalidating-r/o-pages is to have enough memory to
A) Allow all running apps to run (evident by having > 10Meg free, since 6Meg and less cause conservative page-flushing)
B) Making sure that all your normally used files can be fully cached into memory (add size of your normally accessed mail-boxes, your full database+journal, you common
C) There is plenty of room left to build to like 100Meg of buffers.
We're talking at least half a gig of memory so that you can run a 100Meg app like mozilla.
I have hardly any experience with light or worse chromatic computation; only what I've read on slashdot really. But two challenges immediately occur to me.
1) Injecting multiple colors down the same fiber (wave-guide) at the same time will not allow all the colors to appear at the other end at the same time. There are non-linear impedences (attentuations and phase-shifts). So we're trading regions of stability and noise-rejection with the technological challenge of working with synchronizing multiple signals. It's actually the same problem as SCSI/IDE ribbons.. Manufacturers are going to serial buses to avoid this exact problem. But the serial bus is only a transport; not part of the computation.. So I don't know how well this problem maps into the low-level computation.
2) There is the problem of processing in a purely chromatic space.. I've read rumors that various company's have achieved 100% light-based computation (especially useful in networking, to avoid transcieving the data). I'm not aware if their computation is monochromatic or not. I would agree, if this were indeed possible, then it would be remarkable. But again, I must bring up the plausibility of making a pure-light based system denser than a binary electric one. Just as with electric, unless you achieve a digit density of no less than $numDigVals or so times weaker, you're not gaining much. (though in the case of light computation, there is the possibility of faster computation or less power consumption / heat dessipation). And, again, I definitely acknowledge light-based computation has been extremely useful in communications, where latency is removed by not having to convert back and forth to electric at each repeater/router. But I push this into the fringe of specialization, just like electric modems.
You interpret his comment incorrectly. To say that a capitalist takes no venture not prone to benifit is a far cry from meaning that businesses need garunteed returns on investment. It is more tau-istic, than anything; a pessimistic view that in any apparent good deed a corporation does, they have an ulterior profit-minded motive.
Take NPR (National Public Radio), companys make grand donations all the time. Isn't that altruistic? Is that great for the public good? Well, I only know this fact because I hear the advertisments that acknowledge these grants to the individual companys.. Oh, and I get to hear the company's tag-line right after hearing about their generous donation.
Ok, so this is merely a thinly disguised commercial, and they're paying for it as they would a non "grant-based" commercial. What's the point? The point is that you could interpret this pessimisticly as corporations trying to subdue a class of audience (those that think they're not having to listen to commericals). Subdue? Yes, commercials are not meant to "get the message out"; to let people know that a service exists, but to indoctrinate various slogans into peoples head through repetition. "I need a light bulb". "Oh yeah, G.E., we bring good things to lite".. They must make better light bulbs than westing house (or who-ever else non-pathmark brand makes lightbulbs.. see it already works).
Now, it's possible that some company's make anonymous grants to NPR, and thus can't attain such commercial dredgery. And we'll even neglect the tax benifit. We'll even neglect the fact that stock holders might demand that the otherwise undonated money should be distributed to share-holders. Incidently, how could this simple common sence act be considered bad? They're share-holders, don't they have a right to collect on profits if they wish? How could this be interpreted pessimisticly? Well, just take a look at current stock-scandles. American Corporations have written the book on how to manipulate their own stocks. If you allow for a greater than average dividend or profit realization one year, then you've set expectations for subsequent years. Exceeding expectations gives you very little beneifit.. Maybe a few temporary points higher stock. But woe is the company that misses a projection by even a fraction of a point. Better pretend that we had a bad year (by donating some of the excess), then to risk not doing as well later.
The previous poster's comment was merely a reflection that MS is a modern industrous company who is very evidently willing and able to use every dirty trick in the book.. Hell, they invented a whole new generation of dirty tricks.
Does this mean company's are bad? Absolutely not. Does it mean we should give them an inch.. Hell no!! Fight the bastards every step of the way.
This current IM debackle means competition to AIM. That means squelching Open Source environment's use of instant messanging to our non-geek peers. Whether they care about hurting open source instant messenging is frankly irrelevent.. This WILL be the effect of their actions.
Hence, making such transistors would allow chip makers to make huge strides in speed without having to handle the engineering problem of packing in more transistors.
No, they'd just trade the engineering problem of packing more bits into once space with finding ways of unambiguously interpreting a value.
See the whole power of binary (pardon the pun) has always been it's wonderful noise-suppression ability. Imagine a copper wire running 2 miles with either a 5V or a 0V signal on it. You can apply a simple analog device (say a BJT transistor amplifier) that utilizes an exponential function switching at some precisely known voltage (we'll call it 2.5Volts). Voltages before and beneath this voltage are amplified to either zero or 5V exponentially, such that only voltages within a small delta of the threshold voltage have any ambiguity.
Thus you can determine the likelyhood of noise on a line, then put digital amplifiers every so often such that no amount of noise will be sufficient to raise or lower the voltage to the ambiguous region.
The same is true even on micro-scopic wires; Fanning transistor outputs out to too many transistor inputs introduces noise on the wire. CPU's not surprisingly utilize "buffers" which are trivial 2 transistor logic gates which pass the output to the input. This cleans the signal just as the higher-powered digital amplifiers do.
While I'm not sure which particular technologies are being considered in this trinary/quatrinary logic system, if it is nothing more than a sub-division of voltages, then it's doomed to failure for general processing, and possibly even simple memory storage. First of all, you introduce another whole region of voltage ambiguity. The only way to maintain your safety zone is to up the voltage or provide more amplification stages to garuntee a cleaner signal. But the trend has been to decrease, not increase voltages (lower power consumption, smaller devices, whatever), and adding additional logical devices merely to interpret a signal means that your bit-density is going to suffer.. Exactly impeeding it's whole point.
Likewise for denser bit-storage, since the probability of bit-error necessarily increases (all else being equal), then you're not as likely to achieve as small or as dense a physical digit. So unless you can at least achieve less than 1.5x logical-digit spacial expansion (due to error-compensating material), you haven't gained anything by going to a trinary system.
Lastly, the concept of >2 digit computing already has a particular niche where it's trade-offs are acceptible.. Think of 56k modems which encorporate dozens of thousands of "values" for a single digit. They utilize a full 256 voltages for each anticipated time-slice. Of course the analog modem can't anticipate the exact sampling point where the analog phone line gets digitized (happening to transition at that point can be bad), and there is usually a tremendous amount of line noise. But what modems wind up having to do is group several time-slices together and produce a macro-digit with a but-load of error-correcting pad-values. And that's not even enough; the entire packet is still likely to have misrepresented digits, so CRCing and thereby retransmission is often necessary.
All this effort is worth it because we physically realize extra bandwidth.. But such a "probabalistic" solution (prone to bit-error) is unacceptable at the lowest level of computation. You can't get any less error prone than binary (given the above discussion), and mathmeticians have shown that base-e (2.717) is the optimal number to balance complexity of the number of combinations with the number of digits in a given number. (analogously demonstrated by considering an automated phone system where you have to wait to hear 10 possible choices per menu (the base-10), and you have to go through k menu levels to achieve what you want. The metric is the average wait-time using different bases, and mathmatically the shortest wait time was the
Well, Athlons typically want 350W.
There were 128 machines.
Thats 44.8kW
Now take into account at 120V that's 373Amps rms. With all the surge supressors/power-strips, we're talking a serious amount of impedence (fwi, not resistance).
Not to mention, the typical circuit breaker clamps at 20amps. You'd have to have 36 separate circuits in a typical office environment (a circuit usually services several outlets).
To boot, the impedence at such high currents running off the same master power cables could cause serious power level fluxuations; especially at boot time.
Now this is a university; they're likely to have very clean power signals, and possibly each plug runs a seperate voltage-regulated power line. And they definately can sustain high power (look at the cables). But don't expect that sort of power center to run cheaply at your local ISP.
In a fit of coincidence, I've recently tasked out the problem of power distribution, and the solution I came up with was gutted DC AVR'd UPS's (with the DC->AC component gutted) that directly connect to the motherboard; bypassing the switching powersupply and any external drives. Given enough external cooling, you could even resort to passive heat-sinks (albeit large/copper/expensive). You could probably get the power dessipation down to 100W (75W for cpu, 25W for MB+passive periferals). It might be cheaper to get ahold of laptop style power batteries, but I don't know of an easy way of getting them off-the-shelf without just buying laptops outright (more expensive proposition)
The battery-operated systems gives you two things.. Lower total power dessipation, and greater power stability under non-uniform loads. Due to the AVR, it's also possible to use very long power cables to stretch across sides of a building (as a short term solution; avoiding rewiring the master power distribution)..
This is why some organizations do not allow their employee's to have root/administrative access to their own machines. Unfortunately even that isn't enough to prevent installing home-directory applications, but typically those are free software anyway.
Couldn't say personally how effective this policy is; I've only ever been on the recieving side of it.
I have seen software crash both Windows and Linux, MySQL has eaten any and all available memory on Linux
/tmp or /var/). Not to mention that root apps get that last 5-15% of disk space all to themselves, and don't even discuss running a service as root anymore (including mail).
Dude, use ulimit. Out of memory is not an excuse on a unix platform. Likewise with forking-to-death or disk space.
mysql, postgres, httpd, etc all have provisions to limit the number of connections and in some instances memory foot-print (postgres). But all of that can be backed by ulimit.
Disk space a problem? Use disk quotas, or simply sym-link to a separate partition to prevent one overzellous application from hogging too much disk space (killing either
The key to UNIX is building apon trusted concepts instead of re-inventing the wheel every 3 years.
I will say in both Linux and MS's defense, however, that making a server robust is a lot easier than making a front-end robust. Servers typically don't require interrupts (disk and network can often be offloaded for most of their activity), and usually don't require any hard-to-protect application-spaces. The services have well defined interfaces which are relatively easy to detect (especially with over-flow exploits).
The trouble is when you're writing interactive applications, or computer-interfacing devices: USB/serial/parallel/video/sound, all with really creative/ambitious drivers that need kernel access. Hell, the fact that a GUI can be hardware accelerated makes this limitation as well. However, using a client-server model allows that the data be kept safe even in the event of a front-tear-down. If you application-space and your GUI space are separate (a la X), then a GUI-lock can still allow a back-end access to gracefully kill the server-applications (word processor, checkbook, code-editors, databases, etc). I love the fact that I can almost ALWAYS go to an mgetty'd text-prompt or ssh in from a remote machine to recover from a GUI crash.. And I almost never lose my data (except in non-persistable data like HTML-forms; mozilla RFC anyone?). X is not necessarily part of the OS; it's just a regular application (barring optional hardware acceleration). Likewise X-apps don't have to crash when X crashes.
This is the model that I'd like to see facilitated, not the COM/DCOM-like CORBA/GNORBA/RMI/KDE-distributed-computing, where each application is dependent on ALL peer applications behaving well. So what if you can embed a spread-sheet in a word processor.. Just freaking directly link to the source code. I don't buy that the benifits of such peer-computing warrent the TREMENDOUS loss of robustness it afford (I run KDE apps under a gnome interface so that WHEN the KDE backend crashes, my GUI is still alive).
It's this complete lack of robust-design principles which have made MS a laughing stock when compared to stability, even though they invest millions/billions(?) of dollars into code-review/quality-control.
That's true for any two chips that run the same architectures; why is it better to have to compile for x86 and MIPS then to compile for x86 and (possibly) x86-64 and have the choice of running the x86 binary on the x86-64?J
If I understand your question well enough, then that's easy. You don't have a choice about compiling different binaries for different "platforms", where a platform is both an OS and a particular piece of hardware. Linux distributions, for example, simply must compile their entire software line for each and every platform they wish to support (with a few source-only distro's as the exception).
When you have a 100% compatible platform, however, the added cost of producing a completely separate distribution with archetectural flags fine tuned to each varient is too high.. To say nothing of the confusion of having 5 or six different boxes on the shelves.. People can barely find the difference between mac and PC logos, to say nothing of a pentium v.s. AMD. Then think of the administrative overhead of having to lug around 3 or 4 sets of Linux distro's to administer the likely diverse computer pool.
Same applys to windows software; while it's not too hard to swap out dlls for the appropriately platform-dependent compiler optimizations, it costs money to do so.
Again if they choose to market to differing platforms, that's a choice that says, "get these additional customers".. When optimizing for compatible varients, what are you gaining? A 5-20% increase in performance and thus a slightly happier person... It's much easier to say "optimized for Pentium 4" (with a stupid audiable logo).
So now back to your statement.. What's so special about x86-64? Why should we bother differentiating it?
Well, in Linux we have to recompile the kernel suite for the 64bit kernel anyway.. So there is a clear need for SOME differentiation.. Moreoever, given that x86-64 owners are somewhat sophisticated, packaging isnt necessary; only downloads.. Thus the cost is merely reduced to setting up the configuration and building the ISO and allocating disk space on the mirrors.
Of course I say all of this as a lay person's speculation.
Ugh. 64bit != faster
In fact there is no imperical evidence that any 64bit implementation is faster at doing <=32bit calculations.
What 64bit means is a radical archetectural shift, which affords (both to compiler writers and to the CPU designer's management) an excuse to add other radically new technology that is independent of bit-depth. Namely, we're spending the money, might as well pack-the-punch.
AMD64, for example uses a new CPU-mode which gives them cart-blanche ability to deprecate / add instructions (within practical reason). Further, they encorporated more registers..
The Unreal xxx (don't remember which flavor) game was recompiled for the x86-64 and achieved a 15% performance boost, but even they admited that most of this was due to the extra registers.. Note, explicit register-count augmentation is now like a 20 year old concept (see RISC).
And just to further the point, the AMD Hammer encorporates a memory controller which is bound to provide a few percentage point boosts.
The real pratical benifit of 64bit requires a 64bit native OS.. Namely the API calls to and from the OS should allow full 64bit ints by default.. Failing to do so requires clunky code which splits the address space into gig-sized segments. I'm specifically thinking of Linux >4Gig file access as an example.. To randomly access such a file, you first specify the page-number, then a relative position within that page.. That's extra required calculations.. Which was the whole thing avoided by going 64bit.
Yes we're starting to see more and more true-64bit API elements, but the vast majority of library code still assumes 32bit limitations. (think tar,gzip when not using stream-modes).