This is a Karma Whore...we all know where to link to...
Clearly we don't, or the article would have had the partners link. You are right, whover posts the link first gets a karma bonus, but they are getting it for sharing useful information.
Every bit as useful as the guy who posted the link to the Nature story on the same thing. After all we all know how to search the web don't we? I mean really, if it is a science issue, then we all know it'll be in New Scientest, Nature, the University's web site, and the like. Anyone who posts thos links is just Karma Whoreing too.
Just in case anyone whats to know what "way more" per month gets...
Crappy install. That's right. Install costs a whole lot of moeny (they bury a new cable), and it still sucks. It took Bell Atlantic a few months the first time, and two trips (once to bury the cable, once for a guy to attatch a Smart Jack) the first time. The second time it took somewhat less long for the first visit, but then they discovered they "forgot" to dig all the trench they needed, so I had the choice of having cable layed over my new neibors lawn, and across my roof, or waiting another few weeks. I choose the wait.
Once I got the service (56K FR the first time, about 5 or 6 years ago, 256K FR about 2 years ago) it has been great. A few outages (less then 2 "real" ones per year so far). Half the time the ISP calls me first (they tend to call within an hour of the outage, and I'm at work a lot, and not using the connection much!). When the outage isn't solved by rebooting the router (a Ascend Pipeline 70 with an old code load), and isn't a known Bell Atlantic trunk issue they will contact Bell Atlantic for me (I have the option of waiting on hold, being confrenced in, or having them call back). Most outages are solved in a few hours (which can seem like l-o-n-g hours if I was palnning on doing something). One took more then 8 hours, and was a big Bell Atlantic T3 problem of some sort.
Regretably this level of service seems just really expensave, and when I leave my current job I'll have to find something a lot less expensave, and most likely less reliable, or maybe just as reliable, but with longer service wiat queues.
However if reliabilty is a big issue, and your employer will pay for the line, you may want to try Frame Relay from one of the bigger ISPs (I would recomend UUNET, but since I work for them, I'm a bit biased). If cost is a big issue, then stick to cable modems or DSL. And hope LMMDS shows up soon, and is better.
the white paper `The technology behind the Crusoe processor' which I cited.
D'oh! Sorry, you labeled it as the offical paper, but somehow I missed thet when looking at where you link went (not to TM, but off elsewhere). Sorry.
eg. about modelling off-chip supporting hardware in software
They say they do it, but the don't really say why (I can guess, and you can guess, but neither of us can know). Maybe I am being too hard on the Spectrum article, but all it gives is hints at why things really happened. Somehow that managed to bitter me on the technical side of the paper.
Readers will get much more out of the Spectrum article after they have digested the information in the two links I gave.
Yes. Or more from those articles after the spectrum article.
Once this architecture (actually, I guess it's a family of architectures from what I've read before) establishes itself, wouldn't code written to run "native" run better?
I expect so. Except it is likely to be pretty painful since there may be seeming arbatary restrictions like "ALU1 and ALU2 may not both have even register numbers as targets in the same clock cycle" because that may have made the hardware modestly better in some way, and not made the code morpher (much) harder to write. It also doesn't have a "real" MMU (I havn't found out what it does have, so I'll guess a hardware TLB, and all software table walks, but who knows). Oh, and the two biggest problems of all:
Transmeta has two diffrent CPU products the TM3120, and the TM5400. The two CPUs have diffrent (internal) instruction sets. The future products are likely to as well, with some of them being extreamly diffrent from each other.
Diffrent steppings of the TMxxxx will have diffrent eratta, and severe eratta compaired to "normal" CPUs because a normal CPU can't be used with some of the bugs the TMxxxx can!
The article even gives a good example of the kind of severe eratta the TM can live with. At 433Mhz-ish the CPU worked fine. At faster speeds it can't execute two particular instructions in the same bundle (it didn't say what they were, so I'll pretend they were "ADD with 32bit immediate; BRANCH ON CARRY to 16bit offset"). That would prevent the shipping of a normal CPU (faster then 433Mhz at least). With the TM the code morpher can be set to avoid issuing those two instructions at the same time if the CPU stepping is known to have that bug, and they can ship a 600Mhz version. The performance loss from having to code "ADD with 32 bit immediate; NOP; BRANCH ON CARRY to 16bit offset; NOP" will be tiny, I would be supprised if it was 3%, esp. since the CM may frequently be able to fill the NOPs with other instructions.
That's not to say all, or many steppings have such bugs, but if they put out new version with a better cache (25% perf boost) and it introduced a bug that could be avoided by taking a 3% hit, they can release. Nobody else can, because they can't be sure all fielded code avoids such bugs! TM can because, and only because there is one and only one application, the Code Morpher.
You may as well assert you could make faster VAX programs if DEC (er, Compaq) opened their Microcode, or the 68020 and Motorola. Your right, you could. But it would be extreamly non-portable, and may severly restrict Transmeta/DEC/Moto from being able to make new CPUs if a signifigant app starts depending on that ability.
There has been a dearth of good technical analyses of the Crusoe available on the web
Have you looked at Transmeta's own pages? They have everything I would think of as "technical" from this article except the bit about being "bug for bug compatable" being the hardest bit (and since the article mangled that by defining it as getting the BSOD at the same place rather then tracking Intel's bugs so software dependent on them don't BSOD/segv I'm not giving any credit!). Oh, and the article also gives slightly more detail on what early Si bugs were worked around in software.
The Transmeta page will show you the code sequence the article used, and explain how it is derived, and how fast it is, along with a few others.
What I will say for the article is it did a good job explaining the nontechnical parts. It was intresting what it took to get the VCs rolling. What the work enviroment is like. How psyced the hardware folks are to get to do a brand new CPU every time.
Good article, worth the read. But not for the tech info.
Part of the reason is technological; a troy ounce of gold is, was, and forever shall be the same thing; same goes for a bushel of wheat or most other commodities. But memory technology is changing very fast; a 1 meg SIMM might have looked like a really good benchmark at one time, but certainly not now. In that sense, RAM is a very strange commodity
I can see how this would make for a lot of diffrent futures symbols, but not that it is an impossable obsticle. Of corse I would pay a diffrent ammount for PC133 64MBit 7-1-1-1 Jan2001 options then i would for DDR PC200 128Mbit 12-1-1-1 Jan2001 options. And of corse I probbably wouldn't pay much at all for any 2004 options as I think we'll be off to a new technology. but I think the diffrences are easally quantifyed, and most of the boilerplate (delevered to X, loose parts/finished sticks, acceptable defect rate, transaction rules) can remian the same. After all a share of WCOM now is vastly diffrent from a share of WCOM four years ago, yet it is traded on CBOE. A share of UUNT is no longer available, but it was once traded on the CBOE. There is a chance that AWE shares will be swollowd back into T shares, yet they trade on the CBOE.
I'm with you on the other oddamints. I hadn't thought of them. Well with the possable execption of large consumers. I would think this would help them even more. Then again it would also help the small consumers a whole lot, which the large ones might not like. I think most of all that like wheat futures, DRAM futures would help DRAM producers.
Bus width has nothing to do with latency - think about it.
You are right that a narrow bus width doesn't cause high latency in and of itself. And right that it isn't the source of RDRAMs latency. But it doesn't have nothing to do with latency.
If you have an identical 16 and 32 bit bus, and you want to fetch a 128 bit cache line from 32 bit address X, the 16 bit bus has to take two clocks to transmit address X, and 8 more to transmit the data, or 10 clocks. The 32 bit bus needs only one cycle to transmit the address, and 4 more for the data, total of 5 clocks, half the time of hte 16bit bus. As you said "Latency is the amount of time it takes from the issue of a memory read until it answers." (I would count time to issue the read as well).
The latency in RAMBUS (which I'll freely admit I don't know the numbers for) probably has a lot more to do with all of the transactions and shit that RAMBUS does.
RDRAM transaction overhead is resonably competitave with EDO RAM RAS and CAS timings (RDRAM takes 4 clocks at 400Mhz to 800Mhz to start a transaction EDO takes two but at a much lower speed, SDRAM I think also only takes two, but with DDR SDRAM it could be 2 clocks at 266Mhz, which is almost as fast as 600Mhz RDRAM).
The thing that kills RDRAM seems to be the time it takes the motherboard chipset to set up the transaction, the low number the motherboard chipset keeps actiave (each RDRAM can usefully service transactions from 2 sense banks), and most importnat of all, the time the RDRAM itself takes to light up a sesne bank.
With 7-1-1-1 PC100 SDRAM it takes 7 clocks at 100Mhz (70ns?) to read the first 64 bits back from the SDRAM. Allways. No matter what 64bits you want. Then one clock (10ns) for the following 3 64bit words (I think bursts can be longer, but I don't know of any PC chipset that does long bursts).
With 800Mhz RDRAM it takes 4 800Mhz cycles (~6ns? about 10x PC100) to start the transaction. Then if the data is in one of the RDRAMs two sense amps the data comes back 16bits per cycle (a little under 4ns per 64 bit word - about 2x the speed of PC100). However if the data is not in one of the sense amps, the data that is in the amp will be written back (if it has been modifyed), and then that bank will be lit up. This can take a whole lot longer then PC100's 70ns. A whole whole lot longer. Like 400ns. If you have lots o hits in the same sense amp (like you would on a very small, or no cache machine) you get lots more speed form RDRAM. If you get few hits on the sense amp, you suck. Hard.
Regretably that 400ns number is old (as is my SDRAM timings). I don;t know if the newer RDRAM has improved things, or has more sense amps, or a hidden write back. I know that DDR SDRAM comes much closer to RDRAMs peak timings, and that DDR SDRAM can get those numbers consitantly, while RDRAM needs a "good" access pattern otherwise it's throughput falls to a few percent of peak.
The nice thing is that you can overlap (well, I hope) them to hide some of it.
I donno if you can overlap transactions to the same RDRAM chip (I think you can), but you can overlap them between RDRAMs. Of corse that requires either a CPU that can do multiple outstanding memory references, or multiple CPUs (or other sources of memory traffic). You could allways interleve, but that seems kind of pointless given the high bandwidth once the sense amp is lit!
That doesn't mean that RAMBUS doesn't suck, but make sure you don't bash it for the wrong reasons.
Total agreement. RDRAM is cool, but it just doesn't solve a problem most people have.
Uhh, correct me if I'm wrong, but if you have N64 games, don't you already have an N64?
I, like many others, have limited space under the TV. It is cramed full of things, a DVD player, AC-3/DTS decoder, satalite reciever, VCR, and game machine. I like many others have a signifigant other who likes a nice looking room more then a nifty new game machine. I like having a (happy) signifigant other much more then having a new game machine, not to mention an OLD game machine.
So I got rid of the PlayStation (really I put it in a box in the basement) when I got my DreamCast.
I'll bet a lot of people with N64s would like to have a Dolphin, and not have to box up their N64. Of corse I would like to have a PSX2 and not have to box up my DreamCast too. We don't all get what we want.
Plus I would figure it is a minor, but positave, selling point to have an established set of games, even if many arn't so hot, and even if none push the machine.
And back to the main point, RAMBUS is good memory technology for systems that can tolarate fairly high latencey, and need a whole lot of bandwidth for cheep. The "for cheep" part is important, if you have to pay too much for RAMBUS, you can buy more common RAM technologies, and use a wider bus (note, I'm assuming you are designing a system, this won't work if you went out and bought a motherboard, buying 4 SDRAM sticks won't magically give you 4x the bandwidth if the motherboard and chepset arn't designed to work that way).
The high end technical workstation market has little need of RAMBUS, it can design 512-bit wide paths to memory. Sure they cost a ton of money, but that's a big part of why the $7000 Alpha motherbords cost $7000 (and the total reason you need to buy RAM in 4 stick lots, er, maybe 8). Except for the low end Alpha motherboards which cost $2000 or $3000 because they don't sell enough to earn back the NRE at $120 like PC motherboards.
Note that I say little need, not no need. It looks like the Alpha 21364 has RAMBUS controlers on chip, which Compaq claims reduces latency signifigantly. Hopefully they are right, because I like the Alpha, and it would be unplesent if it started sucking.
RAMBUS isn't a very good technology for PC memory because bandwidth to main memory isn't as big an issue as the latency. It might be good memory for a 3D board's texture storage, since bandwidth matters a lot there. Then again it may not, since new 3D boards store vertex info there, which may be far more latency sensitave.
But RAMBUS makes a decent memory for a game machine designed 5 years ago (N64). There was no SDRAM to chalange RDRAMs bandwidth. In fact RDRAM had competiave latancy then even. The psudo-caching effects of RDRAMs sense banks let a no L2 cache RDRAM system compete well with a mid-size (for the year) L2 cache system with EDO DRAMs. Great choice.
Beats me why the Dolphin is slated to use it. Maybe they didn't beleve in SDRAM? Maybe they know something about RDRAM we don't. Maybe they are on crack. Chances are we'll find out in less then a year.
As far as I can tell cheap DDR SDRAM leaves RDRAM as a solution in search of a problem, but that doens't mean RDRAM was allways a steaming pile. In 1992 (which is when I recall the first RDRAM demo systems) it was really promising, and well ahead of the pack. They just havn't been running fast enough, and now the world of cheap RAM has cought up.
Now, correct me if I'm wrong, but isn't a dime only a few cents? So this isn't like the doubling in price which happened last September.
Yep, next weeks price increse is only ten cents a 1.6% price hike.
The article seems to think the demand will continue (or rise), and that Micron has additonal idle production capacity, but pretty much nobody else does (they could switch back to DRAM from FLASH, if DRAM becomes more profitable then FLASH again, incresing hte price of FLASH of corse).
If it is right then we are in for more price hikes. How many or how much is, of corse, pretyt much unknown. If anyone could tell for sure they could make a huge amount of money from buying and selling futures on RAM. Hmmm, I can't find DRAM futures at CBOE (which has other futures and options), anyone know where they might be?
In other words this is the begining. Possably the begining of nothing. Possably the begining of a huge increse. Probbably merely something in between.
If this technology is not free for free software implemenation, forever, then my advice is to avoid it like the plague.
They (the JPEG2K members) can make it free for free software. They can make it free for comercial software. As far as I can tell, they have been working to make both true. They can not make it free forever. All they can do is make sure none of the member componies persue relivant patent "rights". There is know way they can be sure that some (3rd party) patent out there is relivent. There is even less way to know if some as-of-yet unfiled US patent is relivent.
I hope they do release the technology for free, but even then some care is called for. After all, you definitely don't want to send a JPEG2000 image to a browser that doesn't properly support it. One can only hope that the browser support is better than that for, say PNG.
I do hope they give it a new MIME type, and recomended filesystem extension. If they don't it will be a seriously unplesent transition.
I'll also be extreamly intrested in how long it takes to get adopted vs. how long it has been taking PNG (PNG support still appears to be improving in software, but I have seen few big web sites using it -- not even using any unplesent "IfBrowser" stuff). As far as I can tell JPEG2K has few features over JPEG then PNG did over GIF. I wonder if that will help or hurt. Regretably there are other factors and it will be hard to tell which are more important (PNG has a superset of GIFs still image features, but a subset of it's animation features, that is to say none of them; JPEG2K will have easier integration (assuming someone in the JPEG2K group will do the work) into Mozilla then PNG did into the closed-source Netscape; JPEG2K has comercial backing, PNG was a largely individual effort; JPEG2K is replacing an (effectivly) unencumbered format).
I hope they do release the technology for free, but even then some care is called for. After all, you definitely don't want to send a JPEG2000 image to a browser that doesn't properly support it.
I beleve the reason JPEG2K adopts it as part of the image format is they can store the higest resoultion, and quickly convert that into a lower resoultion (or image subarea). That is a pretty cool feature, I don't know how useful it will be in practice, but it sounds cool.
I want to know what they're going to do to prevent people from making nearly-compatible files.
I don't know what they will do. I expect there are things they can do if they care. There are lots of patents on the algos used for JPEG2K. As far as I can tell holders had to allow free use in JPEG2K to get their algos considered. I doubt they gave up rights for non-JPEG2K uses. Which means legaly they could charge for the non-JPEG2K use. The same may be true for JPEG, you could probbably contact IBM and get them to charge Seattle Filmworks...
So software patents do have a minor good use (a few actually). Still IMHO outweighed by their destructave power.
Rendering at a higher resolution and interpolating down would be the same speed as 3dfx's 4xFSAA.
That need not be the case. If you render the pixel four times and avg there is no need to store those four pixels to memory, and then read them back. Rendering at 2x (four intermediate pixels per one output pixel) you need to write pixel values five times, read them four times, and have memory dedicated to the intermediate image (and not textures, or on card virtex lists).
So if any portion of your performance is limited by memory bandwidth (or availability) on the 3D card, the 3Dfx method will be faster. If not, they should be as you suggested, pretty much the same (all else being equal)
That's not saying that's what actually happens, but it is quite possable.
3dfx's implementation cuts performance quite a bit as well.
Could be.
I find it sort of odd that nVidia's method, as you describe it, does not produce the exact same image. It is essentially the same operation. 3dfx renders the same frame 4 times, with pixel offsets of (0,0), (0,0.5), (0.5,0), and (0.5,0.5). After averaging, that should look the same as just rendering at a higher res and then averaging every 4 pixels into one, right? What am I missing here? Can you point me to a comparison, preferably with screenshots?
Beats me. Either could be taking shortcuts which change the result image. It is also possable, but unlikely that the FSAA actually takes more samples if the originals arn't "close enough" in color space. Many software 3D renderers (like POVRay) can do that. It can be fairly expensave in terms of runtime (depending on how you define "close enough", and how busy the image is), but can produce some stunning results.
If they don't do that, I expect some future 3D card will.
Re:This is the wrong question
on
Linux Failover?
·
· Score: 2
I am wondering why NICs with more than one port are so danged expensive though? I can see a bit of an increase in price, but there is no way these things should be $400 and up (last time I looked..)
The SBus QFE part may have been space constrained (SBus cards are small), which will bump the price a little. Multi-port PCI NICs normally need a PCI bridge part (actually it's been a while since I bought one, maybe they do it all in one multifunction PCI chip now), which pushes the cost up a little too.
But the big reason is economy of scale. It costs a lot of money to design a product, document it, write drivers, set up distribution channels, and so on. Cost that is mostly fixed regardless of how few of the product you sell.
Contimplate the following example:
Assume for the sake of argument that it costs $1,000,000 to design a PCI board. Now assume I make a 4 port ethernet (with a parts cost of $40), and you make a one port ehternet (with a parts cost of $10). Also assume there are (only) 1,000,000 people on the earth (and all want to be in on the big LAN party). Some of them are uber-graks and will buy the 4-porter so they can have a 4-porter. Some want a "reliable gaming experance" and will buy the 4-porter because they have 3 more ports if hte first fails. Some want to run the LAN server and need more bandwidth. In all 100,000 people are intrested in my product. 900,000 in yours. To exactly cover our costs you need to charge $10 for the parts and a bit over $1 for the "overhead" -- a $11 price, I have to charge $40 and a bit over $10 in overhead -- a $50 price.
Alot of the people who wanted a "reliable game experiance" are now swayed by your argument that they can buy two cards and get "enough" reliability. Or even 4 of yours ($44), and an extra $6 to buy another ethernet cable in case their breaks! A few more are swayed by the argument that $50 is alot to pay for a network card, look over there a $10 card. Maybe they should keep the rest of the money, or buy a new game, or save up for a monkey. Soon only 10,000 people want my card. Your overhead drops a little (it is still about $1), but mine rockets to $100!
With a $140 price tag even the uber-geeks start rethinking, and decided maybe they would rater show their geekeness with a $130 EFF contribution, and a nifty EFF bumper sticker on the side of their case.
That's when things really start to suck, only the 5 guys holding the LAN party that need my card are now intrested in it. The price rockets to $200,040. At that price the 5 guys will spend a long time trying to figure out a way to do the whole gig without my card. In the end maybe they just charge everyone on the planet $5 to get into the LAN party and end up with "free" cards.
There are lots of little things wrong with this example (the guys running the part could probbably use 4 of your cards at once), there are more then 1,000,000 people, the overhead costs can vary from product to product, some people will buy even seriously overpriced goods. But I think it does go a long ways towards showing why a Sun QFE costs $1,500 and a Intel Ether Express 100+ is $25.
I think VCs == suits by definition, and Kleiner Perkins is one of the big VC firms, yes?
Lots of tech folks (non-suits) have made money. If they decide to fund a start up that they havn't founded (in exchange for stock) that is suitless VC.
So if you shop a start-up around, and, say, get Eric Raymond intrested in it, that doesn't make him a suit (I'm assuming you didn't think he was one anyway). If he is intrested enough in it to give you money in exchange for stock, and a say in how the compony is run, he still isn't a suit either, is he?
It has happened before (not with Eric that I know of). I have no doubt that it will happen again.
Granted most people who give venture capital are suits. But that isn't part of the definition.
It is true that IBM is a great innovator in HDD tech, but they really don't have much market share. How often do you come across an IBM drive in the field? They seem to price themselves out of the market.
Their SCSI LVD prives seemed quite competitave last time I bought a drive, it was only $10 more then the lowest price when I bought it (according to pricewatch). I gladly payed the extra $10 because of all the drive failures we have at work, IBMs are the most rare (HP was the most common, untill they left the biz), and they also start giving R/W soft failure errors hours or days before they actually go. I have never seen a hard failure on an IBM SCSI drive without soft failures before it. I want the chance to say "where is my DAT drive?" before the disk goes Tango Uniform.
Their IDE drives arn't as competitave, that might say more about the quality of their competiters drives then any lack of desire of IBMs to "own" the market. Maybe. It's not like I understand the PC hard disk market.
As far as CPUs go, I think your thery pays out better. RS/6000s have a mammoth profit margin. Far more then the PowerPC. Then again, maybe the same is true in the SCSI vs. IDE thing too.
Glad to hear it. For some reason I thought it had allready lost to P-III@1Hhz, or a K7@1GHz. The numbers I posted were SPECfp95 numbers (that's what AMD had). I do think someone else posted P-III SPEC2000's, but I've forgotten.
It would be nice to see the 1GHz K7 SPEC2000 numbers. As far as I know they meet SPECs def of shipping, so I wonder why AMD hasn't seen fit to publish them. Maybe they are waiting for the large integrated L2 cache version?
RCA had silicon on sapphire for the 1802 microprocessor back in the early 1980's. One of the benefits, as I recall, was radiation resistance (works great in satellites).
Yep, five+ years ago you could get a silicon on sapphire MIPS R3000 (or R2000? I think R3000), it ran at 25Mhz I think, and cost over $10k.
I think IBM's contribution (this time around) to SOI is that they have a way to do it without incresing costs dramatically.
However I'm not a process expert, so take this info with a grain of sand. Sorry.
There are no Athlon figures up (anyone know them?).
AMD has some SPECfp-95 numbers here. They show a 800Mhz athlon at 26.6 (P-III shown at 19.8), 900Mhz at 27.5, and 1000Mhz 29.4 They use to have some SPECint numbers as well, showing about a 15% lead over the P-III, but that was at a clock speed where the Athlon had the half speed L2 cache, and it was when the P-III also had a half speed cache (P-IIIs with the smaller, faster, more associtave cache L2 are a bit faster on many benchmarks then the older P-IIIs). So I don't know how the current P-III stands in int to the current K7. Probbaly not as good or AMD would publish those numbers.
The orignal poster wanted to know if the Alpha was competitave with lower clock speeds. The answers shown here say the 21264 is. I want to point out that the picture was somewhat diffrent with the 21164 and 21064. They are strictly in-order machines, and the 21064 has very strict instruction grouping rules.
The 21064 (frequently) does less work per clock then a P-III, P-II, and even frequently a PPro. Of corse the 21064 was new a very long time ago (8 years?). The 21064 did somewhat less work per clock then most of it's contempary RISCs. But it was clocked much much faster. (i.e. 133Mhz 21064 vs the 50Mhz TI SuperSPARC, definitly much faster then the 386s and 486s of it's day as well)
The 21164 did more work per clock then the 21064. It's contemparary RISCs were doing much more work per clock. Far more out of order dispatch and specultave execution in the other RISCs, and in the PPro which Intel brought out during the 21164's lifetime (I think). However the 21264 once again had a dramitaic clock speed advantage (2x or more in some cases - 3x to 4x over the Intels for a while).
The 21264 is a diffrent kind of Alpha. The first one to do a lot of out of order and specultave execution. Clock for clock it gets far more work done then the 21164. Which is good because it no longer outclocks many of it's foes. It has even lost the top slot in SPECint which the Alpha has held more or less since it's introduction (not at all times, but never lost it for more then a few months that I recall -- then again I didn't check every month!). Even the SPECfp it shows some weeknesses it hasn't in a long time (I recall it having a firmer grip on #1 here, losing when HP announced new HPPA machines, and to some of the RS/6000s, but allways regaining it fairly soon after).
Seeing a 21264 with a really fast clock will definitly be an impressave thing. It will strain it's 8M L2 cache at 1.2Mhz for sure. Probbably blow right past it. I wonder if they will have a much larget L2, or if they will use a big L3?
I also look forward to the 21364. I don't think Compaq has said a lot about it, other then SMT. Simultanius Multi-Threading, which looks similar to SMP on a chip, but it lets the CPU assign functional units on a per-cycle basis to acheve maximum throughput. I wonder what else the 21364 will do. I wonder if it will go back to a simpler in-order less-specultave execution model (using SMT to tolarate the memory latency).
I heard the 21364 taped out in December as planned. I don't know how the test samples were, or what the rest of the schedule is.
P.S. dispite never having owned an Alpha, I'm definitly a member of the "Alpha is fast cult". A pity it has allways been cheeper to ray trace using more CPUs of something else (the K7 last I did my estimates).
COM has been around in one form or another since the 1990s, COM was designed as a binary standard for calling methods.
The first CORBA draft was published in 1991, so COM and CORBA seem to have been devloped at about the same time (I donno which came first, may have been COM, may have been CORBA).
BTW, I'm not sure how relevant your windows is younger than unix statement is, well obviously...VMS is older than Unix, and NT is based on VMS:P.
VMS is sure as hell not older then Unix. VMS came out on the VAX, and not any prior CPU. The VAX was a late-70's CPU (October 1978 I think). If you look at DMR's Historical Perceptions about the VAX architecture you will see some dates (and other intreresting VAX info). If you poke around the rest of his pages you'll see some dates for Unix that are much older. Like by almost ten years.
Unix is generally accepted to have been invented in 1969 (even with a 1970 begining of time value). I find this number easy to remember because I also was "invented" in 1969. That does make it a bit hard for me to remember the VAX rollout, but I figure DMR'll tell it stright.
CORBA is generally an out of process technology. It was developed to allow objects to be called remotely, and sortta, transparently.
You are right when you say CORBA is generally used for cross-process RPCs. Wrong when you tar it with the "sortta transparent" brush. If you either ignore the string issue (CORBA strings are not plain char*'s in C, and not C++ string objects in C++), or in C++ make a conversion operator from string (or char*) the calls are transparent. At least if you are willing to make sync RPC calls.
You can use it as a all-in-one-process calling convention, but it's generally not needed.
[crude memory protection]
I don't know quite how this works, but I guess that it relies on an external chip with a control register or which checks whether the CPU is in supervisor state. (The 68000 family and presumably the Dragonball indicate this for each bus cycle.)
It sets the low bit of the closed "database" so it is an invalid word/dword pointer. If you do any of the Db calls on it you get a bus error, but only because the pointer is mis-alighed. If you do a Db call on it and some other app has it open (or left it open) it goes through.
If you stored a pointer in a variable too long and then use it, the write goes through.
If you store a pointer, and then overwrote part of it, the write will go through.
I don't know if the DragonBall indicates user vs. supervisor state, but the memory "contoler" (chip select control, and RAS/CAS strober) is all built in. So unlike a 68000 system where you need to put a PAL (or descrete logic) in anyway to do all that crud, and can slip in a very simple memry protection unit (like the Amiga WCS, or the ST's "system area"), the DragonBall does not let you ride that stuff in for free. Not because it makes anything more expensave, but because it makes not doing so free, and $10 vs. $9.75 is easy to pay, but $10 vs. $0 isn't so easy to justify.
Only one application is running at a time
Except if you do a Find. Or a few other similar things (but you don't get the "globals register" set, so you have to run in-stack only, and many OS calls are unavailable. There are also shared libraries, I'm not totally clear on how they work in PalmOS (didn't read that chapter yet), but they implment TCP/IP (and UDP, PPP, and ICMP) in a shard lib, so it has to have some sort of premption ability. The IR stuff is also a shared lib.
I don't know anything about EPOC it may be as bad, but what I know about PalmOS makes me amazed at how stable the apps under it are. And it makes me lery of wanting to try to write my own!
On the other hand, if I could bear to lug around the YOPY I would be all over writing apps for it. But man, oh man, cell phone, GPS, and a big-ass PDA is a lot to carry. Even the Visor (Pilot sized PalmOS Pilot clone) is clunky.
PalmOS is definitly a 32bit OS. Or 31 if you want to compain about stealing the low bit of pointers for "locked vs. unlocked".
The DragonBall CPU has a 16bit data bus (I think), and only 24 address pins (plus, um four chip selects I think). It does have a full 32bit ALU. And as far as the OS API cares it's pretty much all 32bits.
That said, it's not a OS I'm fond of programming in. There is no memory protection, and nothing but memory. If my program uses a wild pointer I can damage the data of another application (like, say the apointment scheduler, or address book).
[With OpenVMS]
You decidedly don't get source code to the system.
Really?
Back in the '80s you sure did. It was (mostly) written in Bliss, and totally distributed on MicroFiche (i.e. you can't recompile it unless you retype it...not real assurance that the same source you got was used to compile the system).
I think the idea was that if the full bookshelf of manuals didn't cover it, the source could help out a bit.
"Open Systems" are ones where the APIs are disclosed.
There are lots of things I don't like about VMS, but lack of disclosure isn't one of them. Tons of disclosure come with VMS. Or at least 800 pounds of manuals. Seriously.
Caveat: I know absolutely nothing about the S/390.
This doesn't relate to how fast the actual computers are. Most of the supercomputers I use run under 300 MHz (even the ones purchased this year). Of course, most of those supercomputers are actually glorified clusters...
You are right, Mhz isn't everything. For the 390, it is fairly telling. I don't recall any superscaler implmentations. I don't beleve it has a fused FP multiply and add. For FP it just isn't all that fast, nor even for 32 bit integer math. On the other hand it's BCD math can be quite fast (single instruction for most ops, something like 40 or 60ish digets supported in hardware, more possable with OS assist). Translate table instructions.
Of course, speed all depends on what the job is. In my case I run memory/floating point intensive quantum mechanics calculations.
If it's I/O you need fast a 390 can do it. If it is something else you need fast, there is almost certonally another computer that will do it better. Frequently even made by IBM:-)
For FP Fortran code, I would guess a Alpha would really run much faster (in absolute terms, or per dollar) then a 390, unless you have quite a bit of I/O going on. Even then maybe. I'm sure Compaq has a F90 compiler.
Of corse the 390 is very very very good at making sure that the answer you get is right. It's somewhat fault tolerent, but more importantly for many applications it actaully notices many kinds of breakage and will let you know about them rather then blondering on with the wrong answers.
So you should pick what you need from your Linux distribution, and don't install anything else. Or install OpenBSD if you want to. Just remember that a lot of free software is currently written with Linux as its primary target, so you may need to tweak it to get it going on OpenBSD.
Now you have the misleading comparisin.
The stripped down Linux will be just as sparse of features as OpenBSD (or more so if you do your job right). But who audited all that code for security holes? Who went over that code looking for buffer overuns? Who went back over that code looking for mis-uses of strncat?
OpenBSD isn't secure because they don't ship much stuff. It is secure because they only ship stuff they have secured. That ends up being not much stuff because it is hard to secure things.
Racecars don't have CD players. I can't make my car into a racecar by yanking out my CD player.
Comparing RedHat Linux to OpenBSD simply on the basis of how often security flaws are found in the entire distribution is misleading.
That I'll give you. RedHat has more users, and may be a more intresting target, so it may show more flaws. Except OpenBSD has made itself an extreamly tempting target by going "undefieted" so long, and being the chokepoint into more and more networks.
Still looking at the raw numbers is not as cut and dried as it looks.
disclaimer: I happily use both RedHat Linux and OpenBSD, so I know the strengths and weaknesses of both)
The Linux kernel isn't being developed for RedHat, or Caldera, or whatever.
There are lots of people doing work on Linux for free. Some of that work is even off in userland where it will help some or all of the BSDs as well.
There are people employed by Red Hat (and I expect others) that are payed to work on Red Hat. The folks that work for Red Hat Labs for example.
Are there fewer BSD developers because of Linux, then?
Sure. But Linux has done the work to get them. It's users were more excited. More intrested in recuriting others. More willing to try a new devlopment model. More willing to try a new bisness model. More willing to risk the goose that gave them their golden egg.
So I dont get it. Yeah, Linux gets more press. But who the hell is doing Linux development for the press? And when did lack of press make a difference to bedroom coders?
People doing it for the ego boost would be somewhat more intrested in who has the larger user base. People intrested in doing coding on an OS they can sell the boss may go for the one that has recieved more press. People tired of Windows coding may see the alternitave covered in the press and go for it.
So, yeah, the press helps. And some people who use BSD are jelious of Linux's success. Some people who use BSD are delighted by Linuxes success. Some people who use BSD are happy to see BSD get a bit more press too. Some people who use BSD would rather keep it's eletest nature and not see so much press. I'm all of the above, in diffrent mesures as the days pass.
Slashdot Mirror
Clearly we don't, or the article would have had the partners link. You are right, whover posts the link first gets a karma bonus, but they are getting it for sharing useful information.
Every bit as useful as the guy who posted the link to the Nature story on the same thing. After all we all know how to search the web don't we? I mean really, if it is a science issue, then we all know it'll be in New Scientest, Nature, the University's web site, and the like. Anyone who posts thos links is just Karma Whoreing too.
Just in case anyone whats to know what "way more" per month gets...
Crappy install. That's right. Install costs a whole lot of moeny (they bury a new cable), and it still sucks. It took Bell Atlantic a few months the first time, and two trips (once to bury the cable, once for a guy to attatch a Smart Jack) the first time. The second time it took somewhat less long for the first visit, but then they discovered they "forgot" to dig all the trench they needed, so I had the choice of having cable layed over my new neibors lawn, and across my roof, or waiting another few weeks. I choose the wait.
Once I got the service (56K FR the first time, about 5 or 6 years ago, 256K FR about 2 years ago) it has been great. A few outages (less then 2 "real" ones per year so far). Half the time the ISP calls me first (they tend to call within an hour of the outage, and I'm at work a lot, and not using the connection much!). When the outage isn't solved by rebooting the router (a Ascend Pipeline 70 with an old code load), and isn't a known Bell Atlantic trunk issue they will contact Bell Atlantic for me (I have the option of waiting on hold, being confrenced in, or having them call back). Most outages are solved in a few hours (which can seem like l-o-n-g hours if I was palnning on doing something). One took more then 8 hours, and was a big Bell Atlantic T3 problem of some sort.
Regretably this level of service seems just really expensave, and when I leave my current job I'll have to find something a lot less expensave, and most likely less reliable, or maybe just as reliable, but with longer service wiat queues.
However if reliabilty is a big issue, and your employer will pay for the line, you may want to try Frame Relay from one of the bigger ISPs (I would recomend UUNET, but since I work for them, I'm a bit biased). If cost is a big issue, then stick to cable modems or DSL. And hope LMMDS shows up soon, and is better.
D'oh! Sorry, you labeled it as the offical paper, but somehow I missed thet when looking at where you link went (not to TM, but off elsewhere). Sorry.
They say they do it, but the don't really say why (I can guess, and you can guess, but neither of us can know). Maybe I am being too hard on the Spectrum article, but all it gives is hints at why things really happened. Somehow that managed to bitter me on the technical side of the paper.
Yes. Or more from those articles after the spectrum article.
I expect so. Except it is likely to be pretty painful since there may be seeming arbatary restrictions like "ALU1 and ALU2 may not both have even register numbers as targets in the same clock cycle" because that may have made the hardware modestly better in some way, and not made the code morpher (much) harder to write. It also doesn't have a "real" MMU (I havn't found out what it does have, so I'll guess a hardware TLB, and all software table walks, but who knows). Oh, and the two biggest problems of all:
The article even gives a good example of the kind of severe eratta the TM can live with. At 433Mhz-ish the CPU worked fine. At faster speeds it can't execute two particular instructions in the same bundle (it didn't say what they were, so I'll pretend they were "ADD with 32bit immediate; BRANCH ON CARRY to 16bit offset"). That would prevent the shipping of a normal CPU (faster then 433Mhz at least). With the TM the code morpher can be set to avoid issuing those two instructions at the same time if the CPU stepping is known to have that bug, and they can ship a 600Mhz version. The performance loss from having to code "ADD with 32 bit immediate; NOP; BRANCH ON CARRY to 16bit offset; NOP" will be tiny, I would be supprised if it was 3%, esp. since the CM may frequently be able to fill the NOPs with other instructions.
That's not to say all, or many steppings have such bugs, but if they put out new version with a better cache (25% perf boost) and it introduced a bug that could be avoided by taking a 3% hit, they can release. Nobody else can, because they can't be sure all fielded code avoids such bugs! TM can because, and only because there is one and only one application, the Code Morpher.
You may as well assert you could make faster VAX programs if DEC (er, Compaq) opened their Microcode, or the 68020 and Motorola. Your right, you could. But it would be extreamly non-portable, and may severly restrict Transmeta/DEC/Moto from being able to make new CPUs if a signifigant app starts depending on that ability.
Have you looked at Transmeta's own pages? They have everything I would think of as "technical" from this article except the bit about being "bug for bug compatable" being the hardest bit (and since the article mangled that by defining it as getting the BSOD at the same place rather then tracking Intel's bugs so software dependent on them don't BSOD/segv I'm not giving any credit!). Oh, and the article also gives slightly more detail on what early Si bugs were worked around in software.
The Transmeta page will show you the code sequence the article used, and explain how it is derived, and how fast it is, along with a few others.
What I will say for the article is it did a good job explaining the nontechnical parts. It was intresting what it took to get the VCs rolling. What the work enviroment is like. How psyced the hardware folks are to get to do a brand new CPU every time.
Good article, worth the read. But not for the tech info.
I can see how this would make for a lot of diffrent futures symbols, but not that it is an impossable obsticle. Of corse I would pay a diffrent ammount for PC133 64MBit 7-1-1-1 Jan2001 options then i would for DDR PC200 128Mbit 12-1-1-1 Jan2001 options. And of corse I probbably wouldn't pay much at all for any 2004 options as I think we'll be off to a new technology. but I think the diffrences are easally quantifyed, and most of the boilerplate (delevered to X, loose parts/finished sticks, acceptable defect rate, transaction rules) can remian the same. After all a share of WCOM now is vastly diffrent from a share of WCOM four years ago, yet it is traded on CBOE. A share of UUNT is no longer available, but it was once traded on the CBOE. There is a chance that AWE shares will be swollowd back into T shares, yet they trade on the CBOE.
I'm with you on the other oddamints. I hadn't thought of them. Well with the possable execption of large consumers. I would think this would help them even more. Then again it would also help the small consumers a whole lot, which the large ones might not like. I think most of all that like wheat futures, DRAM futures would help DRAM producers.
You are right that a narrow bus width doesn't cause high latency in and of itself. And right that it isn't the source of RDRAMs latency. But it doesn't have nothing to do with latency.
If you have an identical 16 and 32 bit bus, and you want to fetch a 128 bit cache line from 32 bit address X, the 16 bit bus has to take two clocks to transmit address X, and 8 more to transmit the data, or 10 clocks. The 32 bit bus needs only one cycle to transmit the address, and 4 more for the data, total of 5 clocks, half the time of hte 16bit bus. As you said "Latency is the amount of time it takes from the issue of a memory read until it answers." (I would count time to issue the read as well).
RDRAM transaction overhead is resonably competitave with EDO RAM RAS and CAS timings (RDRAM takes 4 clocks at 400Mhz to 800Mhz to start a transaction EDO takes two but at a much lower speed, SDRAM I think also only takes two, but with DDR SDRAM it could be 2 clocks at 266Mhz, which is almost as fast as 600Mhz RDRAM).
The thing that kills RDRAM seems to be the time it takes the motherboard chipset to set up the transaction, the low number the motherboard chipset keeps actiave (each RDRAM can usefully service transactions from 2 sense banks), and most importnat of all, the time the RDRAM itself takes to light up a sesne bank.
With 7-1-1-1 PC100 SDRAM it takes 7 clocks at 100Mhz (70ns?) to read the first 64 bits back from the SDRAM. Allways. No matter what 64bits you want. Then one clock (10ns) for the following 3 64bit words (I think bursts can be longer, but I don't know of any PC chipset that does long bursts).
With 800Mhz RDRAM it takes 4 800Mhz cycles (~6ns? about 10x PC100) to start the transaction. Then if the data is in one of the RDRAMs two sense amps the data comes back 16bits per cycle (a little under 4ns per 64 bit word - about 2x the speed of PC100). However if the data is not in one of the sense amps, the data that is in the amp will be written back (if it has been modifyed), and then that bank will be lit up. This can take a whole lot longer then PC100's 70ns. A whole whole lot longer. Like 400ns. If you have lots o hits in the same sense amp (like you would on a very small, or no cache machine) you get lots more speed form RDRAM. If you get few hits on the sense amp, you suck. Hard.
Regretably that 400ns number is old (as is my SDRAM timings). I don;t know if the newer RDRAM has improved things, or has more sense amps, or a hidden write back. I know that DDR SDRAM comes much closer to RDRAMs peak timings, and that DDR SDRAM can get those numbers consitantly, while RDRAM needs a "good" access pattern otherwise it's throughput falls to a few percent of peak.
I donno if you can overlap transactions to the same RDRAM chip (I think you can), but you can overlap them between RDRAMs. Of corse that requires either a CPU that can do multiple outstanding memory references, or multiple CPUs (or other sources of memory traffic). You could allways interleve, but that seems kind of pointless given the high bandwidth once the sense amp is lit!
Total agreement. RDRAM is cool, but it just doesn't solve a problem most people have.
I, like many others, have limited space under the TV. It is cramed full of things, a DVD player, AC-3/DTS decoder, satalite reciever, VCR, and game machine. I like many others have a signifigant other who likes a nice looking room more then a nifty new game machine. I like having a (happy) signifigant other much more then having a new game machine, not to mention an OLD game machine.
So I got rid of the PlayStation (really I put it in a box in the basement) when I got my DreamCast.
I'll bet a lot of people with N64s would like to have a Dolphin, and not have to box up their N64. Of corse I would like to have a PSX2 and not have to box up my DreamCast too. We don't all get what we want.
Plus I would figure it is a minor, but positave, selling point to have an established set of games, even if many arn't so hot, and even if none push the machine.
And back to the main point, RAMBUS is good memory technology for systems that can tolarate fairly high latencey, and need a whole lot of bandwidth for cheep. The "for cheep" part is important, if you have to pay too much for RAMBUS, you can buy more common RAM technologies, and use a wider bus (note, I'm assuming you are designing a system, this won't work if you went out and bought a motherboard, buying 4 SDRAM sticks won't magically give you 4x the bandwidth if the motherboard and chepset arn't designed to work that way).
The high end technical workstation market has little need of RAMBUS, it can design 512-bit wide paths to memory. Sure they cost a ton of money, but that's a big part of why the $7000 Alpha motherbords cost $7000 (and the total reason you need to buy RAM in 4 stick lots, er, maybe 8). Except for the low end Alpha motherboards which cost $2000 or $3000 because they don't sell enough to earn back the NRE at $120 like PC motherboards.
Note that I say little need, not no need. It looks like the Alpha 21364 has RAMBUS controlers on chip, which Compaq claims reduces latency signifigantly. Hopefully they are right, because I like the Alpha, and it would be unplesent if it started sucking.
RAMBUS isn't a very good technology for PC memory because bandwidth to main memory isn't as big an issue as the latency. It might be good memory for a 3D board's texture storage, since bandwidth matters a lot there. Then again it may not, since new 3D boards store vertex info there, which may be far more latency sensitave.
But RAMBUS makes a decent memory for a game machine designed 5 years ago (N64). There was no SDRAM to chalange RDRAMs bandwidth. In fact RDRAM had competiave latancy then even. The psudo-caching effects of RDRAMs sense banks let a no L2 cache RDRAM system compete well with a mid-size (for the year) L2 cache system with EDO DRAMs. Great choice.
Beats me why the Dolphin is slated to use it. Maybe they didn't beleve in SDRAM? Maybe they know something about RDRAM we don't. Maybe they are on crack. Chances are we'll find out in less then a year.
As far as I can tell cheap DDR SDRAM leaves RDRAM as a solution in search of a problem, but that doens't mean RDRAM was allways a steaming pile. In 1992 (which is when I recall the first RDRAM demo systems) it was really promising, and well ahead of the pack. They just havn't been running fast enough, and now the world of cheap RAM has cought up.
Yep, next weeks price increse is only ten cents a 1.6% price hike.
The article seems to think the demand will continue (or rise), and that Micron has additonal idle production capacity, but pretty much nobody else does (they could switch back to DRAM from FLASH, if DRAM becomes more profitable then FLASH again, incresing hte price of FLASH of corse).
If it is right then we are in for more price hikes. How many or how much is, of corse, pretyt much unknown. If anyone could tell for sure they could make a huge amount of money from buying and selling futures on RAM. Hmmm, I can't find DRAM futures at CBOE (which has other futures and options), anyone know where they might be?
In other words this is the begining. Possably the begining of nothing. Possably the begining of a huge increse. Probbably merely something in between.
They (the JPEG2K members) can make it free for free software. They can make it free for comercial software. As far as I can tell, they have been working to make both true. They can not make it free forever. All they can do is make sure none of the member componies persue relivant patent "rights". There is know way they can be sure that some (3rd party) patent out there is relivent. There is even less way to know if some as-of-yet unfiled US patent is relivent.
I do hope they give it a new MIME type, and recomended filesystem extension. If they don't it will be a seriously unplesent transition.
I'll also be extreamly intrested in how long it takes to get adopted vs. how long it has been taking PNG (PNG support still appears to be improving in software, but I have seen few big web sites using it -- not even using any unplesent "IfBrowser" stuff). As far as I can tell JPEG2K has few features over JPEG then PNG did over GIF. I wonder if that will help or hurt. Regretably there are other factors and it will be hard to tell which are more important (PNG has a superset of GIFs still image features, but a subset of it's animation features, that is to say none of them; JPEG2K will have easier integration (assuming someone in the JPEG2K group will do the work) into Mozilla then PNG did into the closed-source Netscape; JPEG2K has comercial backing, PNG was a largely individual effort; JPEG2K is replacing an (effectivly) unencumbered format).
I beleve the reason JPEG2K adopts it as part of the image format is they can store the higest resoultion, and quickly convert that into a lower resoultion (or image subarea). That is a pretty cool feature, I don't know how useful it will be in practice, but it sounds cool.
I don't know what they will do. I expect there are things they can do if they care. There are lots of patents on the algos used for JPEG2K. As far as I can tell holders had to allow free use in JPEG2K to get their algos considered. I doubt they gave up rights for non-JPEG2K uses. Which means legaly they could charge for the non-JPEG2K use. The same may be true for JPEG, you could probbably contact IBM and get them to charge Seattle Filmworks...
So software patents do have a minor good use (a few actually). Still IMHO outweighed by their destructave power.
That need not be the case. If you render the pixel four times and avg there is no need to store those four pixels to memory, and then read them back. Rendering at 2x (four intermediate pixels per one output pixel) you need to write pixel values five times, read them four times, and have memory dedicated to the intermediate image (and not textures, or on card virtex lists).
So if any portion of your performance is limited by memory bandwidth (or availability) on the 3D card, the 3Dfx method will be faster. If not, they should be as you suggested, pretty much the same (all else being equal)
That's not saying that's what actually happens, but it is quite possable.
Could be.
Beats me. Either could be taking shortcuts which change the result image. It is also possable, but unlikely that the FSAA actually takes more samples if the originals arn't "close enough" in color space. Many software 3D renderers (like POVRay) can do that. It can be fairly expensave in terms of runtime (depending on how you define "close enough", and how busy the image is), but can produce some stunning results.
If they don't do that, I expect some future 3D card will.
The SBus QFE part may have been space constrained (SBus cards are small), which will bump the price a little. Multi-port PCI NICs normally need a PCI bridge part (actually it's been a while since I bought one, maybe they do it all in one multifunction PCI chip now), which pushes the cost up a little too.
But the big reason is economy of scale. It costs a lot of money to design a product, document it, write drivers, set up distribution channels, and so on. Cost that is mostly fixed regardless of how few of the product you sell.
Contimplate the following example:
Assume for the sake of argument that it costs $1,000,000 to design a PCI board. Now assume I make a 4 port ethernet (with a parts cost of $40), and you make a one port ehternet (with a parts cost of $10). Also assume there are (only) 1,000,000 people on the earth (and all want to be in on the big LAN party). Some of them are uber-graks and will buy the 4-porter so they can have a 4-porter. Some want a "reliable gaming experance" and will buy the 4-porter because they have 3 more ports if hte first fails. Some want to run the LAN server and need more bandwidth. In all 100,000 people are intrested in my product. 900,000 in yours. To exactly cover our costs you need to charge $10 for the parts and a bit over $1 for the "overhead" -- a $11 price, I have to charge $40 and a bit over $10 in overhead -- a $50 price.
Alot of the people who wanted a "reliable game experiance" are now swayed by your argument that they can buy two cards and get "enough" reliability. Or even 4 of yours ($44), and an extra $6 to buy another ethernet cable in case their breaks! A few more are swayed by the argument that $50 is alot to pay for a network card, look over there a $10 card. Maybe they should keep the rest of the money, or buy a new game, or save up for a monkey. Soon only 10,000 people want my card. Your overhead drops a little (it is still about $1), but mine rockets to $100!
With a $140 price tag even the uber-geeks start rethinking, and decided maybe they would rater show their geekeness with a $130 EFF contribution, and a nifty EFF bumper sticker on the side of their case.
That's when things really start to suck, only the 5 guys holding the LAN party that need my card are now intrested in it. The price rockets to $200,040. At that price the 5 guys will spend a long time trying to figure out a way to do the whole gig without my card. In the end maybe they just charge everyone on the planet $5 to get into the LAN party and end up with "free" cards.
There are lots of little things wrong with this example (the guys running the part could probbably use 4 of your cards at once), there are more then 1,000,000 people, the overhead costs can vary from product to product, some people will buy even seriously overpriced goods. But I think it does go a long ways towards showing why a Sun QFE costs $1,500 and a Intel Ether Express 100+ is $25.
Lots of tech folks (non-suits) have made money. If they decide to fund a start up that they havn't founded (in exchange for stock) that is suitless VC.
So if you shop a start-up around, and, say, get Eric Raymond intrested in it, that doesn't make him a suit (I'm assuming you didn't think he was one anyway). If he is intrested enough in it to give you money in exchange for stock, and a say in how the compony is run, he still isn't a suit either, is he?
It has happened before (not with Eric that I know of). I have no doubt that it will happen again.
Granted most people who give venture capital are suits. But that isn't part of the definition.
Their SCSI LVD prives seemed quite competitave last time I bought a drive, it was only $10 more then the lowest price when I bought it (according to pricewatch). I gladly payed the extra $10 because of all the drive failures we have at work, IBMs are the most rare (HP was the most common, untill they left the biz), and they also start giving R/W soft failure errors hours or days before they actually go. I have never seen a hard failure on an IBM SCSI drive without soft failures before it. I want the chance to say "where is my DAT drive?" before the disk goes Tango Uniform.
Their IDE drives arn't as competitave, that might say more about the quality of their competiters drives then any lack of desire of IBMs to "own" the market. Maybe. It's not like I understand the PC hard disk market.
As far as CPUs go, I think your thery pays out better. RS/6000s have a mammoth profit margin. Far more then the PowerPC. Then again, maybe the same is true in the SCSI vs. IDE thing too.
Glad to hear it. For some reason I thought it had allready lost to P-III@1Hhz, or a K7@1GHz. The numbers I posted were SPECfp95 numbers (that's what AMD had). I do think someone else posted P-III SPEC2000's, but I've forgotten.
It would be nice to see the 1GHz K7 SPEC2000 numbers. As far as I know they meet SPECs def of shipping, so I wonder why AMD hasn't seen fit to publish them. Maybe they are waiting for the large integrated L2 cache version?
Yep, five+ years ago you could get a silicon on sapphire MIPS R3000 (or R2000? I think R3000), it ran at 25Mhz I think, and cost over $10k.
I think IBM's contribution (this time around) to SOI is that they have a way to do it without incresing costs dramatically.
However I'm not a process expert, so take this info with a grain of sand. Sorry.
AMD has some SPECfp-95 numbers here. They show a 800Mhz athlon at 26.6 (P-III shown at 19.8), 900Mhz at 27.5, and 1000Mhz 29.4 They use to have some SPECint numbers as well, showing about a 15% lead over the P-III, but that was at a clock speed where the Athlon had the half speed L2 cache, and it was when the P-III also had a half speed cache (P-IIIs with the smaller, faster, more associtave cache L2 are a bit faster on many benchmarks then the older P-IIIs). So I don't know how the current P-III stands in int to the current K7. Probbaly not as good or AMD would publish those numbers.
The orignal poster wanted to know if the Alpha was competitave with lower clock speeds. The answers shown here say the 21264 is. I want to point out that the picture was somewhat diffrent with the 21164 and 21064. They are strictly in-order machines, and the 21064 has very strict instruction grouping rules.
The 21064 (frequently) does less work per clock then a P-III, P-II, and even frequently a PPro. Of corse the 21064 was new a very long time ago (8 years?). The 21064 did somewhat less work per clock then most of it's contempary RISCs. But it was clocked much much faster. (i.e. 133Mhz 21064 vs the 50Mhz TI SuperSPARC, definitly much faster then the 386s and 486s of it's day as well)
The 21164 did more work per clock then the 21064. It's contemparary RISCs were doing much more work per clock. Far more out of order dispatch and specultave execution in the other RISCs, and in the PPro which Intel brought out during the 21164's lifetime (I think). However the 21264 once again had a dramitaic clock speed advantage (2x or more in some cases - 3x to 4x over the Intels for a while).
The 21264 is a diffrent kind of Alpha. The first one to do a lot of out of order and specultave execution. Clock for clock it gets far more work done then the 21164. Which is good because it no longer outclocks many of it's foes. It has even lost the top slot in SPECint which the Alpha has held more or less since it's introduction (not at all times, but never lost it for more then a few months that I recall -- then again I didn't check every month!). Even the SPECfp it shows some weeknesses it hasn't in a long time (I recall it having a firmer grip on #1 here, losing when HP announced new HPPA machines, and to some of the RS/6000s, but allways regaining it fairly soon after).
Seeing a 21264 with a really fast clock will definitly be an impressave thing. It will strain it's 8M L2 cache at 1.2Mhz for sure. Probbably blow right past it. I wonder if they will have a much larget L2, or if they will use a big L3?
I also look forward to the 21364. I don't think Compaq has said a lot about it, other then SMT. Simultanius Multi-Threading, which looks similar to SMP on a chip, but it lets the CPU assign functional units on a per-cycle basis to acheve maximum throughput. I wonder what else the 21364 will do. I wonder if it will go back to a simpler in-order less-specultave execution model (using SMT to tolarate the memory latency).
I heard the 21364 taped out in December as planned. I don't know how the test samples were, or what the rest of the schedule is.
P.S. dispite never having owned an Alpha, I'm definitly a member of the "Alpha is fast cult". A pity it has allways been cheeper to ray trace using more CPUs of something else (the K7 last I did my estimates).
The first CORBA draft was published in 1991, so COM and CORBA seem to have been devloped at about the same time (I donno which came first, may have been COM, may have been CORBA).
VMS is sure as hell not older then Unix. VMS came out on the VAX, and not any prior CPU. The VAX was a late-70's CPU (October 1978 I think). If you look at DMR's Historical Perceptions about the VAX architecture you will see some dates (and other intreresting VAX info). If you poke around the rest of his pages you'll see some dates for Unix that are much older. Like by almost ten years.
Unix is generally accepted to have been invented in 1969 (even with a 1970 begining of time value). I find this number easy to remember because I also was "invented" in 1969. That does make it a bit hard for me to remember the VAX rollout, but I figure DMR'll tell it stright.
You are right when you say CORBA is generally used for cross-process RPCs. Wrong when you tar it with the "sortta transparent" brush. If you either ignore the string issue (CORBA strings are not plain char*'s in C, and not C++ string objects in C++), or in C++ make a conversion operator from string (or char*) the calls are transparent. At least if you are willing to make sync RPC calls.
You can use it as a all-in-one-process calling convention, but it's generally not needed.
It sets the low bit of the closed "database" so it is an invalid word/dword pointer. If you do any of the Db calls on it you get a bus error, but only because the pointer is mis-alighed. If you do a Db call on it and some other app has it open (or left it open) it goes through.
If you stored a pointer in a variable too long and then use it, the write goes through.
If you store a pointer, and then overwrote part of it, the write will go through.
I don't know if the DragonBall indicates user vs. supervisor state, but the memory "contoler" (chip select control, and RAS/CAS strober) is all built in. So unlike a 68000 system where you need to put a PAL (or descrete logic) in anyway to do all that crud, and can slip in a very simple memry protection unit (like the Amiga WCS, or the ST's "system area"), the DragonBall does not let you ride that stuff in for free. Not because it makes anything more expensave, but because it makes not doing so free, and $10 vs. $9.75 is easy to pay, but $10 vs. $0 isn't so easy to justify.
Except if you do a Find. Or a few other similar things (but you don't get the "globals register" set, so you have to run in-stack only, and many OS calls are unavailable. There are also shared libraries, I'm not totally clear on how they work in PalmOS (didn't read that chapter yet), but they implment TCP/IP (and UDP, PPP, and ICMP) in a shard lib, so it has to have some sort of premption ability. The IR stuff is also a shared lib.
I don't know anything about EPOC it may be as bad, but what I know about PalmOS makes me amazed at how stable the apps under it are. And it makes me lery of wanting to try to write my own!
On the other hand, if I could bear to lug around the YOPY I would be all over writing apps for it. But man, oh man, cell phone, GPS, and a big-ass PDA is a lot to carry. Even the Visor (Pilot sized PalmOS Pilot clone) is clunky.
PalmOS is definitly a 32bit OS. Or 31 if you want to compain about stealing the low bit of pointers for "locked vs. unlocked".
The DragonBall CPU has a 16bit data bus (I think), and only 24 address pins (plus, um four chip selects I think). It does have a full 32bit ALU. And as far as the OS API cares it's pretty much all 32bits.
That said, it's not a OS I'm fond of programming in. There is no memory protection, and nothing but memory. If my program uses a wild pointer I can damage the data of another application (like, say the apointment scheduler, or address book).
Really?
Back in the '80s you sure did. It was (mostly) written in Bliss, and totally distributed on MicroFiche (i.e. you can't recompile it unless you retype it...not real assurance that the same source you got was used to compile the system).
I think the idea was that if the full bookshelf of manuals didn't cover it, the source could help out a bit.
There are lots of things I don't like about VMS, but lack of disclosure isn't one of them. Tons of disclosure come with VMS. Or at least 800 pounds of manuals. Seriously.
You are right, Mhz isn't everything. For the 390, it is fairly telling. I don't recall any superscaler implmentations. I don't beleve it has a fused FP multiply and add. For FP it just isn't all that fast, nor even for 32 bit integer math. On the other hand it's BCD math can be quite fast (single instruction for most ops, something like 40 or 60ish digets supported in hardware, more possable with OS assist). Translate table instructions.
If it's I/O you need fast a 390 can do it. If it is something else you need fast, there is almost certonally another computer that will do it better. Frequently even made by IBM :-)
For FP Fortran code, I would guess a Alpha would really run much faster (in absolute terms, or per dollar) then a 390, unless you have quite a bit of I/O going on. Even then maybe. I'm sure Compaq has a F90 compiler.
Of corse the 390 is very very very good at making sure that the answer you get is right. It's somewhat fault tolerent, but more importantly for many applications it actaully notices many kinds of breakage and will let you know about them rather then blondering on with the wrong answers.
Now you have the misleading comparisin.
The stripped down Linux will be just as sparse of features as OpenBSD (or more so if you do your job right). But who audited all that code for security holes? Who went over that code looking for buffer overuns? Who went back over that code looking for mis-uses of strncat?
OpenBSD isn't secure because they don't ship much stuff. It is secure because they only ship stuff they have secured. That ends up being not much stuff because it is hard to secure things.
Racecars don't have CD players. I can't make my car into a racecar by yanking out my CD player.
That I'll give you. RedHat has more users, and may be a more intresting target, so it may show more flaws. Except OpenBSD has made itself an extreamly tempting target by going "undefieted" so long, and being the chokepoint into more and more networks.
Still looking at the raw numbers is not as cut and dried as it looks.
Apparently not. Then again we all make mistakes.
There are lots of people doing work on Linux for free. Some of that work is even off in userland where it will help some or all of the BSDs as well.
There are people employed by Red Hat (and I expect others) that are payed to work on Red Hat. The folks that work for Red Hat Labs for example.
Sure. But Linux has done the work to get them. It's users were more excited. More intrested in recuriting others. More willing to try a new devlopment model. More willing to try a new bisness model. More willing to risk the goose that gave them their golden egg.
People doing it for the ego boost would be somewhat more intrested in who has the larger user base. People intrested in doing coding on an OS they can sell the boss may go for the one that has recieved more press. People tired of Windows coding may see the alternitave covered in the press and go for it.
So, yeah, the press helps. And some people who use BSD are jelious of Linux's success. Some people who use BSD are delighted by Linuxes success. Some people who use BSD are happy to see BSD get a bit more press too. Some people who use BSD would rather keep it's eletest nature and not see so much press. I'm all of the above, in diffrent mesures as the days pass.