The Cyrix chips _WERE_ faster than the Pentiums on the benchmarks everyone was using when the PR system was released. The problem is that everyone started using quake (and some other benchmarks) as a benchmark which the Cyrix sucked on because they were marginally slower than the equivilant clocked pentium with some floating point operations used a lot in quake (important parts of quake were also hand optimized for the pentium U-V pipline arch, which didn't help the cyrix or the amd much). Basically, you purchased a PR166 Cyrix that ran roughtly the same as a Pentium 166 running Winstone and a couple other similar bencharks, yet it was clocked at 133Mhz. When quake came out the Cyrix got its butt kicked because it ran about the speed of a pentium 100. I still have a IBM 6x86 PR166 machine that is running linux. Keep the CPU fan running and its stable as a rock, oh, and it compiles kernels faster than my 233Mhz MMX pentium. Just don't try playing quake. A sweet machine at the time considering It cost about as much as a Pentium 75.
Yah, no crap.. but you get 128G of RAM! lol... Guess you should just make a big RAM disk.
Re:Differences between PPC G4 and Power 4 ?
on
IBM Launches p690
·
· Score: 1
There are two variants on the CPU architecture, which was co-developed by IBM and Motorola.
Accually, the PPC design is based on the early 'POWER' chips (RIOS) from IBM. Hence the Power part of the POWER Performace Computing. Now the 10k question? What does POWER stand for? Ok, Its Performace Optimized With Enhanced RISC.
Ah, don't try to use Memory mapped files under W2k either. I don't know about XP but I have a little memory mapped file application that runs about 10x faster under linux than windows. I jumped though a bunch of hoops to get it up to only about 3x slower by setting my process quota, messing with a bunch of system cache settings, etc. I don't know what the current recomendations are for IPC on w2k but long ago I started to design all my applications for a threaded model and use TCP for any real interprocess/machine communication. This gives me realitivly easy portability off of M$ productions (unlike COM).
frame frate in FPS and movies
on
2.2 GHz Xeon
·
· Score: 1
Actually, I play a lot of FPS too.. It seems the more people play quake the more their brain dies. but much over 30 fps you cannot distinguish the frame rate differences.
That said, I will agree that you need high frame rate benchmarks for quake. Preferably in the 90fps range. This isn't because you can distinguish the differences but rather because the frame rates are usually given as averages (this is why Silent Sam is cool) and those quick glances behind are the parts where the frame rate averages get pulled down. So what you really need in quake is a machine that will guarantee that the time between frames won't drop below 1/30 (or more realistically 1/40) of a second
and the frame rate differences won't be maybe 1/8 of the total.
Now there is another thing to think about, it has to do with the motion speed, relative to you field of vision. You want things that cross your field of vision to cross smoothly. This is incredibly important in quake, since you are trying to absorb all the positional information on your opponents. In these cases it seems that the frame rates actually have to increase to compensate for what I think may be an eye to frame refresh rates (I'm not an expert on this so I don't really know if i'm describing this correctly) mismatch. Contrary to what I originally thought, which was that your eye required higher frame rates to compensate for a higher level of awareness for fast moving objects, I think that you eye/brain seems to slow down the when you look at things that are crossing your vision quickly. Try moving your head right and left quickly, think about what you are seeing when you are doing that. Part of the poor information feed probably has to do with your eye being unable to focus on anything. On the other hand movies are similar to FPS in that your eye doesn't have to refocus, yet I often find that quick pans (on real film, MPEG just makes it worse) are too jerky and out of focus. Of course I often find that things I want to look at in movies are out of focus, because i'm looking at something other than the intended subject.
Basically, what I'm saying is that the 30fps figure is pretty close to what your game should be getting, I might even give you 45 or 50fps. The difference between 40 and 125 though i think is primarily an interaction with the way your game frame rates are changing between frames because there has been a lot of real research about the 'refresh' rates of the human eye and human persistance of vision.
and the salesman can tell him that the G5 runs at 2GHz, just like the new PIV machine.
Actually, according to the article the G5 is probably in a.13 copper SOI process to reach 2ghz. The P4 is a.18 aluminum process right now. Intel has shown with the >1ghz PIII that they can do.13 too so its just a short time until they die shrink the P4 at which point it probably will get another clock speed bump. I expect that by the time I see a 1.6ghz PPC the P4 will probably be 2.5 to 3 ghz with bigger caches, maybe hyperthreading etc. The point is that the P4 will still be roughly as fast if not faster than the G5, and have a bigger clock rate for the sales people.
Exponential, was fast/hot because their processors were designed using BJT technology. The reason why they were 'slow' though was because the processors were based on older PPC cores. Its sort of like making a 3 ghz classic pentium. It would probably suck. As far as exponential tech, what i understand is that early Ppro's had BJT sections. I'm not aware of any such things in the P4.
Ahhhhh, when will they learn! Why didn't they just make it 64 bits or maybe 80 bits. That way in 8 years we won't have to upgrade the damn IDE command protocol again. Christ, all the new processors have 64 bit virtual address spaces. The commonly accepted address space numbers say roughly one bit of growth a year, that means that it will take 28 years or so before we start to run out of address space again. Drive capacities are growing a little faster than that. We are at 2^37 right now, they are extending it to 2^48. Not even enough head room for the next 10 years!!!!
I just bought a bunch of 80gb 7200rpm drives for a RAID! Of course, I only paid $189 for them which makes them about the same price per meg as the 160gb drive. On the other hand, my max capacity would have been much higher.
I've had Seagate 27/30Gb 7200 RPM drives die too. On the other hand my 6 year old 7200 RPM SCSI drives are still going... It probably has little to do with the rotational speed and everything to do with quality of manufacturing.
Everyone seems to be failing to make a distinction between loosely coupled development environments and IDE's vs GUI's and CLI's. Probably because most of the IDE's are GUI.
Frankly the GUI/CLI argument is an old one. I think the answer is more a case of personal preference and what kind of job is being done. Modern GUI's, macro recorders and script languages are as powerful a method of expression as CLI's with their multitude of scripting languages.
IDE's vs Loosely coupled should be a no brainier. Its a lot nicer to be able to use a single environment that is tied together. A lot of people are arguing their emacs->make->gdb configuration is better than the assorted IDE's listed. In truth they are just reinventing the wheel with a group of CLI tools. Instead of accepting a pre packaged IDE sitting on top of command line tools like VC++ they are creating their own IDE using their favorite editor and a bunch of scripts. At that point its pretty much a no brainier that a custom environment designed for their particular project is better. Of course it probably took them three weeks to build a bunch of scripts to tie their resource editor, text editor, code browser, object browser, compiler, debugger, profiler, source control, packaging, etc tools together in a manner that is functional.
So, the real question should have been is it better to use a prebuilt IDE or build your own? The answer to this is probably that it depends on the person. Personally I prefer using VC++ but I also have a large collection of scripts that I load into Xemacs when I'm using a Unix environment that allows me to things like checkout the current module from source control and check everything back in with a keystroke, or build the project and highlight any errors in a widow smart enough to open the offending modules so that I can edit the source line with a keystroke or two. I like to use a nice source browser that allows me to instantly open a new window and go to the module where the function I'm looking at is declared. All of these things require and IDE to be optimal, its just VC++ is preconfigured and I have to remember F12 is 'goto reference' and F7 is build (unless I change the keybindings). While I have about 2k worth of scripts I wrote to do it in emacs.
Any decent macro recorder will do the same thing in windows with about 5 keystrokes and mouse events. Now try saving your results into a html table for viewing on the web. It turns out to be an ugly perl or sed script. Its just a couple more clicks and keystrokes to fire up a html editor, create a table and paste the results in and save as html. Then if you do it enough you just tie the macro to a hotkey. In the end you can do it in either the CLI or the GUI with one keystroke. It makes no diffrence in the end. The goals of GUI's are to make it eaiser to do things you don't know how to do. Everyone here is just arguing the same thing from two diffrent perspectives.
Of, course you still have to do real work! lol. I can't really imagine to many project though where a significant part of the GUI couldn't be handed by something like Borland C++ Builder. In the more recent version of BCB they have a Tframe component that removed nearly all my dependence on hand coded GUI components. There are just so many component libraries available that you can buy a component for just about any GUI widget behavior that can be thought of. About the only time I have to hand code a GUI anymore is for complex graphical rendering. Which is the real part of the application anyway. I can believe though with MFC you ended up recoding everything because its a beast and no one I know has ever managed to write much of their application using it. When the GUI's get more complicated than dialog boxes with push buttons MFC blows.
I had a friend though that ended up writing massive amounts of GUI code because he refused to write a table link or ODBC front-end to his proprietary database. In the end he just ended up rewriting nearly all the database management components included with delphi just to save a two or three day leaning curve to learn how to interface his database to the existing components. Some things cannot be forgiven... lol
The other posters have noted scripting languages. You should also look at winbatch, its more a GUI solution to a GUI problem. Basically its like an advanced macro recorder. I think it also has a script language you can use. You can just tell it to record and then do stuff in the GUI and it will capture the events for repeated playback. VC++ also has this type of stuff built in to a certain extent as long as you stay in VC.
You just don't get it.. It doesn't matter that it gets a lower IPC or is less efficient!!!!! The point is that it has a higher overall throughput because it can run at 2+ Ghz in an aluminum.18 process! Wait till it gets copper, SOI and drops to.13.
Ok, since I may not have made myself clear! Lets make up an example. Assume: that the AMD gets a normalized IPC of 1 and the P4 gets a IPC of.75 (like you argue, AMD is more efficient). Now assume that they are both manufactured in roughly the same process and the P4 can only scale to 2ghz and the AMD maxes out at 1.4ghz (actually they can probably go higher). Therefore the P4 cranks out 1.5 (2*.75) billion operations per second while the AMD can only crank out 1.4 (1.4*1) billion operations per second. Now for grins lets throw the P3 in there.. Lets say it gets an IPC of.95 and maxes out at 1 ghz. Its max throughput is.95 billion operations per second. Which CPU should Intel focus on? Efficiency isn't the name of the game right now, if it was, we would all be running 400 mhz 486's that consume.001 watts.
As far as the FPU is concerned I believe Intel made the right decision. They control the majority of the x86 market and when they make a move people follow. They obviously decided (like AMD has for the Hammer) that high performance FP that isn't compatible with the x87 is more important than mediocre x87 performance. The x87 has turned out to be a beast to optimize because it is a stack based arch. The problem with stack based FP units is that they cannot be truly superscaler. This is why the 'RISC' arch's usually beat the x86 on floating point benchmarks. Its really hard to parallize FP operations when they are all dependent on the TOS from the last operation. So, Intel's engineers made the decision to focus on SSE, assuming that people who truly cared about top of the line floating point performance would recompile their code to use SSE, those people who didn't care would continue to use the old x87 FP. The people using SSE will see a nice performace boost while the people using the x87 will see modest boosts due primarly to the increased clock rates of the new processor. This is how Intel manages to make competitive CPU's (other companies do it too), they figure out a way to make the CPU scream and maintain compatibility with older CPU's at a relatively somewhat lower performance. This is old news, its a rehash of the same discussion when the Ppro came out. Everyone bitched about how much slower it was running 16 bit code. Do you think Intel made the wrong decision releasing the P6 core? That wasn't the first time the discussion came up either. I remember the 286 vs 386 discussions where the 286 was faster doing PIO at similar clock rates. We don't seem to care about that one anymore either.
but their chips ARE designed to ramp the clock speed up at the expense of actual performance.
I call BS on this too. High clock rate processors tend to have slightly lower IPC than lower clocked processors simply because they are designed for high clock rates! You acchieve higher clock rates by increasing the number of pipeline stages (or shrinking the process). This tends to increase the average instruction latency. On the otherhand it also increases the througput per unit time. Christ, if at the end of the day the P4 is only 75% as efficient per clock than the PIII but runs at 2x the clock rate in the same process, then intel made the right decision. Its a no brainer! When intel releases the P5 and its 50% as efficient as the P4 and only runs 2x as fast in the same process then you can cry about how they are making chips just to ramp the clock rate. Till then think about what your saying before you say it.
I think the P4 and the K7 core (in their current implementation) are about the same at the end of the day. The real question of course isn't which one has a higher clock rate in a given process but which one has a higer performace. All things being equal the one with the higher clock rates will be easier to sell. On the other hand, if I were betting, as much as I like AMD, I think that Intel has a winner. The current implementation is a seriously cut down version of what the arch will eventually be. Its caches (TLB, Trace etc) are small, its missing a couple pipes, and there isn't yet a SMT version. In other words the current P4 IPC is probably 3/5 of what it will be in a generation or two. Intel proved with the Ppro/PII/PIII that their x86 CPU designers know what they are doing. From where I stand it looks like they are well on their way to a repeat.
Accually, the Cyrix FP wasn't as bad as everyone made it out to be. The problem was quake was hand optimized for the Pentium U/V pipes and the optimizations didn't do anything for the AMD or Cyrix. The result was Quake ran considerably better on the Intel even though the Intel's floating point was only marginally better. The whole thing is still misunderstood and misquoted by 'experts' like the ones on Tom's HW. A 5% to 10% diffrence in most floating point benchmarks (which is what the Cyrix scored) didn't explain the 40% diffrence in quake performace. Anyone who spent 10 minutes playing around with FP on the Intel and Cyrix knows this, there were a few things that were slower on the Cyrix and a few things that were slower on the Intel. Besides, what do you expect for a chip that cost 1/2 a much? You get what you pay for, and as is true now it was true then. If you care about 3d games get a good video card. A voodoo 1 and a Cyrix cost roughtly the same as the faster Pentium and ran faster and looked prettier.
Intel is like Apple in the 80's. Back then Apple was releasing new computers all time trying to replace the Apple ][. The only problem is all their profit was in the Apple ][ sector. Every time they got screwed with the mac they just released new Apple ][ hardware. Eventually it worked but by then apple had lost the PC market and a lot of their customers to the IBM clone storm. Intel is trying to repeat history, they keep comming up with new processors to replace the x86 first there was the i432 (was that the number?) then there was the i860/i960 and now the itanic. Their latest effort is probably doomed because of AMD's hammer line. Intel will have to release a P4 that runs so well that it puts AMD out of the running or they will have to release a 64-bit x86 processor to compete in the 'server' space with AMD.
Yah, because risc chips take (or are suppost to, rember RISC originaly was toated as high clock rates low CPI, now they are low CPI and low clock rates) more instructions to get the same amount of work done. Sure, there are exceptions, especially since none of the processors you cited are accually RISC, they are load/store arch's though. No one accually uses MIPS (ha ha ha joke, think mips and in Rxxxx) anymore anyway, that was taken away from the 'RISC' camp when intel introduced the Ppro and it could add (rember that was one of the main components for calculating IPC) like mad. Thats when everyone started whining about SpecInt. Then the RISC people were selling their processors on MFLOPS which is the floating point version of MIPS. Until the PII/PIII (and especially now with the P4) had their clock rates bumped through the sky and there went SpecFP.
Then there was STREAM, which basically was a nice benchmark to measure memory bandwidth. This was good because memory bandwidth for the most part is bigger the more you spend on esoteric massivly parallel memory subsystems. Then the P4 came along with its rambus and prefetch logic. Whops!
Now we have people who would like to measure the speed of their general purpose processors on functions that should be in a DSP in your ___(fill in the blank, video card, sound card, etc).
Ah, the non x86 people will eventually face the light, Intel and AMD spend 10x as much on R&D as everyone else because they have 1000x as much volume. You may have better techology but you cant keep up with the people who have 100x as much money. So you have to come up with niche markets like watts per workload. Except that one is about to get clobbered by intel now that the notebook market has been sparked by Transmeta.
Its seems silly except maybe to point out that it can be done. Just about any modern computer can checksum data faster than it can read the data from main memory. By the time the nic has pulled the data from main memory the CPU could have already gotten an answer.
This is almost exactly what I'm doing. Two boxes. One running Windows with exceed and the other running linux. That way I have everything running at full (ok some linux apps suck over 100base) speed. The windows box is my main desktop since it has better hardware support. In particular multiple head support with the ability to easily drag windows between the heads. Combine that with the with a software IDE raid config exporting SMB shares and everything is just dandy. I host the linux applications from exceed. M$ word and Kword running in two windows next to each other is cute. I could try the linux box as my desktop box and run VNC on windows, but that isn't nearly as elegant a solution.
News, hmmp, check out MRBIOS. I first discovered them back in 92/93. Back then they had auto IDE detection, support for big IDE drives, and of course a FAST boot option. A year or so after that they had (software like the promise) IDE RAID support in the BIOS. Today I still have a VLB 486 machine (my firewall/webserver) with MRBIOS. It has a 60 Gig harddrive and a 16.7 Gig harddrive plugged into it with a massive uptime ratio (greater than a year and a half at up at one point). The machine is sub.8 second warm reset times. Its basically instant. The screen clears and lilo starts booting linux (I have lilo configured not to stop unless the shift key is held down) if I press the reset button. If the machine is comming up from a cold start the bios flashes post for something less than a second and then displays a flashing "Waiting for Harddrive to spin up" while the harddrives are going Whhhhhhhhmmmmmmm... As soon as they sound spun up the machine starts booting. I have machines that are 3 years old that don't support 16 gig drives and this little box is getting on towards 10 years old and it has a 60 gig HD plugged into it. I put a dx4-100 overdrive in it a few months back and the board which was bought right when the Dx2-50's first appeared. Poped up and said,"Newer than Dx2 486 at 99mhz",or something like that.
Its really sad though that these guys never caught on. Most of the 'cool' bios features that have appeared in the last few years in award/AMI were in MRBIOS in the early 90's. Now they are just a shell of a compay and they don't have BIOS's for machines newer than a few years old. Some people are just ahead of their time, Well I guess i'm going to go home and reboot my machine from the third harddrive now... lol..
Right, there are a lot of factors, education tailor suited to the child, fewer distractions, less social interaction etc. For example if your kid is really good at social studies, and English but bad at math then you either, make the kid a social studies/English genius or you dedicate more time to learning math at the expense of being really advanced in some other subject. This is something you can't do in a public school. The end result is someone who is average in social studies and English but below average in math.
I believe that many of the basic ideas we hold about school are inefficient or wrong. I'm not the only person who has thought this. The ACE school system (which has far to much religious background for my tastes) is probably a good thing to study. The students work at their own pace, the teachers are often with the same student for many years. It has its flaws but it proves that there are other ways to learn other than the lecture style prevalent in almost all of our schools.
Social interaction is VERY important but it must be carefully weighed just like any other 'subject'. The bully, friends or later on members of the opposite sex form pretty big distractions in the class room situation. I can tell you in college there was more than 1 instance where I missed important lecture information because I was staring at a pretty girl or flirting with one. No matter how much you try to control or how good you are at ignoring it, sex seems to have really high interrupt priority.
Teachers who are with kids for more than 1 year also have a big advantage they have a better feel for how the class is doing, know better where they left off the year before and what areas the students where strong or weak in. The result should just be more efficient teaching
Slashdot Mirror
100 GB is one spindle now days. A hotswap SCSI attached IDE raid config with a capacity of 1TB costs about $12k. Network costs? 100Mbps of internet connectivity costs 1k a month. Assuming mostly static content, the computers, network swiches and hot failover clustering software to drive this bad boy could probably be gotten for less than $30k. Pay a couple good students to set the whole thing up so it runs itself and you would be left with the cost of a couple HTML monkeys to integrate the whole mess.
Cyrix fan boy or whatever you want to call it.
The Cyrix chips _WERE_ faster than the Pentiums on the benchmarks everyone was using when the PR system was released. The problem is that everyone started using quake (and some other benchmarks) as a benchmark which the Cyrix sucked on because they were marginally slower than the equivilant clocked pentium with some floating point operations used a lot in quake (important parts of quake were also hand optimized for the pentium U-V pipline arch, which didn't help the cyrix or the amd much). Basically, you purchased a PR166 Cyrix that ran roughtly the same as a Pentium 166 running Winstone and a couple other similar bencharks, yet it was clocked at 133Mhz. When quake came out the Cyrix got its butt kicked because it ran about the speed of a pentium 100. I still have a IBM 6x86 PR166 machine that is running linux. Keep the CPU fan running and its stable as a rock, oh, and it compiles kernels faster than my 233Mhz MMX pentium. Just don't try playing quake. A sweet machine at the time considering It cost about as much as a Pentium 75.
Yah, no crap.. but you get 128G of RAM! lol... Guess you should just make a big RAM disk.
Accually, the PPC design is based on the early 'POWER' chips (RIOS) from IBM. Hence the Power part of the POWER Performace Computing. Now the 10k question? What does POWER stand for? Ok, Its Performace Optimized With Enhanced RISC.
Ah, don't try to use Memory mapped files under W2k either. I don't know about XP but I have a little memory mapped file application that runs about 10x faster under linux than windows. I jumped though a bunch of hoops to get it up to only about 3x slower by setting my process quota, messing with a bunch of system cache settings, etc. I don't know what the current recomendations are for IPC on w2k but long ago I started to design all my applications for a threaded model and use TCP for any real interprocess/machine communication. This gives me realitivly easy portability off of M$ productions (unlike COM).
Actually, I play a lot of FPS too.. It seems the more people play quake the more their brain dies. but much over 30 fps you cannot distinguish the frame rate differences.
That said, I will agree that you need high frame rate benchmarks for quake. Preferably in the 90fps range. This isn't because you can distinguish the differences but rather because the frame rates are usually given as averages (this is why Silent Sam is cool) and those quick glances behind are the parts where the frame rate averages get pulled down. So what you really need in quake is a machine that will guarantee that the time between frames won't drop below 1/30 (or more realistically 1/40) of a second
and the frame rate differences won't be maybe 1/8 of the total.
Now there is another thing to think about, it has to do with the motion speed, relative to you field of vision. You want things that cross your field of vision to cross smoothly. This is incredibly important in quake, since you are trying to absorb all the positional information on your opponents. In these cases it seems that the frame rates actually have to increase to compensate for what I think may be an eye to frame refresh rates (I'm not an expert on this so I don't really know if i'm describing this correctly) mismatch. Contrary to what I originally thought, which was that your eye required higher frame rates to compensate for a higher level of awareness for fast moving objects, I think that you eye/brain seems to slow down the when you look at things that are crossing your vision quickly. Try moving your head right and left quickly, think about what you are seeing when you are doing that. Part of the poor information feed probably has to do with your eye being unable to focus on anything. On the other hand movies are similar to FPS in that your eye doesn't have to refocus, yet I often find that quick pans (on real film, MPEG just makes it worse) are too jerky and out of focus. Of course I often find that things I want to look at in movies are out of focus, because i'm looking at something other than the intended subject.
Basically, what I'm saying is that the 30fps figure is pretty close to what your game should be getting, I might even give you 45 or 50fps. The difference between 40 and 125 though i think is primarily an interaction with the way your game frame rates are changing between frames because there has been a lot of real research about the 'refresh' rates of the human eye and human persistance of vision.
Actually, according to the article the G5 is probably in a .13 copper SOI process to reach 2ghz. The P4 is a .18 aluminum process right now. Intel has shown with the >1ghz PIII that they can do .13 too so its just a short time until they die shrink the P4 at which point it probably will get another clock speed bump. I expect that by the time I see a 1.6ghz PPC the P4 will probably be 2.5 to 3 ghz with bigger caches, maybe hyperthreading etc. The point is that the P4 will still be roughly as fast if not faster than the G5, and have a bigger clock rate for the sales people.
Exponential, was fast/hot because their processors were designed using BJT technology. The reason why they were 'slow' though was because the processors were based on older PPC cores. Its sort of like making a 3 ghz classic pentium. It would probably suck. As far as exponential tech, what i understand is that early Ppro's had BJT sections. I'm not aware of any such things in the P4.
Ahhhhh, when will they learn! Why didn't they just make it 64 bits or maybe 80 bits. That way in 8 years we won't have to upgrade the damn IDE command protocol again. Christ, all the new processors have 64 bit virtual address spaces. The commonly accepted address space numbers say roughly one bit of growth a year, that means that it will take 28 years or so before we start to run out of address space again. Drive capacities are growing a little faster than that. We are at 2^37 right now, they are extending it to 2^48. Not even enough head room for the next 10 years!!!!
I just bought a bunch of 80gb 7200rpm drives for a RAID! Of course, I only paid $189 for them which makes them about the same price per meg as the 160gb drive. On the other hand, my max capacity would have been much higher.
I've had Seagate 27/30Gb 7200 RPM drives die too. On the other hand my 6 year old 7200 RPM SCSI drives are still going... It probably has little to do with the rotational speed and everything to do with quality of manufacturing.
Everyone seems to be failing to make a distinction between loosely coupled development environments and IDE's vs GUI's and CLI's. Probably because most of the IDE's are GUI.
Frankly the GUI/CLI argument is an old one. I think the answer is more a case of personal preference and what kind of job is being done. Modern GUI's, macro recorders and script languages are as powerful a method of expression as CLI's with their multitude of scripting languages.
IDE's vs Loosely coupled should be a no brainier. Its a lot nicer to be able to use a single environment that is tied together. A lot of people are arguing their emacs->make->gdb configuration is better than the assorted IDE's listed. In truth they are just reinventing the wheel with a group of CLI tools. Instead of accepting a pre packaged IDE sitting on top of command line tools like VC++ they are creating their own IDE using their favorite editor and a bunch of scripts. At that point its pretty much a no brainier that a custom environment designed for their particular project is better. Of course it probably took them three weeks to build a bunch of scripts to tie their resource editor, text editor, code browser, object browser, compiler, debugger, profiler, source control, packaging, etc tools together in a manner that is functional.
So, the real question should have been is it better to use a prebuilt IDE or build your own? The answer to this is probably that it depends on the person. Personally I prefer using VC++ but I also have a large collection of scripts that I load into Xemacs when I'm using a Unix environment that allows me to things like checkout the current module from source control and check everything back in with a keystroke, or build the project and highlight any errors in a widow smart enough to open the offending modules so that I can edit the source line with a keystroke or two. I like to use a nice source browser that allows me to instantly open a new window and go to the module where the function I'm looking at is declared. All of these things require and IDE to be optimal, its just VC++ is preconfigured and I have to remember F12 is 'goto reference' and F7 is build (unless I change the keybindings). While I have about 2k worth of scripts I wrote to do it in emacs.
So what exactly was the point again?
Any decent macro recorder will do the same thing in windows with about 5 keystrokes and mouse events. Now try saving your results into a html table for viewing on the web. It turns out to be an ugly perl or sed script. Its just a couple more clicks and keystrokes to fire up a html editor, create a table and paste the results in and save as html. Then if you do it enough you just tie the macro to a hotkey. In the end you can do it in either the CLI or the GUI with one keystroke. It makes no diffrence in the end. The goals of GUI's are to make it eaiser to do things you don't know how to do. Everyone here is just arguing the same thing from two diffrent perspectives.
Of, course you still have to do real work! lol. I can't really imagine to many project though where a significant part of the GUI couldn't be handed by something like Borland C++ Builder. In the more recent version of BCB they have a Tframe component that removed nearly all my dependence on hand coded GUI components. There are just so many component libraries available that you can buy a component for just about any GUI widget behavior that can be thought of. About the only time I have to hand code a GUI anymore is for complex graphical rendering. Which is the real part of the application anyway. I can believe though with MFC you ended up recoding everything because its a beast and no one I know has ever managed to write much of their application using it. When the GUI's get more complicated than dialog boxes with push buttons MFC blows.
I had a friend though that ended up writing massive amounts of GUI code because he refused to write a table link or ODBC front-end to his proprietary database. In the end he just ended up rewriting nearly all the database management components included with delphi just to save a two or three day leaning curve to learn how to interface his database to the existing components. Some things cannot be forgiven... lol
The other posters have noted scripting languages. You should also look at winbatch, its more a GUI solution to a GUI problem. Basically its like an advanced macro recorder. I think it also has a script language you can use. You can just tell it to record and then do stuff in the GUI and it will capture the events for repeated playback. VC++ also has this type of stuff built in to a certain extent as long as you stay in VC.
You just don't get it.. It doesn't matter that it gets a lower IPC or is less efficient!!!!! The point is that it has a higher overall throughput because it can run at 2+ Ghz in an aluminum .18 process! Wait till it gets copper, SOI and drops to .13.
.75 (like you argue, AMD is more efficient). Now assume that they are both manufactured in roughly the same process and the P4 can only scale to 2ghz and the AMD maxes out at 1.4ghz (actually they can probably go higher). Therefore the P4 cranks out 1.5 (2*.75) billion operations per second while the AMD can only crank out 1.4 (1.4*1) billion operations per second. Now for grins lets throw the P3 in there.. Lets say it gets an IPC of .95 and maxes out at 1 ghz. Its max throughput is .95 billion operations per second. Which CPU should Intel focus on? Efficiency isn't the name of the game right now, if it was, we would all be running 400 mhz 486's that consume .001 watts.
Ok, since I may not have made myself clear! Lets make up an example. Assume: that the AMD gets a normalized IPC of 1 and the P4 gets a IPC of
As far as the FPU is concerned I believe Intel made the right decision. They control the majority of the x86 market and when they make a move people follow. They obviously decided (like AMD has for the Hammer) that high performance FP that isn't compatible with the x87 is more important than mediocre x87 performance. The x87 has turned out to be a beast to optimize because it is a stack based arch. The problem with stack based FP units is that they cannot be truly superscaler. This is why the 'RISC' arch's usually beat the x86 on floating point benchmarks. Its really hard to parallize FP operations when they are all dependent on the TOS from the last operation. So, Intel's engineers made the decision to focus on SSE, assuming that people who truly cared about top of the line floating point performance would recompile their code to use SSE, those people who didn't care would continue to use the old x87 FP. The people using SSE will see a nice performace boost while the people using the x87 will see modest boosts due primarly to the increased clock rates of the new processor. This is how Intel manages to make competitive CPU's (other companies do it too), they figure out a way to make the CPU scream and maintain compatibility with older CPU's at a relatively somewhat lower performance. This is old news, its a rehash of the same discussion when the Ppro came out. Everyone bitched about how much slower it was running 16 bit code. Do you think Intel made the wrong decision releasing the P6 core? That wasn't the first time the discussion came up either. I remember the 286 vs 386 discussions where the 286 was faster doing PIO at similar clock rates. We don't seem to care about that one anymore either.
I call BS on this too. High clock rate processors tend to have slightly lower IPC than lower clocked processors simply because they are designed for high clock rates! You acchieve higher clock rates by increasing the number of pipeline stages (or shrinking the process). This tends to increase the average instruction latency. On the otherhand it also increases the througput per unit time. Christ, if at the end of the day the P4 is only 75% as efficient per clock than the PIII but runs at 2x the clock rate in the same process, then intel made the right decision. Its a no brainer! When intel releases the P5 and its 50% as efficient as the P4 and only runs 2x as fast in the same process then you can cry about how they are making chips just to ramp the clock rate. Till then think about what your saying before you say it.
I think the P4 and the K7 core (in their current implementation) are about the same at the end of the day. The real question of course isn't which one has a higher clock rate in a given process but which one has a higer performace. All things being equal the one with the higher clock rates will be easier to sell. On the other hand, if I were betting, as much as I like AMD, I think that Intel has a winner. The current implementation is a seriously cut down version of what the arch will eventually be. Its caches (TLB, Trace etc) are small, its missing a couple pipes, and there isn't yet a SMT version. In other words the current P4 IPC is probably 3/5 of what it will be in a generation or two. Intel proved with the Ppro/PII/PIII that their x86 CPU designers know what they are doing. From where I stand it looks like they are well on their way to a repeat.
Accually, the Cyrix FP wasn't as bad as everyone made it out to be. The problem was quake was hand optimized for the Pentium U/V pipes and the optimizations didn't do anything for the AMD or Cyrix. The result was Quake ran considerably better on the Intel even though the Intel's floating point was only marginally better. The whole thing is still misunderstood and misquoted by 'experts' like the ones on Tom's HW. A 5% to 10% diffrence in most floating point benchmarks (which is what the Cyrix scored) didn't explain the 40% diffrence in quake performace. Anyone who spent 10 minutes playing around with FP on the Intel and Cyrix knows this, there were a few things that were slower on the Cyrix and a few things that were slower on the Intel. Besides, what do you expect for a chip that cost 1/2 a much? You get what you pay for, and as is true now it was true then. If you care about 3d games get a good video card. A voodoo 1 and a Cyrix cost roughtly the same as the faster Pentium and ran faster and looked prettier.
Intel is like Apple in the 80's. Back then Apple was releasing new computers all time trying to replace the Apple ][. The only problem is all their profit was in the Apple ][ sector. Every time they got screwed with the mac they just released new Apple ][ hardware. Eventually it worked but by then apple had lost the PC market and a lot of their customers to the IBM clone storm. Intel is trying to repeat history, they keep comming up with new processors to replace the x86 first there was the i432 (was that the number?) then there was the i860/i960 and now the itanic. Their latest effort is probably doomed because of AMD's hammer line. Intel will have to release a P4 that runs so well that it puts AMD out of the running or they will have to release a 64-bit x86 processor to compete in the 'server' space with AMD.
They wern't 64bit clean on the alpha, from what I understand they wern't '64-bit' at all. Sort of like win32s on windows 3.1.
Yah, because risc chips take (or are suppost to, rember RISC originaly was toated as high clock rates low CPI, now they are low CPI and low clock rates) more instructions to get the same amount of work done. Sure, there are exceptions, especially since none of the processors you cited are accually RISC, they are load/store arch's though. No one accually uses MIPS (ha ha ha joke, think mips and in Rxxxx) anymore anyway, that was taken away from the 'RISC' camp when intel introduced the Ppro and it could add (rember that was one of the main components for calculating IPC) like mad. Thats when everyone started whining about SpecInt. Then the RISC people were selling their processors on MFLOPS which is the floating point version of MIPS. Until the PII/PIII (and especially now with the P4) had their clock rates bumped through the sky and there went SpecFP.
Then there was STREAM, which basically was a nice benchmark to measure memory bandwidth. This was good because memory bandwidth for the most part is bigger the more you spend on esoteric massivly parallel memory subsystems. Then the P4 came along with its rambus and prefetch logic. Whops!
Now we have people who would like to measure the speed of their general purpose processors on functions that should be in a DSP in your ___(fill in the blank, video card, sound card, etc).
Ah, the non x86 people will eventually face the light, Intel and AMD spend 10x as much on R&D as everyone else because they have 1000x as much volume. You may have better techology but you cant keep up with the people who have 100x as much money. So you have to come up with niche markets like watts per workload. Except that one is about to get clobbered by intel now that the notebook market has been sparked by Transmeta.
Its seems silly except maybe to point out that it can be done. Just about any modern computer can checksum data faster than it can read the data from main memory. By the time the nic has pulled the data from main memory the CPU could have already gotten an answer.
This is almost exactly what I'm doing. Two boxes. One running Windows with exceed and the other running linux. That way I have everything running at full (ok some linux apps suck over 100base) speed. The windows box is my main desktop since it has better hardware support. In particular multiple head support with the ability to easily drag windows between the heads. Combine that with the with a software IDE raid config exporting SMB shares and everything is just dandy. I host the linux applications from exceed. M$ word and Kword running in two windows next to each other is cute. I could try the linux box as my desktop box and run VNC on windows, but that isn't nearly as elegant a solution.
News, hmmp, check out MRBIOS. I first discovered them back in 92/93. Back then they had auto IDE detection, support for big IDE drives, and of course a FAST boot option. A year or so after that they had (software like the promise) IDE RAID support in the BIOS. Today I still have a VLB 486 machine (my firewall/webserver) with MRBIOS. It has a 60 Gig harddrive and a 16.7 Gig harddrive plugged into it with a massive uptime ratio (greater than a year and a half at up at one point). The machine is sub .8 second warm reset times. Its basically instant. The screen clears and lilo starts booting linux (I have lilo configured not to stop unless the shift key is held down) if I press the reset button. If the machine is comming up from a cold start the bios flashes post for something less than a second and then displays a flashing "Waiting for Harddrive to spin up" while the harddrives are going Whhhhhhhhmmmmmmm... As soon as they sound spun up the machine starts booting. I have machines that are 3 years old that don't support 16 gig drives and this little box is getting on towards 10 years old and it has a 60 gig HD plugged into it. I put a dx4-100 overdrive in it a few months back and the board which was bought right when the Dx2-50's first appeared. Poped up and said,"Newer than Dx2 486 at 99mhz" ,or something like that.
Its really sad though that these guys never caught on. Most of the 'cool' bios features that have appeared in the last few years in award/AMI were in MRBIOS in the early 90's. Now they are just a shell of a compay and they don't have BIOS's for machines newer than a few years old. Some people are just ahead of their time, Well I guess i'm going to go home and reboot my machine from the third harddrive now... lol..
Right, there are a lot of factors, education tailor suited to the child, fewer distractions, less social interaction etc. For example if your kid is really good at social studies, and English but bad at math then you either, make the kid a social studies/English genius or you dedicate more time to learning math at the expense of being really advanced in some other subject. This is something you can't do in a public school. The end result is someone who is average in social studies and English but below average in math.
I believe that many of the basic ideas we hold about school are inefficient or wrong. I'm not the only person who has thought this. The ACE school system (which has far to much religious background for my tastes) is probably a good thing to study. The students work at their own pace, the teachers are often with the same student for many years. It has its flaws but it proves that there are other ways to learn other than the lecture style prevalent in almost all of our schools.
Social interaction is VERY important but it must be carefully weighed just like any other 'subject'. The bully, friends or later on members of the opposite sex form pretty big distractions in the class room situation. I can tell you in college there was more than 1 instance where I missed important lecture information because I was staring at a pretty girl or flirting with one. No matter how much you try to control or how good you are at ignoring it, sex seems to have really high interrupt priority.
Teachers who are with kids for more than 1 year also have a big advantage they have a better feel for how the class is doing, know better where they left off the year before and what areas the students where strong or weak in. The result should just be more efficient teaching