The "short long" is a popular haircut amongst professional wrestlers, primadonna soccer players, and residents of Indiana.
(buzzed on the top, but long in the back)
and while we're at it.. the site has some pretty obvious flaws... to bmw fanatics:)
it refers to a 535i with a "nickel" block. This is most likely referring to the Nikasil alloy used in the 530 and 540 engines in the E34 5 series (5 series models 89-95). The 530 and 540 are both V8s that originally used Nikasil alloy.. while the 535i was the legendary M30 based inline 6 motor and had no such problems (and indeed usually lasts well into the 200k mile range).
If the car was ineed a 535i, its engine had no such problem. If the car was really a 530, and did have an effected nikasil block, then depending on mileage, the block could have perhaps been replaced under warranty. Finally, there is no guarantee that a nikasil laden engine will exhibit the particular problem so trading in a car based on heresey from someone else seems kinda foolish:)
furthermore, "beamer" is a misnomer. Dumb as it sounds, BMWs with 4 wheels (i.e. cars) are "bimmers", while the BMW motorcycle heritage (which i might add is much older than the automobile side) produces the "beemers".
as a 2 time BMW owner, i'd have to agree. No rich brat should be without a new BMW....It's important that rich idiots buy brand new BMWs as status symbols, so BMW AG can afford to make the cars fun and worthwhile for legitimate auto enthusiasts. As long as soccer moms are buying V8 X5's and 750iLs and the whole paralegal crowd is paying too much for the 3er and 530, i can continue to expect to pick up a used one and drive it the way it was meant to be driven...for pennies on the original cost.
If what you say is true, then i should be able to take an R3000 and with a sufficiently small die size and make it go 3 ghz.
But I can't. If I could do that, why did SGI break the elegance of the R3k when they introduced the R4k ? The 4400 ? The un-scalable R10k ?
Remember, when you add more pipeline stages, the amount of effort you put into designing the stage, and the amount of effort you put into designing the interlocking, goes up. You pay a much higher penalty on _every_ instruction that deals with memory ( on the x86 this is quite a lot of them). There has to be some compelling reason to do this.
Why aren't people _always_ making caches run at the same speed as registers; after all it should just be an issue of shrinking the feature size, right ?
And while you point out correctly that changing the number of pipeline stages wont help a single instruction make it through faster, pipelining has always been about amortizing the cost of the entire pipeline over as many instructions as possible, so the single instruction case isn't really relevant.
The other advantage of increasing the number of stages is that it _does_ allow a clock speed increase. All other things equal, one instruction still takes the same amount of time, but if you double the pipeline length and then double the internal clock, a million instructions take about half the time as they used to.
Finally, it should be pointed out that a given design has a realistic feature-size range and mhz range. Right now the p4 is in a spot where its featuresize and mhz are _below_ the "break even" point for the architectual complexity it introduces over the PIII/athlon. But the P4 only has to hit 2.5ghz before its 20 stage pipeline is "as good" for a single instruction as a 10-stage PIII at 1.25ghz. There of course is no doubt that hte P4 will hit 2.5ghz. And remember, the entire time intel is shrinking feature size and cranking clock rate on the P4, the total instructions completed in unit time is rising.
So the "sweet spot" ghz and feature size for the P4 architecture haven't been reached yet. Until they are, expect the P4 to comparatively dissappoint. But dont expect a PIII or Athlon to ever reach 2ghz.
They don't mention any sort of range. They also dont say if it requires line of sight, although since its an 802.11 family standard, I would have to assume that it does not. But could it _benefit_ from line of sight ?
Given that you can build LOS point-to-point microwave xcvrs and get a few kilometers out of them, how well would this lend itself to effectively making wireless DS-3s ? I know it'd be much cheaper to put up two towers pointing at each other than it'd cost to pay for a full-clock DS-3 for even 1 _month_
Nothing is said about antenna's or anything, so while its nice that they've got lots of functionality on these small chips (233 and 68 pins, iirc), if i need a big antenna it wont be a very nice device afterall.
Finally, they mentioned that the R-5M or whatever chip supported half-duplex operation. Is this the norm in wireless ? A 54mbps half-duplex pipe seems like it could be a lot better on paper than in practice.
It's a good thing the TeX vs LaTeX war is taking up too many resources, otherwise the "*TeX* gestapo might be paying you a visit for suggesting there _could possibly maybe in the future_ be some other way to think of expressing mathematical ideas electronically or on paper.
I for one will stick with TeX/LaTeX. Saying that TeX is obfuscated/obsolete makes me think you've never used it (successfully):)
I would support a TeX->MathML "renderer", but TeX in and of itself is faultless imo:)
That the transmeta chip has some vliwish elements in it is merely an implementation detail. 95% of software will use the code morphing layer, and not know what chip is underneath.
This is 1) good 2) important.
When you compile natively to a VLIW, you completely lose all binary compatability. If a pipeline length changes, if the number of EU's change, if _anything_ about the implementation of the processor changes - your binaries break. All of them.
Once intel moves to a VLIW architecture, evolutionary changes from 486->pentium, pentium->ppro are no longer possible. Each of these represented new EUs being added or pipeline changes.
The transmeta approach is different. Instead of breaking all the software for a new transmeta chip, you just change hte code morphing layer for the underlying physical processor. THe user-level (and emulated OS level) stuff never really knows the difference - it just runs (presumably) faster.
Of course, stuff running natively against transmeta chips will break, but it is expected this will be a small amount of software. If its just the linux kernel, it wont even matter - people tend to build kernels alot more often than transmeta releases chips:)
It will be a shame if transmeta doesn't make it in the market. They've got a lot more big names and big brains than linus, and for reasons i mentioned above, they do actually have a solid advantage over intel's strategy going forward.
The DC piracy groups use a cable that lets you connect a DC to the Neo Geo Pocket color, iirc.
The hack on that interface a bit to get something that they can suck data off the disc with, but only the DC can actually read a GD Rom disc directly.
Once they have the data off of it, its a matter of packaging it correctly. My understanding is that the DC "piracy" scene is possible because of a developer functionality left in the DC. If memory serves, you can put non-protected DC software on the second session of a normal CDrom and the DC will load it. If you've ever burnt a dc game, you'll notice that its a 2 session disc, and the 2nd one is where the bulk of the data goes:)
Packaing of the games is furhter complicated by the size differences between GDRom and CDRs. For games bigger than 80 minute CDs , they usually downsample all the audio and video sequences, or sometimes elminate the video sequences completely. This sometimes requires changes to the actual compiled code of the game.
The groups that do this sort of "repackaging" of up to 1.2gb games into 700mb or so are quite talented. And because the original game content is modified, there is still value in owning the legitimate game. If you want the real music and real videos, you're often stuck for jusy paying for the damn thing.
At any rate, the 3d power of the dreamcast is not phenominal. Your GF2 GTS frankly destroys the capabilities of the DC. Some of the DC games im sure most definitely put it to shame, but that has nothing to do with the capabilities of your PC hardware, and everything to do with the talent/design goals of the software developres for the game in question. iirc, the DC uses the NEC powerVR chipset. It's peak poly rate is something like 3 or 6 or 9 million / sec - much lower than the 31million claimed by nVidia for the GF2 GTS ultra.
Moving along, the DC does _not_ run a slimmed down versino of windows CE. To ease game development, sega did a Windows CE HAL for the dc hardware. So, if you want, you can write a game using Windows CE for theoretically much shorter dev time, and if its aport from a PC game, it should allegedly be easier. I think the native OS for the DC is called "Shinobi" or something along those lines, but Windows CE inclusion is purely up to the developer. Sega Rally 2 is a CE game - most games are not. Sega Rally 2 has serious fill-in and frame rate problems, some alledge that this is because of CE although I'd have no intelligent way of saying yes or no on that:)
As far as sega getting out of hardware development - maybe. But they just released (or was it previewed ?) their Naomi II arcade board. Sega makes some of the best games anywhere so if they go to a purely software route, it might be a good move.. The profits are wider when you're not taking a loss on the box:)
what are you talking about?! Do you own any console machines ?
Was playstation development opened ? DC development ?
There are lots of non-licensed kids developing SNES,N64, PSX, and now even DC software. The specs on these machines are by no means open. What does sony stand to benefit from opening up the specs ? NOTHING - except they wont get to charge licensing fees to people that want to develop for the platform, which is where they'll make all their money since usually console makers take a loss on the console hardware itself.
The X-box _behind_ in terms of performance ? What part of the PSX2 can touch 64mb of ram, >700mhz CPU, and something nVidia hasn't even gotten finished making yet ?
The X-box is doing _many_ things right. For one, ethernet. I am frankly pissed off that dreamcast has this great multi-player and online capability but i have to use their stupid 56k modem to do it.
Secondly, they're re-using commodity stuff. This is a huge cost win. No goofy cpu to learn. No goofy graphics chip to learn. No new quirky development tools. Run of the mill DVD drive.
It will have many of hte advantages of a PC - cheap, extremely powerful, well understood _everything_, easy to develop for.
It _wont_ have the main disadvantage of a PC - hardware variation.
If you can come up with _anything_ to substantiate your claims that the x-box will be
1) slower than PSX2
or
2) expensive (especially because of PC parts!)
Erm. I'm sure you know that most professional drivers turn off things like traction control when doing hot laps, as they _can_ outperform the computer. One of the only automotive systems that seems to be better/faster than "human intervention" is Ferrari's F1 derived shift-plate transmission. Computer controlled clutch can complete a gear change - complete with rev matching in.125 seconds. Thats extremely fast:)
Ferrari's driver ran faster in the F360 with the shift plates than he did using the normal manual gearbox.
fwiw, SPARC chips have "register windows" which save you from pushing/popping them all to the stack across calls. Instead, you just do a window-shift. You only have to put the registers to ram in the event you have a "window overflow" (there are no more register "sets" left)
This is of course all within a process. SPARC cpus also have somethign called "hardware contexts", which I unfortuneately haven't read much on, but my assumption is that these are different from the register windows and provide some sort of optimization for context switching in the metal.
Cache _latency_ is the important point. Bandwidth is nice, but its latency that kills you. Super pipelining is _defined_ as having a clock freq faster than the tiem to retreive from L1 cache. If you've got an L1 thats running at 1/2 your pipeline speed, essentially for every l/s you've got 1 extra cycle before the result can be used in the BEST CASE (l1 hit). That effectively means you'd need something like:
Load x
NOOP
do something with x
of course, this sucks, and so controllers try and do reordering and alll that other shit they do now just to get around all the delays incurred by having the memory subsystem so vastly slower than the cpu.
The obnoxious tricks required to get the processor to not spend all of its time stalling have contributed to the bloat of the RISC controller logic, so much so that there really aren't RISC chips any more - they're all complex and nasty and the controllers are responsible.
This is the appeal of LIW and/or VLIW. Force the compiler to handle all instruction ordering, all data hazards, and all pipeline delay issues. The cpu controller gets much much simpler and the cpu gets that much faster, not to mention you get the benefit of having _lots_ of EUs instead of just the few (1-4, an IBM chip has 6) you're limited to in a superscalar when you're resolving all these issues real-time in the controller
Mac OS X is more or less nextstep/openstep. Some things have been updated, somethings added, and some removed.
The windowing system on OS was "WindowServer". It natively rendered postscript. It's analagous to the Xserver, and the Xserver using the Xlib protocol to be its base set of functionality.
In OSX, they ditched postscript as the imaging model and went iwth "Quartz" which is more or less PDF. This lets them get away from wholly-adobe owned code.
people that want to speculate intelligently about OS X should have done at least one of the two following things:
You are 100% wrong. SunOS supporst dyanamic modules. Solaris supports them even better. The solaris module system, from a usability point of view is fantastic. The reason you didn't know solaris had a module system is because it always works and never fucks up (unlike, say, the linux module system.)
try these on a sunbox:
modinfo
modload
modunload
(iirc... they're there but i dont have a sun handy to verify the exact names of the commands:)
fwiw, damn near evreything is dynamically loaded on solaris. by default on my sun4m SS10/612, there are nearly 100 modules loaded.
VLIW was done over 20 years ago. Try looking at the AP-120B. "Trace" scheduling and other advanced techniques were being used on full-fleged microprocessors while intel was still dicking around with 4004s. In general, though, compilers were not smart enough to make them effective. doing manual software pipelining isn't fun or time-effective.
Fast forward to now. Now that RISC compilers are so bright, and the control section is taking up so much die on your average "RISC" chip to make it arse-slow anyway, VLIW is again worth considering. Making the CPU dynamically extract ILP is now too complex to allow the CPUs to scale up the clock. Enter the Mips R10k. Amazing at its introduction, but never even doubled its introductory clock rate over its life cycle.
Also. The intel chip is _not_ a VLIW chip. LIW, perhaps. There are previous VLIW designs that used > 1000 bit instructions with dozens if not hundreds of execution units. The Intel chip has nowhere near this many.
Intel _is_ doing something smart. Moving the scheduling code to the compiler where it can be made infinitely smart and as slow as necessary, is a good thing for performance.
However, there are drawbacks. Adding EUs breaks binaries (and compilers). Changing pipeline length breaks binaries (and compilers). The compiler on a LIW (or VLIW) is absolutely intimiately tied to the microarchitecture of the CPU. If any of the details of pipelining, EU type, resource numbers, or timeing are changed, everything breaks. Thats not just compilers, thats existing code. Get ready for a recompilation nightmare - theres almost no binary compatability once you change anything significant.
It's easy to see why this is the case; with a x86 chip today, you stuff it some instructions, it figures out how to schedule them and manages all resource conflicts for you.
With the new intel chip, the compiler will be doing all of this. "At stage 1, this instruction will be on EU0, this will be on EU1.... this will be on EUn." "The instruction package is 128 bits long. At stage k, each of these sub-instructions are still not creating any hazards because I knew how the eu's were pipelined when i made the instruction packge.
So if you add another EU, its going to need a slot in the instruction package -> the 128bit size goes up, or some other amount of that space gets shrunk. There goes binary compatability. If the pipeline lengths are changed, then the load/store/branch slot delays may change. There goes your scheduling for the next n instrucation packages.
LIW/VLIW isn't a silver bullet. There is never a silver bullet. Think of it as more as a necessary evolution as controllers take up more and more precious die space on cpus.
Real compilers (read: non gcc) have been cranking out MT code automatically for years. Suns and SGI's C and Fortran compilers both do this. I'd have to imagine other UNIX vendor compilers also do.
The point of porting is you get a useful UI. One that is consistant, and inherits years and years of UI research.
Aqua may look neat. But Mac OS X is more or less OpenStep. Re-skinning the widgets and adding alpha blending to everything is a neat refresh, and moving hte menus/dock around are probably necessary from apples perspective to make it not so next-ish.. but iirc both of those design changes are things that can be undone... probably with dread/dwrites (next's resource management tools for those that want to poke underneath the GUI)
Most GUIs ontop of UNIX oses suck ass. Nextstep was a notable exception. Consitant, well designed, good object model.
Lots of people would be happy with that. Of course, it's really hard to pull off. IBM makes UDB2 for NT clusters and SP machines. I don't konw if its "fully distributed" or not, but I want to say that it is.
It's tricky enough to design file-systems that are properly distributed. I did some design for a school thesis for a serverless distributed file-system with useful fault tolerance features. Thats pretty tricky in and of itself, even to support UNIX file-semantics. Building on something like that to build a strong and safe RDBMS would be quite a feat.
People _really_ like the single-machine programming paradigm. The OS at every level needs to emulate that behavior as much as possible, regardless of the reality of the situation. Hence, the need for a good file-system. (see Berkely xFS for the right approach, or Centravision for a shipping product looks interesting). RDBMS are already choked by locking algorithms and contention on SINGLE CPU machines. It should be no surprise that a fast RDBMS that is fully distributed and scalable isn't widely available. To do it right you've got to have transparent internal replication of basially everything. Not just data and meta-data, but even logic. Coming up with a serverless (and thus usefully scalable) scheme that gives strong enough guarantees for RDBMS applications yet still survives and survives corectly and quickly and doesn't bog down the system with locking will be quite a feat for whoever manages to do it.
You of course wont have to do with this REAL hardware. If you have a faulty C-brick, disable its resources, or partition it off, and then power it down. The rest of the ram/cpus operate normally. No rebooting required.
FWIW, the O3k qualifies as "real hardware". Redundancy. What a beautiful thing.
One process with 512 _threads_ will do _really_ well. No one else ships a single memory image computer anywhere near this big. They can't. SGI took the R&D hit early with the O2k, adopted from the Stanford DASH machine. IRIX took the complexity hit early with 6.4 to improve concurrency/lock granularity.
Now they ship this monster. For large problems, No OS can touch IRIX, and no hardware can touch this. For people wanting to make the "clusters are better argument", well, if you happen to have the small variety of problem thats "clusterizable", this thing will run those too, and quite well. Furthermore, you can always cluster a bunch of these guys together for _thousands_ of cpus and _terabytes_ of ram... and it will all be using interconnects a shit of a lot faster than what you can get elsewhere.
Finally, if you pay attention, you'll see that the whole thing is totally modular. It doesn't have to run MIPS cpus. You can yank the C-bricks and throw in an IA-64 c-brick (sometime in the future). It's _NOT_ a MIPS-based architecture. It's a modular supercomputing platform.
SGI has done their homework adopting the lessons learned in DASH (and later FLASH). As a result they've got the most scalable real-world-useful computer there is.
The pitfall of large scale opensource development is that you get a product that has difficulty maintaining singular focus.
Furthermore, there aren't a million eyes and hands working on the linux kernel, i'd say there are less than a thousand, but thats just a guess. Assuming everyone that uses linux codes is simply false. Kernel coding is even more false. Even so, you've already got Alan making his own patches that tend to be more anticipated than the "real" releases linus likes. Not to mention the gaping holes in linux where developers never had the inclination to implement those things they did not use/need.
Linux is a good idea, and linux on sparc is even a good idea. For one thing, Sun loves to EOL cheap hardware. Linux will run on all sorts of handy sun equipment that Solaris no longer runs on.
However, convincing sun to dump solaris would be 1) difficult 2) stupid. People that think linux can eliminate Solaris today either dont know much about solaris or are just plain zealots. (or both). A few of the people in the sparclinux community love to slander solaris all day long, but until dbri and Sunvideo are even _supported_, solaris is still better even as a _workstation_ OS, if you happen to have an SS10 or LX.
Furthermore, for those machines having >1 CPU, solaris simply wins. The kernel granularity is better and the userland interface (solaris threads / pthreads) is better.
Hopefully what will happen is the release of the solaris code will be sort of a cross-training event. There are some things in solaris that sun should definitely take care of, but doesn't because of their priorities. Likewise, there are some things solaris does really well that linux really out to take a look at. Hopefully both operating systems will improve. The zealots on both sides (there _are_ Sun zealots, beleive it or not:) will continue to FUD around no matter what happens.. meanwhile everyone else can benefit.
Yes.. they'll still be licensing software tradionally, and enterprises will be able to setup their own information clouds etc.. furthermore, using SOAP, those clouds will be interoperable with other web services..
.. or thats the claim, anyhow:)
part of.net is pervasive data availability. ASPs will be required to provide this.. as well as the second peice.. pervasive application availability..
Slashdot Mirror
The "short long" is a popular haircut amongst professional wrestlers, primadonna soccer players, and residents of Indiana.
(buzzed on the top, but long in the back)
As such, it should not be used in C/C++
Only the ignorant do.
Self respecting BMW owners know the difference.
Let me guess, This was a 535i _auto_
and while we're at it.. the site has some pretty obvious flaws... to bmw fanatics :)
:)
it refers to a 535i with a "nickel" block. This is most likely referring to the Nikasil alloy used in the 530 and 540 engines in the E34 5 series (5 series models 89-95). The 530 and 540 are both V8s that originally used Nikasil alloy.. while the 535i was the legendary M30 based inline 6 motor and had no such problems (and indeed usually lasts well into the 200k mile range).
If the car was ineed a 535i, its engine had no such problem. If the car was really a 530, and did have an effected nikasil block, then depending on mileage, the block could have perhaps been replaced under warranty. Finally, there is no guarantee that a nikasil laden engine will exhibit the particular problem so trading in a car based on heresey from someone else seems kinda foolish
furthermore, "beamer" is a misnomer. Dumb as it sounds, BMWs with 4 wheels (i.e. cars) are "bimmers", while the BMW motorcycle heritage (which i might add is much older than the automobile side) produces the "beemers".
as a 2 time BMW owner, i'd have to agree. No rich brat should be without a new BMW....It's important that rich idiots buy brand new BMWs as status symbols, so BMW AG can afford to make the cars fun and worthwhile for legitimate auto enthusiasts. As long as soccer moms are buying V8 X5's and 750iLs and the whole paralegal crowd is paying too much for the 3er and 530, i can continue to expect to pick up a used one and drive it the way it was meant to be driven...for pennies on the original cost.
If what you say is true, then i should be able to take an R3000 and with a sufficiently small die size and make it go 3 ghz.
But I can't. If I could do that, why did SGI break the elegance of the R3k when they introduced the R4k ? The 4400 ? The un-scalable R10k ?
Remember, when you add more pipeline stages, the amount of effort you put into designing the stage, and the amount of effort you put into designing the interlocking, goes up. You pay a much higher penalty on _every_ instruction that deals with memory ( on the x86 this is quite a lot of them). There has to be some compelling reason to do this.
Why aren't people _always_ making caches run at the same speed as registers; after all it should just be an issue of shrinking the feature size, right ?
And while you point out correctly that changing the number of pipeline stages wont help a single instruction make it through faster, pipelining has always been about amortizing the cost of the entire pipeline over as many instructions as possible, so the single instruction case isn't really relevant.
The other advantage of increasing the number of stages is that it _does_ allow a clock speed increase. All other things equal, one instruction still takes the same amount of time, but if you double the pipeline length and then double the internal clock, a million instructions take about half the time as they used to.
Finally, it should be pointed out that a given design has a realistic feature-size range and mhz range. Right now the p4 is in a spot where its featuresize and mhz are _below_ the "break even" point for the architectual complexity it introduces over the PIII/athlon. But the P4 only has to hit 2.5ghz before its 20 stage pipeline is "as good" for a single instruction as a 10-stage PIII at 1.25ghz. There of course is no doubt that hte P4 will hit 2.5ghz. And remember, the entire time intel is shrinking feature size and cranking clock rate on the P4, the total instructions completed in unit time is rising.
So the "sweet spot" ghz and feature size for the P4 architecture haven't been reached yet. Until they are, expect the P4 to comparatively dissappoint. But dont expect a PIII or Athlon to ever reach 2ghz.
They don't mention any sort of range. They also dont say if it requires line of sight, although since its an 802.11 family standard, I would have to assume that it does not. But could it _benefit_ from line of sight ?
Given that you can build LOS point-to-point microwave xcvrs and get a few kilometers out of them, how well would this lend itself to effectively making wireless DS-3s ? I know it'd be much cheaper to put up two towers pointing at each other than it'd cost to pay for a full-clock DS-3 for even 1 _month_
Nothing is said about antenna's or anything, so while its nice that they've got lots of functionality on these small chips (233 and 68 pins, iirc), if i need a big antenna it wont be a very nice device afterall.
Finally, they mentioned that the R-5M or whatever chip supported half-duplex operation. Is this the norm in wireless ? A 54mbps half-duplex pipe seems like it could be a lot better on paper than in practice.
It's a good thing the TeX vs LaTeX war is taking up too many resources, otherwise the "*TeX* gestapo might be paying you a visit for suggesting there _could possibly maybe in the future_ be some other way to think of expressing mathematical ideas electronically or on paper.
:)
:)
I for one will stick with TeX/LaTeX. Saying that TeX is obfuscated/obsolete makes me think you've never used it (successfully)
I would support a TeX->MathML "renderer", but TeX in and of itself is faultless imo
Well, i mentioned linux running natively because its been rumoured that linus might do that, to get the last bit of performance out of the system.
But yeah, for now you'd be running linux for i386 ontop of the code morphing layer.
They have already beaten the VLIW problem.
:)
That the transmeta chip has some vliwish elements in it is merely an implementation detail. 95% of software will use the code morphing layer, and not know what chip is underneath.
This is 1) good 2) important.
When you compile natively to a VLIW, you completely lose all binary compatability. If a pipeline length changes, if the number of EU's change, if _anything_ about the implementation of the processor changes - your binaries break. All of them.
Once intel moves to a VLIW architecture, evolutionary changes from 486->pentium, pentium->ppro are no longer possible. Each of these represented new EUs being added or pipeline changes.
The transmeta approach is different. Instead of breaking all the software for a new transmeta chip, you just change hte code morphing layer for the underlying physical processor. THe user-level (and emulated OS level) stuff never really knows the difference - it just runs (presumably) faster.
Of course, stuff running natively against transmeta chips will break, but it is expected this will be a small amount of software. If its just the linux kernel, it wont even matter - people tend to build kernels alot more often than transmeta releases chips
It will be a shame if transmeta doesn't make it in the market. They've got a lot more big names and big brains than linus, and for reasons i mentioned above, they do actually have a solid advantage over intel's strategy going forward.
Time will tell.
The DC piracy groups use a cable that lets you connect a DC to the Neo Geo Pocket color, iirc.
:)
:)
:)
The hack on that interface a bit to get something that they can suck data off the disc with, but only the DC can actually read a GD Rom disc directly.
Once they have the data off of it, its a matter of packaging it correctly. My understanding is that the DC "piracy" scene is possible because of a developer functionality left in the DC. If memory serves, you can put non-protected DC software on the second session of a normal CDrom and the DC will load it. If you've ever burnt a dc game, you'll notice that its a 2 session disc, and the 2nd one is where the bulk of the data goes
Packaing of the games is furhter complicated by the size differences between GDRom and CDRs. For games bigger than 80 minute CDs , they usually downsample all the audio and video sequences, or sometimes elminate the video sequences completely. This sometimes requires changes to the actual compiled code of the game.
The groups that do this sort of "repackaging" of up to 1.2gb games into 700mb or so are quite talented. And because the original game content is modified, there is still value in owning the legitimate game. If you want the real music and real videos, you're often stuck for jusy paying for the damn thing.
At any rate, the 3d power of the dreamcast is not phenominal. Your GF2 GTS frankly destroys the capabilities of the DC. Some of the DC games im sure most definitely put it to shame, but that has nothing to do with the capabilities of your PC hardware, and everything to do with the talent/design goals of the software developres for the game in question. iirc, the DC uses the NEC powerVR chipset. It's peak poly rate is something like 3 or 6 or 9 million / sec - much lower than the 31million claimed by nVidia for the GF2 GTS ultra.
Moving along, the DC does _not_ run a slimmed down versino of windows CE. To ease game development, sega did a Windows CE HAL for the dc hardware. So, if you want, you can write a game using Windows CE for theoretically much shorter dev time, and if its aport from a PC game, it should allegedly be easier. I think the native OS for the DC is called "Shinobi" or something along those lines, but Windows CE inclusion is purely up to the developer. Sega Rally 2 is a CE game - most games are not. Sega Rally 2 has serious fill-in and frame rate problems, some alledge that this is because of CE although I'd have no intelligent way of saying yes or no on that
As far as sega getting out of hardware development - maybe. But they just released (or was it previewed ?) their Naomi II arcade board. Sega makes some of the best games anywhere so if they go to a purely software route, it might be a good move.. The profits are wider when you're not taking a loss on the box
Development opened up ?
,N64, PSX, and now even DC software. The specs on these machines are by no means open. What does sony stand to benefit from opening up the specs ? NOTHING - except they wont get to charge licensing fees to people that want to develop for the platform, which is where they'll make all their money since usually console makers take a loss on the console hardware itself.
what are you talking about?! Do you own any console machines ?
Was playstation development opened ? DC development ?
There are lots of non-licensed kids developing SNES
The X-box _behind_ in terms of performance ? What part of the PSX2 can touch 64mb of ram, >700mhz CPU, and something nVidia hasn't even gotten finished making yet ?
The X-box is doing _many_ things right. For one, ethernet. I am frankly pissed off that dreamcast has this great multi-player and online capability but i have to use their stupid 56k modem to do it.
Secondly, they're re-using commodity stuff. This is a huge cost win. No goofy cpu to learn. No goofy graphics chip to learn. No new quirky development tools. Run of the mill DVD drive.
It will have many of hte advantages of a PC - cheap, extremely powerful, well understood _everything_, easy to develop for.
It _wont_ have the main disadvantage of a PC - hardware variation.
If you can come up with _anything_ to substantiate your claims that the x-box will be
1) slower than PSX2
or
2) expensive (especially because of PC parts!)
i'd love to hear about it.
It's not vapour. It exists, it runs, and people are developing for it, today.
.NET runtime, just like the other .NET products.
Furthermore, C# has been (or will be) submitted to ECMA.
Finally, C# doesn't have its own runtime. It uses the
Erm. I'm sure you know that most professional drivers turn off things like traction control when doing hot laps, as they _can_ outperform the computer. One of the only automotive systems that seems to be better/faster than "human intervention" is Ferrari's F1 derived shift-plate transmission. Computer controlled clutch can complete a gear change - complete with rev matching in .125 seconds. Thats extremely fast :)
Ferrari's driver ran faster in the F360 with the shift plates than he did using the normal manual gearbox.
Funny you should bring up SPARC processors.
fwiw, SPARC chips have "register windows" which save you from pushing/popping them all to the stack across calls. Instead, you just do a window-shift. You only have to put the registers to ram in the event you have a "window overflow" (there are no more register "sets" left)
This is of course all within a process. SPARC cpus also have somethign called "hardware contexts", which I unfortuneately haven't read much on, but my assumption is that these are different from the register windows and provide some sort of optimization for context switching in the metal.
Cache _latency_ is the important point. Bandwidth is nice, but its latency that kills you. Super pipelining is _defined_ as having a clock freq faster than the tiem to retreive from L1 cache. If you've got an L1 thats running at 1/2 your pipeline speed, essentially for every l/s you've got 1 extra cycle before the result can be used in the BEST CASE (l1 hit). That effectively means you'd need something like:
Load x
NOOP
do something with x
of course, this sucks, and so controllers try and do reordering and alll that other shit they do now just to get around all the delays incurred by having the memory subsystem so vastly slower than the cpu.
The obnoxious tricks required to get the processor to not spend all of its time stalling have contributed to the bloat of the RISC controller logic, so much so that there really aren't RISC chips any more - they're all complex and nasty and the controllers are responsible.
This is the appeal of LIW and/or VLIW. Force the compiler to handle all instruction ordering, all data hazards, and all pipeline delay issues. The cpu controller gets much much simpler and the cpu gets that much faster, not to mention you get the benefit of having _lots_ of EUs instead of just the few (1-4, an IBM chip has 6) you're limited to in a superscalar when you're resolving all these issues real-time in the controller
Mac OS X is more or less nextstep/openstep. Some things have been updated, somethings added, and some removed.
The windowing system on OS was "WindowServer". It natively rendered postscript. It's analagous to the Xserver, and the Xserver using the Xlib protocol to be its base set of functionality.
In OSX, they ditched postscript as the imaging model and went iwth "Quartz" which is more or less PDF. This lets them get away from wholly-adobe owned code.
people that want to speculate intelligently about OS X should have done at least one of the two following things:
1) used Mac OS X
2) used Openstep and/or Nextstep
You are 100% wrong. SunOS supporst dyanamic modules. Solaris supports them even better. The solaris module system, from a usability point of view is fantastic. The reason you didn't know solaris had a module system is because it always works and never fucks up (unlike, say, the linux module system.)
:)
try these on a sunbox:
modinfo
modload
modunload
(iirc... they're there but i dont have a sun handy to verify the exact names of the commands
fwiw, damn near evreything is dynamically loaded on solaris. by default on my sun4m SS10/612, there are nearly 100 modules loaded.
You are wrong.
VLIW was done over 20 years ago. Try looking at the AP-120B. "Trace" scheduling and other advanced techniques were being used on full-fleged microprocessors while intel was still dicking around with 4004s. In general, though, compilers were not smart enough to make them effective. doing manual software pipelining isn't fun or time-effective.
Fast forward to now. Now that RISC compilers are so bright, and the control section is taking up so much die on your average "RISC" chip to make it arse-slow anyway, VLIW is again worth considering. Making the CPU dynamically extract ILP is now too complex to allow the CPUs to scale up the clock. Enter the Mips R10k. Amazing at its introduction, but never even doubled its introductory clock rate over its life cycle.
Also. The intel chip is _not_ a VLIW chip. LIW, perhaps. There are previous VLIW designs that used > 1000 bit instructions with dozens if not hundreds of execution units. The Intel chip has nowhere near this many.
Intel _is_ doing something smart. Moving the scheduling code to the compiler where it can be made infinitely smart and as slow as necessary, is a good thing for performance.
However, there are drawbacks. Adding EUs breaks binaries (and compilers). Changing pipeline length breaks binaries (and compilers). The compiler on a LIW (or VLIW) is absolutely intimiately tied to the microarchitecture of the CPU. If any of the details of pipelining, EU type, resource numbers, or timeing are changed, everything breaks. Thats not just compilers, thats existing code. Get ready for a recompilation nightmare - theres almost no binary compatability once you change anything significant.
It's easy to see why this is the case; with a x86 chip today, you stuff it some instructions, it figures out how to schedule them and manages all resource conflicts for you.
With the new intel chip, the compiler will be doing all of this. "At stage 1, this instruction will be on EU0, this will be on EU1.... this will be on EUn." "The instruction package is 128 bits long. At stage k, each of these sub-instructions are still not creating any hazards because I knew how the eu's were pipelined when i made the instruction packge.
So if you add another EU, its going to need a slot in the instruction package -> the 128bit size goes up, or some other amount of that space gets shrunk. There goes binary compatability. If the pipeline lengths are changed, then the load/store/branch slot delays may change. There goes your scheduling for the next n instrucation packages.
LIW/VLIW isn't a silver bullet. There is never a silver bullet. Think of it as more as a necessary evolution as controllers take up more and more precious die space on cpus.
Real compilers (read: non gcc) have been cranking out MT code automatically for years. Suns and SGI's C and Fortran compilers both do this. I'd have to imagine other UNIX vendor compilers also do.
The point of porting is you get a useful UI. One that is consistant, and inherits years and years of UI research.
Aqua may look neat. But Mac OS X is more or less OpenStep. Re-skinning the widgets and adding alpha blending to everything is a neat refresh, and moving hte menus/dock around are probably necessary from apples perspective to make it not so next-ish.. but iirc both of those design changes are things that can be undone... probably with dread/dwrites (next's resource management tools for those that want to poke underneath the GUI)
Most GUIs ontop of UNIX oses suck ass. Nextstep was a notable exception. Consitant, well designed, good object model.
It's tricky enough to design file-systems that are properly distributed. I did some design for a school thesis for a serverless distributed file-system with useful fault tolerance features. Thats pretty tricky in and of itself, even to support UNIX file-semantics. Building on something like that to build a strong and safe RDBMS would be quite a feat.
People _really_ like the single-machine programming paradigm. The OS at every level needs to emulate that behavior as much as possible, regardless of the reality of the situation. Hence, the need for a good file-system. (see Berkely xFS for the right approach, or Centravision for a shipping product looks interesting). RDBMS are already choked by locking algorithms and contention on SINGLE CPU machines. It should be no surprise that a fast RDBMS that is fully distributed and scalable isn't widely available. To do it right you've got to have transparent internal replication of basially everything. Not just data and meta-data, but even logic. Coming up with a serverless (and thus usefully scalable) scheme that gives strong enough guarantees for RDBMS applications yet still survives and survives corectly and quickly and doesn't bog down the system with locking will be quite a feat for whoever manages to do it.
You of course wont have to do with this REAL hardware. If you have a faulty C-brick, disable its resources, or partition it off, and then power it down. The rest of the ram/cpus operate normally. No rebooting required.
FWIW, the O3k qualifies as "real hardware".
Redundancy. What a beautiful thing.
One process with 512 _threads_ will do _really_ well. No one else ships a single memory image computer anywhere near this big. They can't. SGI took the R&D hit early with the O2k, adopted from the Stanford DASH machine. IRIX took the complexity hit early with 6.4 to improve concurrency/lock granularity.
Now they ship this monster. For large problems, No OS can touch IRIX, and no hardware can touch this. For people wanting to make the "clusters are better argument", well, if you happen to have the small variety of problem thats "clusterizable", this thing will run those too, and quite well. Furthermore, you can always cluster a bunch of these guys together for _thousands_ of cpus and _terabytes_ of ram... and it will all be using interconnects a shit of a lot faster than what you can get elsewhere.
Finally, if you pay attention, you'll see that the whole thing is totally modular. It doesn't have to run MIPS cpus. You can yank the C-bricks and throw in an IA-64 c-brick (sometime in the future). It's _NOT_ a MIPS-based architecture. It's a modular supercomputing platform.
SGI has done their homework adopting the lessons learned in DASH (and later FLASH). As a result they've got the most scalable real-world-useful computer there is.
The pitfall of large scale opensource development is that you get a product that has difficulty maintaining singular focus.
:) will continue to FUD around no matter what happens.. meanwhile everyone else can benefit.
Furthermore, there aren't a million eyes and hands working on the linux kernel, i'd say there are less than a thousand, but thats just a guess. Assuming everyone that uses linux codes is simply false. Kernel coding is even more false. Even so, you've already got Alan making his own patches that tend to be more anticipated than the "real" releases linus likes. Not to mention the gaping holes in linux where developers never had the inclination to implement those things they did not use/need.
Linux is a good idea, and linux on sparc is even a good idea. For one thing, Sun loves to EOL cheap hardware. Linux will run on all sorts of handy sun equipment that Solaris no longer runs on.
However, convincing sun to dump solaris would be 1) difficult 2) stupid. People that think linux can eliminate Solaris today either dont know much about solaris or are just plain zealots. (or both). A few of the people in the sparclinux community love to slander solaris all day long, but until dbri and Sunvideo are even _supported_, solaris is still better even as a _workstation_ OS, if you happen to have an SS10 or LX.
Furthermore, for those machines having >1 CPU, solaris simply wins. The kernel granularity is better and the userland interface (solaris threads / pthreads) is better.
Hopefully what will happen is the release of the solaris code will be sort of a cross-training event. There are some things in solaris that sun should definitely take care of, but doesn't because of their priorities. Likewise, there are some things solaris does really well that linux really out to take a look at. Hopefully both operating systems will improve. The zealots on both sides (there _are_ Sun zealots, beleive it or not
Win 2k is not a platform requirement for .net
any SOAP (read: XML) enabled webserver platform will work
Yes.. they'll still be licensing software tradionally, and enterprises will be able to setup their own information clouds etc.. furthermore, using SOAP, those clouds will be interoperable with other web services..
:)
.net is pervasive data availability. ASPs will be required to provide this.. as well as the second peice.. pervasive application availability..
.. or thats the claim, anyhow
part of