Now my PC can take 10 min to POST like the itanic we have? Plus it can have three diffrent "BIOS" menus i have to scroll through before the OS starts to boot?
Again, who gives a shit. The current BIOS is working just fine, old, clunky, yes. But its well understood and its working.
In this case it was because the CPU wouldn't do prediction on JMP's with register targets (not that unusual, combined with the fact that unknown JMP's took longer than just regular JMP's on that CPU) resulting in slow JMPs.
So the compiler got around that for virtual method calls using a number of "tricks". Apparently there are a lot of cases where the compiler _can_ statically bind a virtual method or generate code which looks like
if (objtype==1)
call x; else
call y;
instead of a vtable method call. Both of these methods resulted in significantly faster code because the predictor was enabled or worked. In the worse case the compiler ends up simply loading the method pointer from the vtable, and making the call. In this case its exactly the same speed as doing it the C way with a function pointer in a structure.
I've also heard of games where compilers facing similar problems made an indexed jump into a vtable like structure and then jumped to the method. Again in these cases to work around CPU's not being able to predict on jump targets contained in registers.
Even so, normally you don't sprinkle virtual around in front of every method call (unless you using JAVA in which case you get that behavior with asking for it). Instead you use it when needed. Same as when you use function pointers. The result isn't noticable. If for some reason you designed an OS that was completly pluggable and used a lot of virtual methods, its still not a big deal because a slow JMP on nearly any processor is still siginificantly faster than a lot of things, load misses in particular and in theory you would be gaining something by it.
With gcc (g++ (GCC) 3.3.1 (SuSE Linux)) on a P4 2.4 this is the output from the program I just wrote (and will put in another message)
vtable call time 58355 call time 58482 function ptr time 91741
Didn't look at the assembly so something could be wrong... results are a little better with -O2.
vtable call time 58378 call time 54861 function ptr time 75041
and with -O3. vtable call time 12518 call time 8385 function ptr time 66780
Of course, you wouldn't use virtual methods in os code unless you were a retard.
Virtual methods are up to the compiler how they get implemented but often times they are just function pointers. This is exactly what everyone is doing in the kernel anyway. There isn't any point to not use virtual methods if the need presents itself. A couple of years ago on AIX I showed how the C++ compiler was generating virtual method calls that were faster than the function pointer syntax people were using because of branch prediction. So in some cases there is accually performace to be gained.
Glade lets you DRAG AND DROP GTK+ controls onto a window.
What I said about GLADE...
The cheezy little form builders for GTK and QT
Welcome to borland C++'s resource editor from the early '90s.
Of course you're a windows programmer so you put all your code in one.C file and use batchfiles to build it...
You would be surprised to find my name in the linux kernel patch list, and i'm employed to get my job done.. That means programming for windows/linux/aix/hpux and solaris in the last 2 years. Currently about 30% of my work time is spent doing HPUX development the remainder is mostly linux. Compared with windows its like working in the dark ages. I haven't written a batch file for windows in at least 5 years. This isn't true of the little shell scripts I have to write just to get make to work properly. In windows the IDE's just handle everything. A few mouse clicks here and there and I can build for x86-64 machines vs normal x86. In linux I have to hack up a bunch of autoconf/automake files which usually takes about 100x as long. We are using autoconf/automake and complicating our lives because we want proper dependency checking, something the windows IDE's have been doing since the late '80s.
This is turning into a flame war, and you obviously are some HS student without more than a few hours of real experience. So this is where i'm done with the discussion.
um what the fuck do you think Motif, GTK+, OSS, etc... are all DOING
Reinventing borland C++ and Visual Studio. Not a RAD tool. Ive used both GTK+ and KDE/qt. KDE is far more advanced in that regard but I still end up spending a lot of time writing code that looks like.
Or even worse writing my own components. The cheezy little form builders for GTK and QT are little more than rehashes of the resource editor borland had in '91 and VS 1.0 had.
You obviously missed the whole point of my post, and have never left your comfortable little environment from the 1980's.
BTW.. I would like to see you get motif working in an environment without X. Or OSS working on a palmOS device. Plus there are things like I still can't copy paste a graphic between an application written for gnome and one written for KDE. SO much for portability.
Linux is only Unix on the outside. There's scarcely little code on the inside from 1992.
Doesn't matter, its just another UNIX, just like BSD is just another UNIX. It didn't steal anything from "UNIX" either other than the structure and API's. It has all the same problems UNIX had back in the 1970's. There are so many cool things that could be done in a modern OS its not funny. Instead we have an OS thats just a API compatable rewrite that missed the whole late 80's and 90's worth of OS research and even is written in C, a language designed to implement UNIX instead of something even a little better like C++ which supports virtual methods instead of hand implementing function pointers everywhere. Even NT is nativly message passing, and async. M$ has 1/10 the number of programmers working on windows and it still has advanced features like versioned file systems with metadata that linux doesn't have.
Don't know about you but on windows the higher level RAD languages like delphi, C#, etc remove much of the tedium your talking about. Sure some of it is still there but it doesn't take hours to create basic applications. Hell a heavily GUI program is mostly drawn, with a few lines of code to instruct it what to do on events like menu selections, Ok opens, etc.. Tree component expansion, and the like are handled transparntly in the component. Data manipulation is often just writing SQL statments which are themselves sometimes generated with SQL generators. Most basic algorithms you learned in school exist in the standard libraries as generics. Programming is far less tedious now than it was 10 years ago if you choose the right tools. Otherwise you spend all day screwing around with command line utilities you are gluing together by rewritting the same code to redirect stdin/stdout that people were writting 15 years ago. Then once you have the data you spend all day walking it in for loops to set some state on the data elements.
The majority of us OSS folk are writing ***PORTABLE*** tools that work anywhere.
That POSIX is... Which is complete crap and doesn't define anything worth a damn. POSIX database access? POSIX audio output, POSIX tape access. You get my point. Any application that is non trivial isn't portable. It may be ported through the use of translation layers, but people have been doing that for years. Its not hard but it requires you to write to the lowest common denominator and build your app on that. The result is you have programmers reinventing the wheel all the time.
This is accually one of the problems with linux on the desktop. A lot of the "windows only" applications are windows only because they were written using RAD tools that provide extensive "standard" components. A couple of years ago I showed someone how easy it was in VB to create a scanner application by dropping the scanner OCX on a form, adding a graphics button for preview and then dumping a the selection rectangle to the scanner OCX. The resulting bump got inserted into a table. In about 5 minuites I had a working "scan and filter" application that could scan, clip, invert, convert to BW and dump the result to a database table.
Try porting that? I rewrite it with appropiate shell utilities too, but it would be a lot harder and wouldn't be nearly as nice without writting a lot of Tk code to present the user with options. There are a _LOT_ of windows only applications. For example DVDshrink is a free DVD ripper tool that in my opinion is better than anything i've seen for Linux. Its fast, stable, clean and just works. Things like that are possible when you spend your time working on the core application rather than writing 100's of lines of code to interface with SANE and display basic graphics boxes with selection capability.
Actually, I lie. I am one of those 'old' people in class who actually does their homework, and gets straight 'A's all of the young kids hate me. It is amazing what can happen in school when you are more interested in learning, than banging the chick next to you. I would be interested in banging the chick next to me, but I am 20 years too old for her...so I guess learning will have to suffice.
Chuckle, thats a good one. It's legal, so who gives a shit. I'm sure you can find some "cutie" who is looking to be a little expermental. Gotta get the full college experience...
I don't really see your point. The spiral is to remove the disconnect that exists between the noble gas column on the left of the existing chart and the succeding element on the left hand side of the chart. Count the concentric rings to get the "row" from this chart.
Other than some minor corrections this is just a circular version of the existing chart. Any tricks you can do with an existing chart work just as well with this one.
I run 2000 as my primary box at home. I ran accross something a few months ago that wanted XP. Took me 10 minuites with google to find a hack to add XP to 2000's list of "Compatibility mode" OS's. Then I just went in and set "Run in compatibilty mode" and selected XP. I think it just lied about what version of the OS was running.
From what i've seen there are less than a dozen WIN32 API diffrences between XP and 2000 SP4. They are almost all pretty obscure changes. So if an app demands xp there is a good chance its just because someone didn't want to test it on 2k.
Back when I purchased my 233 MMX pentium, I was anoyed it didn't have a turbo jumper (first machine I purchased that didn't). So I wired the turbo button to one of the clock selection jumpers (the was before people started doing soft BIOS overclocking). When I hit the turbo button my machine ran at 266 Mhz. Only problem was that you had to preselect the speed before booting because hitting the turbo button while it was running caused the machine to hang.
He disabled runas.. Thats really annoying, how else can you run with a non administrator account and still run other programs with diffrent privlege levels (like sudo on linux for people who don't know what RunAs does)?
Blah, other than that its nice to see/. picking up on the fact that its pretty easy to run newer M$ os's on old hardware too.
Its nice and all that IBM recommends linux. Which is probably a good idea for people mad about their closed source operating system being discontinued. On the other hand it doesn't really address any of the real issues. First like it or not, OS/2's API's are a lot closer to windows than they are to linux. If I had some huge application I wrote for OS2 I probably wouldn't just up and rewrite it in java unless I wanted to spend a lot of money. Instead I would try to port it to the closest supported OS. In this case that is probably W2003/Embedded/etc. While M$ may screw you left and right, they probably won't be dropping support for windows anytime in the near future.
I've got a few old books from the 20's-60's at home about motor and generator design (and some modern electronics textbooks which arn't as helpful, go figure). From what I know, air core generators suck. Its quite amazing that these guys were that modivated but didn't think about designing a better generator (or for the $700 the spent on the magnets and windings just buying one). A quick google search picked this up..
This is not to say that I think your right about DIY generators. I think a perfectly good generator could have been built. A good lathe and mill would have been more than adequate.
This is the reason I leave javascript off for most sites. The thing behaves better with it off.. The cute little stars for radio boxes are really really annoying.
Your quoting FP performance. The "integer" (aka general purpose) performance isn't nearly as competitive. This is because its a static VLIW machine, and its hard to write a good VLIW compiler. Writing fast FP code is simpler. Then there is the fact that the Itanic is 3x the hardware of the machines your comparing it to. Bigger caches, and all that. Your misunderstanding of clock rate is also simplistic. In order to get the Itanic faster they would have to create a longer pipeline, this would more than likely decrease the IPC and keep the processor from scaling lineraly.
Basically it was pointless. we don't need yet another processor targeted into the same market the POWER64/SPARC64/PARISC and now the X86-64 etc are in. The whole arch is a mess in my opinion its accually probably worse than the x86, this is evident in how long it took to get the thing out the door. For a processor based on the idea that superscaler wasn't easy and wouldn't perform its beginning to look like the itanic is accually in that boat. Its a dead arch, there are orders of magnitude more x86-64 machines out there even though the itanic had a two year lead. Why should I use itanic when there is a larger software base for PPC/POWER and its multivendor? POWER is cheaper,faster and more mature and it can barely compete with x86 in the desktop area. ARM has pretty much taken over the smaller chores (cellphones, PDA's MP3 players etc..) and smaller chips like the 8051 clones sit below that.
Give it up, it was stupid, Intel was wrong. My opionion is that itanic was a marking plan to lock up the processor market. If we were all forced to run itaniums back in 96-98 then we would all be buying intel chips for everything. Instead intel had to release the P-Pro to keep ahead of Cyrix/AMD, only they never got far enough ahead to kill AMD to release the pressure and transition everyone to Itanic, where theyhold all kinds of patents and copyrights on the instruction set. Plus they couldn't make the thing work and it slipped for 5 years.
Switching Between MDI Child Windows For MDI child windows, apply common mouse conventions for activating and switching between primary windows. The recommended keyboard shortcuts for switching between child windows are CTRL+F6 and CTRL+TAB (and SHIFT+ modified combinations to move backwards). On the menu bar of the parent window, include a Window menu with commands for switching between child windows and managing or arranging the windows within the MDI parent window, such as Tile or Cascade.
Alt-Tab tabs through EVERY window, which can be quite tedious when you have a lot of them up.
I screwed up posting the original comment, but I tried to point that out, I think you are confusing the short lived idea that everything should be SDI with the system behavior, that is why you have 100 diffrent IE and word windows. Ctrl-tab doesn't work in these cases because M$ tried to make it look like there are 100 diffrent applications open when in reality there are 2. IE doesn't have a tabbed version (aka MDI) but word does. Turn it on and you will discover that alt-tab works better and ctrl-tab switches through your word docs. Then they tried to fix the problem of people complaining about cluttered task bars by grouping the tasks by the owning application. All this just to come in a full circle and conclude that MDI didn't completly suck. Some applications just work better that way.
There may be a "standard" at the application level, but there's nothing at the OS level that makes Ctrl-Tab work.
Depends on your definition of application level and os level, but all the standard built in components in the GUI toolkit behave that way. And the win32 api knows enough about components to post the correct WM_messages to the appropriate message queue for a lot of events. I've found applications where people tried to disable the ctrl-c/v paste option (for entering serial numbers etc) but they didn't know about ctrl/shift-insert. The base components behave correctly as long as people don't fsck them up they continue to work properly. Granted a lot of custom components people wrote to do funky things, thankfully they are realitivly rare. I don't think i've ever used an MDI application that doesn't support ctrl-tab properly. Besides is there anything in the mac os that enfoces behavior for a custom component? I doubt it. Even then some of the behavior is just WM_messages, like the scroll bars for example. M$ didn't have to rewrite every application when they added the scroll wheel because the mouse just posted WM_SCROLL messages to the window the mouse was over. Normally these messages would be comming from the GDI in response to scrollbar clicks. This is an example of something that still doesn't work properly in KDE/Gnome because there isn't a standard "scroll up/down" message in X.
Slashdot Mirror
Now my PC can take 10 min to POST like the itanic we have? Plus it can have three diffrent "BIOS" menus i have to scroll through before the OS starts to boot?
Again, who gives a shit. The current BIOS is working just fine, old, clunky, yes. But its well understood and its working.
This is BS. Server versions of windows support 64G of memory with PAE.
use the runas, command or right click on .exe's and select runas. That does basically the samething as sudo in unix.
Which is probably more appropriate since you will have to check with a controlling interest every time you want to do run/play something...
// please Ignore the uglies and /. issues
//structure function call
t art.tv_usec);
. tv_usec);
. tv_usec);
#include sys/time.h&
#include stdio.h&
int x;
class vtest
{
public:
vtest() {};
~vtest() {};
virtual void test(void);
} vglobal;
void vtest::test(void)
{
x=x+1;
}
void test(void)
{
x=x+1;
}
struct functioncall
{
void (*test)(void);
} ftest;
int main(int argc,int *argv[])
{
const unsigned long ALOT=10000000;
timeval start,end;
timezone tz;
gettimeofday(&start,&tz);
for (int count=0;countALOT;count++)
{
vglobal.test();
}
gettimeofday(&end,&tz);
printf("vtable call time \t%u\t%u\n",end.tv_sec-start.tv_sec,end.tv_usec-s
gettimeofday(&start,&tz);
for (int count=0;countALOT;count++)
{
test();
}
gettimeofday(&end,&tz);
printf("call time \t\t%u \t%u\n",end.tv_sec-start.tv_sec,end.tv_usec-start
ftest.test=test;
gettimeofday(&start,&tz);
for (int count=0;countALOT;count++)
{
ftest.test();
}
gettimeofday(&end,&tz);
printf("function ptr time \t%u \t%u\n",end.tv_sec-start.tv_sec,end.tv_usec-start
}
Branch prediction? On function pointers?
In this case it was because the CPU wouldn't do prediction on JMP's with register targets (not that unusual, combined with the fact that unknown JMP's took longer than just regular JMP's on that CPU) resulting in slow JMPs.
So the compiler got around that for virtual method calls using a number of "tricks". Apparently there are a lot of cases where the compiler _can_ statically bind a virtual method or generate code which looks like
if (objtype==1)
call x;
else
call y;
instead of a vtable method call. Both of these methods resulted in significantly faster code because the predictor was enabled or worked. In the worse case the compiler ends up simply loading the method pointer from the vtable, and making the call. In this case its exactly the same speed as doing it the C way with a function pointer in a structure.
I've also heard of games where compilers facing similar problems made an indexed jump into a vtable like structure and then jumped to the method. Again in these cases to work around CPU's not being able to predict on jump targets contained in registers.
Even so, normally you don't sprinkle virtual around in front of every method call (unless you using JAVA in which case you get that behavior with asking for it). Instead you use it when needed. Same as when you use function pointers. The result isn't noticable. If for some reason you designed an OS that was completly pluggable and used a lot of virtual methods, its still not a big deal because a slow JMP on nearly any processor is still siginificantly faster than a lot of things, load misses in particular and in theory you would be gaining something by it.
With gcc (g++ (GCC) 3.3.1 (SuSE Linux)) on a P4 2.4 this is the output from the program I just wrote (and will put in another message)
vtable call time 58355
call time 58482
function ptr time 91741
Didn't look at the assembly so something could be wrong... results are a little better with -O2.
vtable call time 58378
call time 54861
function ptr time 75041
and with -O3.
vtable call time 12518
call time 8385
function ptr time 66780
Virtual methods are up to the compiler how they get implemented but often times they are just function pointers. This is exactly what everyone is doing in the kernel anyway. There isn't any point to not use virtual methods if the need presents itself. A couple of years ago on AIX I showed how the C++ compiler was generating virtual method calls that were faster than the function pointer syntax people were using because of branch prediction. So in some cases there is accually performace to be gained.
C is inappropriate for OS work. Too much happens behind your back, and as you may have noticed, it's s l o w.
Glade lets you DRAG AND DROP GTK+ controls onto a window.
.C file and use batchfiles to build it...
What I said about GLADE...
The cheezy little form builders for GTK and QT
Welcome to borland C++'s resource editor from the early '90s.
Of course you're a windows programmer so you put all your code in one
You would be surprised to find my name in the linux kernel patch list, and i'm employed to get my job done.. That means programming for windows/linux/aix/hpux and solaris in the last 2 years. Currently about 30% of my work time is spent doing HPUX development the remainder is mostly linux. Compared with windows its like working in the dark ages. I haven't written a batch file for windows in at least 5 years. This isn't true of the little shell scripts I have to write just to get make to work properly. In windows the IDE's just handle everything. A few mouse clicks here and there and I can build for x86-64 machines vs normal x86. In linux I have to hack up a bunch of autoconf/automake files which usually takes about 100x as long. We are using autoconf/automake and complicating our lives because we want proper dependency checking, something the windows IDE's have been doing since the late '80s.
This is turning into a flame war, and you obviously are some HS student without more than a few hours of real experience. So this is where i'm done with the discussion.
Back to real work.
um what the fuck do you think Motif, GTK+, OSS, etc... are all DOING
r method;
Reinventing borland C++ and Visual Studio. Not a RAD tool. Ive used both GTK+ and KDE/qt. KDE is far more advanced in that regard but I still end up spending a lot of time writing code that looks like.
button x=new button;
x.text="OK";
x.buttonpushevent=someothe
parent.form.addbutton(x);
Or even worse writing my own components. The cheezy little form builders for GTK and QT are little more than rehashes of the resource editor borland had in '91 and VS 1.0 had.
You obviously missed the whole point of my post, and have never left your comfortable little environment from the 1980's.
BTW.. I would like to see you get motif working in an environment without X. Or OSS working on a palmOS device. Plus there are things like I still can't copy paste a graphic between an application written for gnome and one written for KDE. SO much for portability.
Doesn't matter, its just another UNIX, just like BSD is just another UNIX. It didn't steal anything from "UNIX" either other than the structure and API's. It has all the same problems UNIX had back in the 1970's. There are so many cool things that could be done in a modern OS its not funny. Instead we have an OS thats just a API compatable rewrite that missed the whole late 80's and 90's worth of OS research and even is written in C, a language designed to implement UNIX instead of something even a little better like C++ which supports virtual methods instead of hand implementing function pointers everywhere. Even NT is nativly message passing, and async. M$ has 1/10 the number of programmers working on windows and it still has advanced features like versioned file systems with metadata that linux doesn't have.
Don't know about you but on windows the higher level RAD languages like delphi, C#, etc remove much of the tedium your talking about. Sure some of it is still there but it doesn't take hours to create basic applications. Hell a heavily GUI program is mostly drawn, with a few lines of code to instruct it what to do on events like menu selections, Ok opens, etc.. Tree component expansion, and the like are handled transparntly in the component. Data manipulation is often just writing SQL statments which are themselves sometimes generated with SQL generators. Most basic algorithms you learned in school exist in the standard libraries as generics. Programming is far less tedious now than it was 10 years ago if you choose the right tools. Otherwise you spend all day screwing around with command line utilities you are gluing together by rewritting the same code to redirect stdin/stdout that people were writting 15 years ago. Then once you have the data you spend all day walking it in for loops to set some state on the data elements.
That POSIX is... Which is complete crap and doesn't define anything worth a damn. POSIX database access? POSIX audio output, POSIX tape access. You get my point. Any application that is non trivial isn't portable. It may be ported through the use of translation layers, but people have been doing that for years. Its not hard but it requires you to write to the lowest common denominator and build your app on that. The result is you have programmers reinventing the wheel all the time.
This is accually one of the problems with linux on the desktop. A lot of the "windows only" applications are windows only because they were written using RAD tools that provide extensive "standard" components. A couple of years ago I showed someone how easy it was in VB to create a scanner application by dropping the scanner OCX on a form, adding a graphics button for preview and then dumping a the selection rectangle to the scanner OCX. The resulting bump got inserted into a table. In about 5 minuites I had a working "scan and filter" application that could scan, clip, invert, convert to BW and dump the result to a database table.
Try porting that? I rewrite it with appropiate shell utilities too, but it would be a lot harder and wouldn't be nearly as nice without writting a lot of Tk code to present the user with options. There are a _LOT_ of windows only applications. For example DVDshrink is a free DVD ripper tool that in my opinion is better than anything i've seen for Linux. Its fast, stable, clean and just works. Things like that are possible when you spend your time working on the core application rather than writing 100's of lines of code to interface with SANE and display basic graphics boxes with selection capability.
Chuckle, thats a good one. It's legal, so who gives a shit. I'm sure you can find some "cutie" who is looking to be a little expermental. Gotta get the full college experience...
I don't really see your point. The spiral is to remove the disconnect that exists between the noble gas column on the left of the existing chart and the succeding element on the left hand side of the chart. Count the concentric rings to get the "row" from this chart.
Other than some minor corrections this is just a circular version of the existing chart. Any tricks you can do with an existing chart work just as well with this one.
I run 2000 as my primary box at home. I ran accross something a few months ago that wanted XP. Took me 10 minuites with google to find a hack to add XP to 2000's list of "Compatibility mode" OS's. Then I just went in and set "Run in compatibilty mode" and selected XP. I think it just lied about what version of the OS was running.
From what i've seen there are less than a dozen WIN32 API diffrences between XP and 2000 SP4. They are almost all pretty obscure changes. So if an app demands xp there is a good chance its just because someone didn't want to test it on 2k.
Back when I purchased my 233 MMX pentium, I was anoyed it didn't have a turbo jumper (first machine I purchased that didn't). So I wired the turbo button to one of the clock selection jumpers (the was before people started doing soft BIOS overclocking). When I hit the turbo button my machine ran at 266 Mhz. Only problem was that you had to preselect the speed before booting because hitting the turbo button while it was running caused the machine to hang.
He disabled runas.. Thats really annoying, how else can you run with a non administrator account and still run other programs with diffrent privlege levels (like sudo on linux for people who don't know what RunAs does)?
/. picking up on the fact that its pretty easy to run newer M$ os's on old hardware too.
Blah, other than that its nice to see
Its nice and all that IBM recommends linux. Which is probably a good idea for people mad about their closed source operating system being discontinued. On the other hand it doesn't really address any of the real issues. First like it or not, OS/2's API's are a lot closer to windows than they are to linux. If I had some huge application I wrote for OS2 I probably wouldn't just up and rewrite it in java unless I wanted to spend a lot of money. Instead I would try to port it to the closest supported OS. In this case that is probably W2003/Embedded/etc. While M$ may screw you left and right, they probably won't be dropping support for windows anytime in the near future.
I've got a few old books from the 20's-60's at home about motor and generator design (and some modern electronics textbooks which arn't as helpful, go figure). From what I know, air core generators suck. Its quite amazing that these guys were that modivated but didn't think about designing a better generator (or for the $700 the spent on the magnets and windings just buying one). A quick google search picked this up..
/ 91
http://www.fieldlines.com/story/2003/12/27/202634
This is not to say that I think your right about DIY generators. I think a perfectly good generator could have been built. A good lathe and mill would have been more than adequate.
This is the reason I leave javascript off for most sites. The thing behaves better with it off.. The cute little stars for radio boxes are really really annoying.
Your quoting FP performance. The "integer" (aka general purpose) performance isn't nearly as competitive. This is because its a static VLIW machine, and its hard to write a good VLIW compiler. Writing fast FP code is simpler. Then there is the fact that the Itanic is 3x the hardware of the machines your comparing it to. Bigger caches, and all that. Your misunderstanding of clock rate is also simplistic. In order to get the Itanic faster they would have to create a longer pipeline, this would more than likely decrease the IPC and keep the processor from scaling lineraly.
Basically it was pointless. we don't need yet another processor targeted into the same market the POWER64/SPARC64/PARISC and now the X86-64 etc are in.
The whole arch is a mess in my opinion its accually probably worse than the x86, this is evident in how long it took to get the thing out the door. For a processor based on the idea that superscaler wasn't easy and wouldn't perform its beginning to look like the itanic is accually in that boat. Its a dead arch, there are orders of magnitude more x86-64 machines out there even though the itanic had a two year lead. Why should I use itanic when there is a larger software base for PPC/POWER and its multivendor?
POWER is cheaper,faster and more mature and it can barely compete with x86 in the desktop area. ARM has pretty much taken over the smaller chores (cellphones, PDA's MP3 players etc..) and smaller chips like the 8051 clones sit below that.
Give it up, it was stupid, Intel was wrong. My opionion is that itanic was a marking plan to lock up the processor market. If we were all forced to run itaniums back in 96-98 then we would all be buying intel chips for everything. Instead intel had to release the P-Pro to keep ahead of Cyrix/AMD, only they never got far enough ahead to kill AMD to release the pressure and transition everyone to Itanic, where theyhold all kinds of patents and copyrights on the instruction set. Plus they couldn't make the thing work and it slipped for 5 years.
There may be a "standard" at the application level,
= /library/en-us/dnwue/html/ch10g.asp
The Windows UI guidelines also say that ctrl-tab and ctrl-f6 switch windows (the ctrl-f6 is historical).
http://msdn.microsoft.com/library/default.asp?url
Switching Between MDI Child Windows
For MDI child windows, apply common mouse conventions for activating and switching between primary windows. The recommended keyboard shortcuts for switching between child windows are CTRL+F6 and CTRL+TAB (and SHIFT+ modified combinations to move backwards). On the menu bar of the parent window, include a Window menu with commands for switching between child windows and managing or arranging the windows within the MDI parent window, such as Tile or Cascade.
I screwed up posting the original comment, but I tried to point that out, I think you are confusing the short lived idea that everything should be SDI with the system behavior, that is why you have 100 diffrent IE and word windows. Ctrl-tab doesn't work in these cases because M$ tried to make it look like there are 100 diffrent applications open when in reality there are 2. IE doesn't have a tabbed version (aka MDI) but word does. Turn it on and you will discover that alt-tab works better and ctrl-tab switches through your word docs. Then they tried to fix the problem of people complaining about cluttered task bars by grouping the tasks by the owning application. All this just to come in a full circle and conclude that MDI didn't completly suck. Some applications just work better that way.
Depends on your definition of application level and os level, but all the standard built in components in the GUI toolkit behave that way. And the win32 api knows enough about components to post the correct WM_messages to the appropriate message queue for a lot of events. I've found applications where people tried to disable the ctrl-c/v paste option (for entering serial numbers etc) but they didn't know about ctrl/shift-insert. The base components behave correctly as long as people don't fsck them up they continue to work properly. Granted a lot of custom components people wrote to do funky things, thankfully they are realitivly rare. I don't think i've ever used an MDI application that doesn't support ctrl-tab properly. Besides is there anything in the mac os that enfoces behavior for a custom component? I doubt it. Even then some of the behavior is just WM_messages, like the scroll bars for example. M$ didn't have to rewrite every application when they added the scroll wheel because the mouse just posted WM_SCROLL messages to the window the mouse was over. Normally these messages would be comming from the GDI in response to scrollbar clicks. This is an example of something that still doesn't work properly in KDE/Gnome because there isn't a standard "scroll up/down" message in X.