Umm - A/UX supported System 5 and FFS (UFS) file systems - I suspect you probably mean the (somewhat overblown) filesystem partitioning stuff that wass added so that you could dual boot MacOS and A/UX. The A/UX experience was great - looked like a mac, worked like a mac, was unix underneath (system V with BSD networking).... but you could pop up a console window at any time - or run an X server and have X apps as well as the Mac ones - sadly Apple seemed to treat it as a check-off item (hardware was required to be able to run system V at the time in order to participate in a lot of govt contracts) and didn't really develop/suport it thru the MacOS 7 transition - a real pity because they could have started this whole transition to a protected OS a decade earlier rather than all the false sarts they've suffered since.
(PS: I'm biased - I worked on it, and still have a box that runs it - and proudly wear the "A/UX Users Group 10th annual meeting" T-shirt I got earlier this year)
It is... think about it every person who read the Xenu story now knows Scientology as "that nutty space alien cult who run around in sailor suits who beleive we're all haunted by space aliens" -/. gets read by how many people a day? 40k? (a guess based on the number of people who bother to vote in polls) - each of those people probably have say a circle of 50 acquaintances/family/coworkers (again a guess we're going for orders of magnitude here) - so now there's maybe a quarter of a million people who are going to get told about the space aliens if they they start getting interested about Scientology - all in all I think it's a great day's work
I wondered why my DSL was running so slow today (mostly people coming in on the clamnanny link then poking around).... of course/. readers should check out: http://www.taniwha.com/nospam.jpg
I've done simulations in the past - the problem is with data stalls - they occur deep in the pipe and for a non-OO CPU you have to toss all the stuff that's partially started in the pipe, and start the new thread which takes a while - so thread switch is expensive. To make things worse it makes no sense to switch on an L1 miss - simulations say that waiting for L2 miss is a must.
Now with a superscalar/OO system things are different - you can keep partially done stuff sitting in reservation stations (but you need twice as many of them which may cost you in cycle time - which is what marketting are interested in). There's still probably a lot of serializing things around (like L2 miss). On the other hand one place you can win is with the main memory subsystem - these days you can build systems with multiple outstanding memory transactions (Rambus - no matter how people dislike it - is particularly good at potentially having many concurrent senses running in parallel) - but to be usefull you need to either move the main memory interface onto the CPU or get rid of tacky serializing buses like slot-1 (it's much better to put the memory interface on the CPU in this case because you can run the internal memory interface at a higher clock rate and be exposed to more parallelism).
Surface Mount Technology.... of course all us chip weenies think packaging when you use that TLA.
Seriously though threading like that is kind of at odds with todays very long pipelines (basicly the cost of a thread switch can be very high if you have to fill a deep pipe). With heavily out-of-order systems this can be less of a problem.... but you're still stuck with the problem that if you're using a larger percentage of the CPU's real clocks then you're going to put more pressure on shared resources like caches and TLBs - larger L1s/TLBs are going to potentially hit CPU cycle time and of course these days L2 can take a large percentage of your die size (after all the goal here is to get more usefull clocks/area)
the chip is actually achieving its theoretical fillrate. This has never happened before in the entire history of the graphics chip industry except perhaps in their previous chips.
Nah - people have designed graphics chips that hit 'perfect' fill rates before - I know I did one (for the Mac 7-8 years back) that hit 1.2Gb/sec into VRAM (then state of the art DRAM) exactly as it was designed to.
Graphics chips have a relativly long history that is at least in part driven by the comodity memory technologies they have available to them. These days we're particularly troubled - system costs are going down, DRAM speeds haven't kept pace with CPU/GPU speed increases (CPUs have maybe gone from 100MHz to 1GHz in the time that memory has gone from 66MHz to 266MHz [transfer rate - latencies have only halved]).
'Tricks' like ISS (aka tiled frame buffers) work because they basicly cache the problem - at the expense of keeping an ordered polygon list (which means that you are more sensitive to scene complexity - too many more polys than pixels and you might be in big trouble) and latency (because you can't finish the poly sort stage before you start rendering - so you have to render a complete screen at once - while maybe buffering the next scene's polys in parallel) - note I'm over simplifying the problems here to explain some of the issues - there's lots of scope for smart people to do smart things in a space like this (before all the patents are granted - then without competition inovation will probably cease:-( )
That's the recent standards.... don't forget all the previous (mostly analog) wrangling back before the TV people finally acquiesed to things like square pixels etc etc
My Dell does it in the Dos partition - I left a mimimal DOS partition around for this and made a big save-to-disk file in it - that's all you need for older BIOS's
But why use hibernate - that still has to read all the memory off the disk - since it's done in the BIOS it's OS independant - while I could use it my 3 yr old DELL/redhat/KDE system just suspends - virtual instant-on - batterys last days in suspend state (but it lives in the dock anyway when I don't use it) - only time I ever truely hibernate it is when I'm oing on a plane
AFAIK noone has released a comprehensive stress test program that attempts to stress all possible timeing paths in an inplace CPU, which is what you would have to do, since OCers don't have the timeing info worked out by the engineers.
You have to realize that it's not that simple - one thing I didn't stress as much as I should of was that often the actualy worst case paths on a chip are not the ones you think of, or expect, or even what your tools tell you about - maybe there's a noise issue at higher frequencies (that's happened to me), inductive coupling on some long wires etc etc
and worse yet in places like datapaths they may be sensitive to data patterns (maybe stressing the power/gnd grid) - this means combinatorial explosions on top of combinatorial explosions.
Another thing I didn't point out was all thge different reasons for timing failures - you can effects like the position of the die on the wafer, the day of the week the wafer started the fab (I kid you not), etc etc..... the result after all this stuff is a statistical mess - die come in all within a bell curvish sort of range you have to work to position the curve so that you can meet your revenue targets - both by yield and then by binning - pushing the yield up to get the volume at the low end (ie moving the peak of the curve so that vast majority of the parts at least yield your slower parts) may mean you make too many fast ones - it's all deeply intertwingled
this will not work for arbitrary CPUs - always read the data sheets.... some CPUs use internal dynamic nodes in things like carry chains.... and should be spec'd with a lowest freq as well as a fastest
OK - I'm a chip designer I have some experience making manufacturable chips - let me explain how this stuff works....
When you build a new chip you build software models of the entire chip - right down to the gate and polygon level, you do a LOT of timing analysis - these days we extract the polygons and do 3d parasitic extraction - this takes a long time (days for a big chip) - but the results are by their nature statistical - because the results of building a particular chip are somewhat staistical (depends on etch rates, temp, etc etc at the fab) so we calculate the worst case fast and worst case slow process corners and use the timing tools to check all the potential timing paths (thing combinatorial explosion here). After we think we have something that will make timing we build some - at the fab at the begeinning we get the fab guys to explicitly vary the process to push some wafers into each 'corner' of the process - then we bring those die into the lab and use them to make sure that they will work at speed within the various temp ranges the chip is supposed to work at.
One of the problems with making chips is that testing them is VERY expensive - the testing machines that do die and chip sorting cost millions of $$ and the number of seconds a die spends on one effects the final cost - so you design your tests to uncover raw defects (via scan and maybe functional tests) and speed problems by using the results of your original timing imulations to identify the timing paths that are so close to the edge that they are likely to fail first - because the testers don't have access to most of the internal nodes you have to do things like overclocking by say 10% and then hoping the internal logic will fail in some manner that you can catch (you also use the previous lab work to validate this approach by identifying known bad chips and making sure they fail on the tester).
One thing you can do is 'bin' chips - test them at different frequencies and sell the ones that happen to be faster for more - because binning is a more expensive process its usually only done for CPUs and other expensive sorts of chips.
What commonly happens over the lifetime of a chip is that as the process improves the number of die that fall into the faster bins increases - however for marketting reasons a company may wish to continue to sell the 'faster' ones at a premium so it will label some fast chips as 'slower' so to keep their product mix in the market (a fancy way of saying 'so they can make more money'). I'm told the same thing happens with olive oil:-)
Now the chips are vey carefully screened and carefull spec sheets are written for them - you buy an 850MHz chip from AMD or Intel and it will work at 850 within the appropriate voltage/temp range specified on the data sheet (if not as, we've seen, Intel will recall chips that don't) - it's not in the chip manufacturer's interest to sell chips that don't work - they get soldered on to expensive boards and expensive system which have to be trashed at the OEM if they don't work - those data sheets make sure that to parts in a million those chips work as advertised.
Having said that - some chips do run faster if overclocked - you can always tell which ones - because you don't know which process corner the die was fabbed at - or what the binning policies were the day it was manufactured etc etc - even worse yet - and here's my traditional warning - WARNING - your overclocked CPU may work perfectly for months because what you're doing may not exercise the slowest timing path(s) in the design (remember combinatorial explosion!) - you might play quake for months on end without a problem.... then silently drop $1000 off your tax refund....
I thought that for a contract to be valid there had to be a quid-pro-quo - either something exchanged on both sides - does the implicit 'job offer' in 'sign this or be fired' count?
In seems to me that in all fairness that if a company wants a non-compete they should pay for it - say a retainer of 30% of previous salary while it's in force - you quit company X and they don't want you to work for company Y - you don't so long as they pay you for it - they stop paying you get to work where ever you want....
1. Before MS came along, computers were unaffordable. Now we all reap the benefits of a computer in every home.
While this is true it doesn't mean that M$ is responsible - in fact I think you're confusing cause and effect - M$ simply ssupplanted the previous reigning monopoly (at time that the govt had THEM in court trying to break them up). And it wasn't because their software was cheaper - it was because the advent of the microprocessor suddenly brought the cost of a low end system from seomewhere in the tens of thousands of dollars (think PDP11) to something in the hundreds of dollars - there were other more sophisticated OSs around at the time - M$ didn't even write the original DOS.
M$ owes it's existance to the technical changes that made cheap hardware available to all of us, not the other way around
apparently for $29 if I register with them they will send a lawyer's letter on my behalf to someone else.... I hope they remember to copyright those letters..... otherwise one could just send yourself one and then resend it as much as I like for free....
(somewhat) Seriously though.... maybe it's time to set up copyleft.net to send out lawyer's letters about GPL violations.....:-)
to be fair I think they try to picket people when they're not there - less likely people will call the cops - they picketed me for doing basicly the same things as Dave when I wasn't home (but did harass my grade school kids). Apart from the kids being a bit wide eyed by the "xenu people" it was a great opportunity to tell the neighbors about the evil Co$
just walk into the mall, fire it up, and let it rip (imagine the whine from the ghostbusters backpacks followed by a really loud crackle...).... oh you wanted kids? tough....
I just don't think that RDRAM makes sense as the main memory of a general purpose computer.......
For databases which are small non-linear pieces of data, it's not.
The interesting thing to look at is the point where usefull concurrency maxes out - which is roughly the point where the data transfer time of cache line size matches the access time on a bank (this is different if you do speculative accesses) - if you assume that the memory accesses coming out the back end of the L2/L3 cache are random (not always true - but, apart from startup and context switch, simulation seems to bear this out) it's best to interleave across dram banks at a cache line granularity - this means that if you have enough concurrent banks (say 8) you can have concurrency 7/8 of the time (the difference between 16 banks 15/16 and 7/8 isn't much). However as I mentioned in my previous post if you have to send the data across a bus (slot 1 for example) that's much slower then either the memory (RDRAM clocks I mean) or CPU then you get little concurrency at the memory controller (which starts to win when it can choose between multiple concurrent transactions for the 'best one' - and it really needs 3 active transactions before this kicks in) - to make matters (here it hits latency) is when you have a bus (like slot 1, not slot A) where the memory controller must retire data back in-order - for a gross example an early transaction waiting for refresh (or any other bank conflist) will stall following transactions even though the memory subsystem might be able to retire them earlier.
Sounds like you've got a great job. I often think I was born many years too late considering I love playing with the bare metal so much.
Actually I started out as a programmer doing OS stuff (I ported Unix V6 for example:-) but I had always done some hardware stuff - I fell into chip design architecting Mac graphics accelerators - eventually it got easier to code Verilog myself than tell other people what to do.... these days chip design is very similar to normal programming - Verilog is just a wierd C - I actually think that chip design needs more designers with a software background - that hard wall between hardware groups and software groups has always seemed to me to be a real problem - there are lots of hardware software tradeoffs that don;t get done because neither group understands each other well enough.
Having said this I've actually been trying to get out of doing full-time chip-design and in to doing a lot more software design - mosstly because I find coding is much more satisfying on a day-to-day level - doing chip design you're spending maybe 10% of your time doing the cool creative stuff that's really satisfying, and 90% of your time making sure that chip is absolutely perfect when you tape out - with programming you tend to get something working every day
Slashdot Mirror
(PS: I'm biased - I worked on it, and still have a box that runs it - and proudly wear the "A/UX Users Group 10th annual meeting" T-shirt I got earlier this year)
that would be chicken manure .....
is late can't do math .... must sleep ....
It is ... think about it every person who read the Xenu story now knows Scientology as "that nutty space alien cult who run around in sailor suits who beleive we're all haunted by space aliens" - /. gets read by how many people a day? 40k? (a guess based on the number of people who bother to vote in polls) - each of those people probably have say a circle of 50 acquaintances/family/coworkers (again a guess we're going for orders of magnitude here) - so now there's maybe a quarter of a million people who are going to get told about the space aliens if they they start getting interested about Scientology - all in all I think it's a great day's work
I wondered why my DSL was running so slow today (mostly people coming in on the clamnanny link then poking around) .... of course /. readers should check out: http://www.taniwha.com/nospam.jpg
Now with a superscalar/OO system things are different - you can keep partially done stuff sitting in reservation stations (but you need twice as many of them which may cost you in cycle time - which is what marketting are interested in). There's still probably a lot of serializing things around (like L2 miss). On the other hand one place you can win is with the main memory subsystem - these days you can build systems with multiple outstanding memory transactions (Rambus - no matter how people dislike it - is particularly good at potentially having many concurrent senses running in parallel) - but to be usefull you need to either move the main memory interface onto the CPU or get rid of tacky serializing buses like slot-1 (it's much better to put the memory interface on the CPU in this case because you can run the internal memory interface at a higher clock rate and be exposed to more parallelism).
Seriously though threading like that is kind of at odds with todays very long pipelines (basicly the cost of a thread switch can be very high if you have to fill a deep pipe). With heavily out-of-order systems this can be less of a problem .... but you're still stuck with the problem that if you're using a larger percentage of the CPU's real clocks then you're going to put more pressure on shared resources like caches and TLBs - larger L1s/TLBs are going to potentially hit CPU cycle time and of course these days L2 can take a large percentage of your die size (after all the goal here is to get more usefull clocks/area)
Nah - people have designed graphics chips that hit 'perfect' fill rates before - I know I did one (for the Mac 7-8 years back) that hit 1.2Gb/sec into VRAM (then state of the art DRAM) exactly as it was designed to.
Graphics chips have a relativly long history that is at least in part driven by the comodity memory technologies they have available to them. These days we're particularly troubled - system costs are going down, DRAM speeds haven't kept pace with CPU/GPU speed increases (CPUs have maybe gone from 100MHz to 1GHz in the time that memory has gone from 66MHz to 266MHz [transfer rate - latencies have only halved]).
'Tricks' like ISS (aka tiled frame buffers) work because they basicly cache the problem - at the expense of keeping an ordered polygon list (which means that you are more sensitive to scene complexity - too many more polys than pixels and you might be in big trouble) and latency (because you can't finish the poly sort stage before you start rendering - so you have to render a complete screen at once - while maybe buffering the next scene's polys in parallel) - note I'm over simplifying the problems here to explain some of the issues - there's lots of scope for smart people to do smart things in a space like this (before all the patents are granted - then without competition inovation will probably cease :-( )
and there lies the solution - do it faster, better, cheaper, less buggier than M$ can ..... then we own it :-)
you'll have to license some big chunk-o-M$ software to do it .... plobably only runs on M$-Apache .... embrace and extend here we come ....
That's the recent standards .... don't forget all the previous (mostly analog) wrangling back before the TV people finally acquiesed to things like square pixels etc etc
IMHO the main thing that's slowed HDTV adoption has been the 1000 different standard that have been proposed/adopted over the past decade
and will that program run under Linux .... will we need a 14yr-old in Outer Mongolia to pull a couple of all nighters before we can play them?
My Dell does it in the Dos partition - I left a mimimal DOS partition around for this and made a big save-to-disk file in it - that's all you need for older BIOS's
But why use hibernate - that still has to read all the memory off the disk - since it's done in the BIOS it's OS independant - while I could use it my 3 yr old DELL/redhat/KDE system just suspends - virtual instant-on - batterys last days in suspend state (but it lives in the dock anyway when I don't use it) - only time I ever truely hibernate it is when I'm oing on a plane
You have to realize that it's not that simple - one thing I didn't stress as much as I should of was that often the actualy worst case paths on a chip are not the ones you think of, or expect, or even what your tools tell you about - maybe there's a noise issue at higher frequencies (that's happened to me), inductive coupling on some long wires etc etc and worse yet in places like datapaths they may be sensitive to data patterns (maybe stressing the power/gnd grid) - this means combinatorial explosions on top of combinatorial explosions.
Another thing I didn't point out was all thge different reasons for timing failures - you can effects like the position of the die on the wafer, the day of the week the wafer started the fab (I kid you not), etc etc ..... the result after all this stuff is a statistical mess - die come in all within a bell curvish sort of range you have to work to position the curve so that you can meet your revenue targets - both by yield and then by binning - pushing the yield up to get the volume at the low end (ie moving the peak of the curve so that vast majority of the parts at least yield your slower parts) may mean you make too many fast ones - it's all deeply intertwingled
this will not work for arbitrary CPUs - always read the data sheets .... some CPUs use internal dynamic nodes in things like carry chains .... and should be spec'd with a lowest freq as well as a fastest
the plastic package burst into flames ....
When you build a new chip you build software models of the entire chip - right down to the gate and polygon level, you do a LOT of timing analysis - these days we extract the polygons and do 3d parasitic extraction - this takes a long time (days for a big chip) - but the results are by their nature statistical - because the results of building a particular chip are somewhat staistical (depends on etch rates, temp, etc etc at the fab) so we calculate the worst case fast and worst case slow process corners and use the timing tools to check all the potential timing paths (thing combinatorial explosion here). After we think we have something that will make timing we build some - at the fab at the begeinning we get the fab guys to explicitly vary the process to push some wafers into each 'corner' of the process - then we bring those die into the lab and use them to make sure that they will work at speed within the various temp ranges the chip is supposed to work at.
One of the problems with making chips is that testing them is VERY expensive - the testing machines that do die and chip sorting cost millions of $$ and the number of seconds a die spends on one effects the final cost - so you design your tests to uncover raw defects (via scan and maybe functional tests) and speed problems by using the results of your original timing imulations to identify the timing paths that are so close to the edge that they are likely to fail first - because the testers don't have access to most of the internal nodes you have to do things like overclocking by say 10% and then hoping the internal logic will fail in some manner that you can catch (you also use the previous lab work to validate this approach by identifying known bad chips and making sure they fail on the tester).
One thing you can do is 'bin' chips - test them at different frequencies and sell the ones that happen to be faster for more - because binning is a more expensive process its usually only done for CPUs and other expensive sorts of chips.
What commonly happens over the lifetime of a chip is that as the process improves the number of die that fall into the faster bins increases - however for marketting reasons a company may wish to continue to sell the 'faster' ones at a premium so it will label some fast chips as 'slower' so to keep their product mix in the market (a fancy way of saying 'so they can make more money'). I'm told the same thing happens with olive oil :-)
Now the chips are vey carefully screened and carefull spec sheets are written for them - you buy an 850MHz chip from AMD or Intel and it will work at 850 within the appropriate voltage/temp range specified on the data sheet (if not as, we've seen, Intel will recall chips that don't) - it's not in the chip manufacturer's interest to sell chips that don't work - they get soldered on to expensive boards and expensive system which have to be trashed at the OEM if they don't work - those data sheets make sure that to parts in a million those chips work as advertised.
Having said that - some chips do run faster if overclocked - you can always tell which ones - because you don't know which process corner the die was fabbed at - or what the binning policies were the day it was manufactured etc etc - even worse yet - and here's my traditional warning - WARNING - your overclocked CPU may work perfectly for months because what you're doing may not exercise the slowest timing path(s) in the design (remember combinatorial explosion!) - you might play quake for months on end without a problem .... then silently drop $1000 off your tax refund ....
In seems to me that in all fairness that if a company wants a non-compete they should pay for it - say a retainer of 30% of previous salary while it's in force - you quit company X and they don't want you to work for company Y - you don't so long as they pay you for it - they stop paying you get to work where ever you want ....
While this is true it doesn't mean that M$ is responsible - in fact I think you're confusing cause and effect - M$ simply ssupplanted the previous reigning monopoly (at time that the govt had THEM in court trying to break them up). And it wasn't because their software was cheaper - it was because the advent of the microprocessor suddenly brought the cost of a low end system from seomewhere in the tens of thousands of dollars (think PDP11) to something in the hundreds of dollars - there were other more sophisticated OSs around at the time - M$ didn't even write the original DOS.
M$ owes it's existance to the technical changes that made cheap hardware available to all of us, not the other way around
(somewhat) Seriously though .... maybe it's time to set up copyleft.net to send out lawyer's letters about GPL violations ..... :-)
to be fair I think they try to picket people when they're not there - less likely people will call the cops - they picketed me for doing basicly the same things as Dave when I wasn't home (but did harass my grade school kids). Apart from the kids being a bit wide eyed by the "xenu people" it was a great opportunity to tell the neighbors about the evil Co$
just walk into the mall, fire it up, and let it rip (imagine the whine from the ghostbusters backpacks followed by a really loud crackle ...) .... oh you wanted kids? tough ....
The interesting thing to look at is the point where usefull concurrency maxes out - which is roughly the point where the data transfer time of cache line size matches the access time on a bank (this is different if you do speculative accesses) - if you assume that the memory accesses coming out the back end of the L2/L3 cache are random (not always true - but, apart from startup and context switch, simulation seems to bear this out) it's best to interleave across dram banks at a cache line granularity - this means that if you have enough concurrent banks (say 8) you can have concurrency 7/8 of the time (the difference between 16 banks 15/16 and 7/8 isn't much). However as I mentioned in my previous post if you have to send the data across a bus (slot 1 for example) that's much slower then either the memory (RDRAM clocks I mean) or CPU then you get little concurrency at the memory controller (which starts to win when it can choose between multiple concurrent transactions for the 'best one' - and it really needs 3 active transactions before this kicks in) - to make matters (here it hits latency) is when you have a bus (like slot 1, not slot A) where the memory controller must retire data back in-order - for a gross example an early transaction waiting for refresh (or any other bank conflist) will stall following transactions even though the memory subsystem might be able to retire them earlier.
Sounds like you've got a great job. I often think I was born many years too late considering I love playing with the bare metal so much.
Actually I started out as a programmer doing OS stuff (I ported Unix V6 for example :-) but I had always done some hardware stuff - I fell into chip design architecting Mac graphics accelerators - eventually it got easier to code Verilog myself than tell other people what to do .... these days chip design is very similar to normal programming - Verilog is just a wierd C - I actually think that chip design needs more designers with a software background - that hard wall between hardware groups and software groups has always seemed to me to be a real problem - there are lots of hardware software tradeoffs that don;t get done because neither group understands each other well enough.
Having said this I've actually been trying to get out of doing full-time chip-design and in to doing a lot more software design - mosstly because I find coding is much more satisfying on a day-to-day level - doing chip design you're spending maybe 10% of your time doing the cool creative stuff that's really satisfying, and 90% of your time making sure that chip is absolutely perfect when you tape out - with programming you tend to get something working every day