In Windows, bringing a window to foreground effectively re-nices it to a higher priority.
And just what the hell does that have to do with whether the mouse pointer tracks or not?
Yeh, give the interactive task more CPU, that's fine, that's what "nice" is all about, after all. The thing is, though, it doesn't matter in Windows, X11, NeXTstep, AmigaDOS, or, well, anything that isn't a freshman CS cooperative multitasking system... it doesn't matter in any of them whether the foreground task is busy, hung, dead, hung over, stoned, or depressed... it's not the thing that's moving the mouse pointer.
Got it?
That kind of deep user interface failure isn't caused by bad scheduling, good scheduling, or bad-cop-good-cop scheduling. It's caused by X11 deciding that this is a good time to let latency go hang. Because it's not a real-time system, and it doesn't give the user interface itself the kind of loving personal hands-on attention that the rest of the GUI based systems do, because that's not what it was designed for.
"He's installing a new game on the computer. It keeps you from playing the other games, if you can crack it, maybe you can get a summer job at Microsoft. Wouldn't that be nice?"
2 factors in this were dynamic priority boosting (a runnable task that had been 'starved' for too long would get its priority boosted untill it became high enough for it to get a timeslice)
When I started using UNIX back around '78 it had already been doing that kind of priority juggling for so long that you just assumed it was there.
No, really, it's not the scheduler. Juggling priorities so that interactive tasks get priority over compute bound ones is precambrian. It's not what makes OS/2 and other operating systems that provide good interactive response what they are. Do you want to know what it is? It's the whole GUI design. It's recognising that a GUI is a real-time environment, one in which the time a result is generated is part of whether the result is correct or not. It's taking advantage of the fact that the display is computationally close to the user. It's all kinds of things.
X11 is not a real-time design. X11 is designed to provide decent display update speed... decent throughput... over networks that have inadequate bandwidth and totally inadquate latency. It's not as good at it as schemes like NeWS (now there's a sweet design) that split the whole user interface away from the heavy lifting and let you run the GUI in a lightweight scripting language in the display server itself... but that's the environment it was designed for. It wasn't designed to give you any guaranteed response time, it was designed to make sure you could get any response at all. By design, it defers and batches transactions. It can deliberately delay updates so it can bundle operations together and send a single packet to the display instead of having to sith through 6 or 8 turnarounds.
THAT is why now that you have a 2 GHz 64-bit processor and a graphics card that by itself has more CPU power than the whole of Project Athena at MIT did... that is why you can have all that and when things get busy it gets delayed.
The differences between the design of X11 and OS/2 are so profound that they utterly swamp trivia like a slightly different scheduling algorithm.
One thing OS/2 seems quite good at doing is adjusting various process priorities to make the user experience a smooth one.
I doubt that what you're seeing has anything to do with process priorities or scheduler design. The unfortunate design decisions that have produced the kinds of glitches you see in the current X-based desktop environment are buried much deeper and are harder to fix than simply tweaking the scheduler.
Um, even Microsoft managed to figure that one out.
There's three main ways that personal computer operating systems have implemented multitasking. Round robin timeslicing, preemptive multitasking, and cooperative multitasking.
Round robin timeslicing is used when the programs being shared are running under a virtual machine of some kind, and have no way to give up the CPU. The old timeslicers for DOS used this, and of course these days your VMware type systems tend to end up in this state when you're running more than one at a time.
Cooperative multitasking. This is very easy to implement, I did one in Forth that was about 16 lines of code. User-mode threads generally implement cooperative multitasking within a process. It's a kind of "Hello World" for OS design. There's a very short set of systems I can think of that exposed this at the application level. Polyforth. Mac OS. 16-bit Windows.
That's about it.
The rest, from AmigaDOS through Mac OS X, even including 32-bit Windows to a pretty great degree, and of course including the NT based Windows and every UNIX implementation ever, they are all using preemptive multitasking.
If Apple hadn't resorted to cooperative multitasking to avoid facing some bad design decisions back in the original single-tasking Mac OS, and Windows hadn't copied some of those bad design decisions, nobody would even think of preemptive multitasking as being something special. When someone talks about preemptive multitasking being a feature, it's like they're suggesting that putting tires on cares is kind of an exciting innovation. It's, well, it's just how multitasking is DONE.
"We don't want courts or legislation dictating how we provide our content. Just like we don't want courts and legislation dictating how we should consume our content."
I interpret that as suggesting that all laws regulating production and consumption of content should be struck down.
I interpreted it as saying that the industry rather than government should be in the business of defining standards, technical requirements, and so on.
why wouldn't you think that Windows, which is produced by a completely market-oriented company, would be shaped by the same influences?
Sure it is, but unless you have competition you don't evolve any further. That's why you see pages on Microsoft's site titled "What's new with Internet Explorer" with a last-change date some time in 2003.
The market doesn't work without competition. Microsoft doesn't have any competition because they evolved a strategy of expanding by locking out competing products rather than expanding by finding and discovering new markets. They're the economic equivalent of a an organism that's so perfectly adapted to their evolutionary niche they hardly ever need to change.
I mean, let's look at IBM. Microsoft kicked IBM;s keister in the desktop OS market. If IBM had been like Microsoft, that would have been the end of the story... but IBM is way bigger than Microsoft and does a little bit of everything, it's always picking up new products (Linux, say) and dropping or spinning off ones that that aren't cutting it any more.
Microsoft, on the other hand, is totally devoted to "Windows Everywhere". That's pretty much their only criterion for deciding the value of a business or a product... how many copies of Windows will it sell?
And that's why market forces mean something completely different for Microsoft. They can ignore the market for half a decade, like they did with Internet Explorer, and still have a 90% market share. Let's say Longhorn doesn't come out until 2011, and Windows XP is 10 years old and on Service Pack 5. What do you think the effect Microsoft's market share would be? Down 5%? Or do you think it might actually be down 10%? I wouldn't bet on it. They're almost halfway there and they're not even hurting.
Can you elaborate on the relationship you see between your comments about patents and copyrights and the OP's comments about DRM and the DMCA.
What's the connection you're trying to make? Something about the DMCA? Something about DRM?
What do laws mandating the presence or absence of DRM or any particular DRM technology have to do with the desirability of copyrights or patents? Alternatively, what do the anti-reverse-engineering provisions in the DMCA have to do with it?
It's true, but remember with that comes 2 more bits of register file address in every instruction.
One more bit. You get 2x from having twice the registers, and another 2x from them being twice as wide. This isn't as good as having 4x the registers but it does help some.
As for the encoding... it's hard to imagine an instruction set encoding that could be WORSE than the x86.
My mother, my father, and probably anyone over the age of 40.
Ah, and these are the people who are passing music around on the P2P networks? But never mind that...
Audio tape recording has been made simple and obvious: there are two decks, one of them has a Record button right by the Play button. Most people, though, would be surprised to discover that a sound card can actually accept sound!
Where did I say anything about the sound card being an input device? They were recording stuff to tape, what's stopping them from recording this stuff to tape. I know people like that are recording FM radio to tape, because MY Mom and Dad have sent me enough of the results... this is basically the same thing.
When AMD designed the x86-64 instruction set some of the early prototypes had more registers exposed. However that left less registers available to the optimizers on this chip (I forget what they call this), so the performance was less with more registers.
Register renaming, I think, or the recompiler that needs to do it.
Register renaming is a tool developed to deal with the fact that you don't have enough registers, so the compiler can't do enough optimization, so you have to slide a register that's still holding a result out of the way to keep working on later instructions that want to write to the same register once it's available.
If you have enough registers you can get rid of the whole thing and shorten the pipeline and that's even better. Not only is a shorter pipeline faster clock for clock, other things being equal, but the compiler can see a bigger chunk of code than the recompiler on the chip, and it's bigger and smarter as well... so if the compiler does the register allocation (all other things still being equal, of course) it can do a better job.
The problem things aren't equal. AMD64 doesn't have the luxury of exposing as much internal state to the compiler as Alpha or even older RISCs (let alone pulling some of the nasty pranks on the compiler that Intel's trademark psycho architectures... i860 and IA64, or even old iAPX432... are wont to do). The problem is AMD64 has to keep the chunk of hardware that does the register renaming around anyway because it's still got to run IA32 code really fast.
Yes, but the 8086 and descendants is easier to make go fast than the PDP-11 could have been, because the memory-memory architecture turned out to be much much harder to pipeline. The VAX was even worse, which is why DEC came up with the lovely Alpha.
But artistically the PDP-11 was unsurpassed. Consider the strange beauty of these fragments:
You're missing the point (that is, it doesn't matter if the mbone wasn't "for streaming media", it was still an early and significant use of the mbone and it still predated Real's unicast streaming media by years.
But not only are you missing that point, you're using an argument that makes absolutely no sense. You're arguing against points that aren't being made, and on top of that it's only correct in some kind of strict mathematic sense that's divorced from reality. For example:
It was designed to create a multicast infrastructure.
And what is a multicast infrastructure good for? What does it do really well, and what does it do badly? Well, what it does best is sending the same data to a bunch of different end-points at the same time. It's really good at streaming, but that's about it. Pretty much anything else it does badly because of the need for all the participants to be operating on the same schedule.
then who were all those people sharing music on the P2Ps? Or making copies of CDs , and before that, tapes?
Tell me, who is this person who can figure out how to make a copy of a tape but can't figure out how to plug that 3.5mm jack into the back of the computer instead of the back of the casette player?
x86-64 Windows is completely incapable of running 16-bit DOS executbles. While you may think this is unimportant, unfortunately far too many dumb websites still distribute those "self extracting" archives that are 16-bit DOS executables.
Oh good, that means that maybe, just maybe, they'll have to quit using these Windows-specific malware-promoting abominations! Thank you' I really appreciate a bit of good news.
Slashdot Mirror
In Windows, bringing a window to foreground effectively re-nices it to a higher priority.
And just what the hell does that have to do with whether the mouse pointer tracks or not?
Yeh, give the interactive task more CPU, that's fine, that's what "nice" is all about, after all. The thing is, though, it doesn't matter in Windows, X11, NeXTstep, AmigaDOS, or, well, anything that isn't a freshman CS cooperative multitasking system... it doesn't matter in any of them whether the foreground task is busy, hung, dead, hung over, stoned, or depressed... it's not the thing that's moving the mouse pointer.
Got it?
That kind of deep user interface failure isn't caused by bad scheduling, good scheduling, or bad-cop-good-cop scheduling. It's caused by X11 deciding that this is a good time to let latency go hang. Because it's not a real-time system, and it doesn't give the user interface itself the kind of loving personal hands-on attention that the rest of the GUI based systems do, because that's not what it was designed for.
That's all.
That's all.
"What's daddy doing?"
"He's installing a new game on the computer. It keeps you from playing the other games, if you can crack it, maybe you can get a summer job at Microsoft. Wouldn't that be nice?"
2 factors in this were dynamic priority boosting (a runnable task that had been 'starved' for too long would get its priority boosted untill it became high enough for it to get a timeslice)
When I started using UNIX back around '78 it had already been doing that kind of priority juggling for so long that you just assumed it was there.
No, really, it's not the scheduler. Juggling priorities so that interactive tasks get priority over compute bound ones is precambrian. It's not what makes OS/2 and other operating systems that provide good interactive response what they are. Do you want to know what it is? It's the whole GUI design. It's recognising that a GUI is a real-time environment, one in which the time a result is generated is part of whether the result is correct or not. It's taking advantage of the fact that the display is computationally close to the user. It's all kinds of things.
X11 is not a real-time design. X11 is designed to provide decent display update speed... decent throughput... over networks that have inadequate bandwidth and totally inadquate latency. It's not as good at it as schemes like NeWS (now there's a sweet design) that split the whole user interface away from the heavy lifting and let you run the GUI in a lightweight scripting language in the display server itself... but that's the environment it was designed for. It wasn't designed to give you any guaranteed response time, it was designed to make sure you could get any response at all. By design, it defers and batches transactions. It can deliberately delay updates so it can bundle operations together and send a single packet to the display instead of having to sith through 6 or 8 turnarounds.
THAT is why now that you have a 2 GHz 64-bit processor and a graphics card that by itself has more CPU power than the whole of Project Athena at MIT did... that is why you can have all that and when things get busy it gets delayed.
The differences between the design of X11 and OS/2 are so profound that they utterly swamp trivia like a slightly different scheduling algorithm.
We haven't seen a man like this in the White House since Andrew Jackson.
One thing OS/2 seems quite good at doing is adjusting various process priorities to make the user experience a smooth one.
I doubt that what you're seeing has anything to do with process priorities or scheduler design. The unfortunate design decisions that have produced the kinds of glitches you see in the current X-based desktop environment are buried much deeper and are harder to fix than simply tweaking the scheduler.
But, god knows, it could have been worse.
Um, even Microsoft managed to figure that one out.
There's three main ways that personal computer operating systems have implemented multitasking. Round robin timeslicing, preemptive multitasking, and cooperative multitasking.
Round robin timeslicing is used when the programs being shared are running under a virtual machine of some kind, and have no way to give up the CPU. The old timeslicers for DOS used this, and of course these days your VMware type systems tend to end up in this state when you're running more than one at a time.
Cooperative multitasking. This is very easy to implement, I did one in Forth that was about 16 lines of code. User-mode threads generally implement cooperative multitasking within a process. It's a kind of "Hello World" for OS design. There's a very short set of systems I can think of that exposed this at the application level. Polyforth. Mac OS. 16-bit Windows.
That's about it.
The rest, from AmigaDOS through Mac OS X, even including 32-bit Windows to a pretty great degree, and of course including the NT based Windows and every UNIX implementation ever, they are all using preemptive multitasking.
If Apple hadn't resorted to cooperative multitasking to avoid facing some bad design decisions back in the original single-tasking Mac OS, and Windows hadn't copied some of those bad design decisions, nobody would even think of preemptive multitasking as being something special. When someone talks about preemptive multitasking being a feature, it's like they're suggesting that putting tires on cares is kind of an exciting innovation. It's, well, it's just how multitasking is DONE.
Damn, why didn't he have that idea BEFORE starting work on the Fandom Menace.
Not impressed at all, will be looking for another anti-virus solution. Any suggestions?
Apple's coming out with a really great one this Friday.
"We don't want courts or legislation dictating how we provide our content. Just like we don't want courts and legislation dictating how we should consume our content."
I interpret that as suggesting that all laws regulating production and consumption of content should be struck down.
I interpreted it as saying that the industry rather than government should be in the business of defining standards, technical requirements, and so on.
why wouldn't you think that Windows, which is produced by a completely market-oriented company, would be shaped by the same influences?
Sure it is, but unless you have competition you don't evolve any further. That's why you see pages on Microsoft's site titled "What's new with Internet Explorer" with a last-change date some time in 2003.
The market doesn't work without competition. Microsoft doesn't have any competition because they evolved a strategy of expanding by locking out competing products rather than expanding by finding and discovering new markets. They're the economic equivalent of a an organism that's so perfectly adapted to their evolutionary niche they hardly ever need to change.
I mean, let's look at IBM. Microsoft kicked IBM;s keister in the desktop OS market. If IBM had been like Microsoft, that would have been the end of the story... but IBM is way bigger than Microsoft and does a little bit of everything, it's always picking up new products (Linux, say) and dropping or spinning off ones that that aren't cutting it any more.
Microsoft, on the other hand, is totally devoted to "Windows Everywhere". That's pretty much their only criterion for deciding the value of a business or a product... how many copies of Windows will it sell?
And that's why market forces mean something completely different for Microsoft. They can ignore the market for half a decade, like they did with Internet Explorer, and still have a 90% market share. Let's say Longhorn doesn't come out until 2011, and Windows XP is 10 years old and on Service Pack 5. What do you think the effect Microsoft's market share would be? Down 5%? Or do you think it might actually be down 10%? I wouldn't bet on it. They're almost halfway there and they're not even hurting.
Would "developer's notes" mean, by any chance, the same thing as source code for this woman?
I suspect she's referring to the comments.
Can you elaborate on the relationship you see between your comments about patents and copyrights and the OP's comments about DRM and the DMCA.
What's the connection you're trying to make? Something about the DMCA? Something about DRM?
What do laws mandating the presence or absence of DRM or any particular DRM technology have to do with the desirability of copyrights or patents? Alternatively, what do the anti-reverse-engineering provisions in the DMCA have to do with it?
It's true, but remember with that comes 2 more bits of register file address in every instruction.
One more bit. You get 2x from having twice the registers, and another 2x from them being twice as wide. This isn't as good as having 4x the registers but it does help some.
As for the encoding... it's hard to imagine an instruction set encoding that could be WORSE than the x86.
So Kodak got away with it at the low and and now Nikon thinks they can get away with it on digital.
"And has any camera manufacturer ever mandated what film processing methods must be used with photographs taken with their camera?"
I thought that was one of the reasons for Kodak coming up with their silly disk cameras.
My mother, my father, and probably anyone over the age of 40.
Ah, and these are the people who are passing music around on the P2P networks? But never mind that...
Audio tape recording has been made simple and obvious: there are two decks, one of them has a Record button right by the Play button. Most people, though, would be surprised to discover that a sound card can actually accept sound!
Where did I say anything about the sound card being an input device? They were recording stuff to tape, what's stopping them from recording this stuff to tape. I know people like that are recording FM radio to tape, because MY Mom and Dad have sent me enough of the results... this is basically the same thing.
When AMD designed the x86-64 instruction set some of the early prototypes had more registers exposed. However that left less registers available to the optimizers on this chip (I forget what they call this), so the performance was less with more registers.
Register renaming, I think, or the recompiler that needs to do it.
Register renaming is a tool developed to deal with the fact that you don't have enough registers, so the compiler can't do enough optimization, so you have to slide a register that's still holding a result out of the way to keep working on later instructions that want to write to the same register once it's available.
If you have enough registers you can get rid of the whole thing and shorten the pipeline and that's even better. Not only is a shorter pipeline faster clock for clock, other things being equal, but the compiler can see a bigger chunk of code than the recompiler on the chip, and it's bigger and smarter as well... so if the compiler does the register allocation (all other things still being equal, of course) it can do a better job.
The problem things aren't equal. AMD64 doesn't have the luxury of exposing as much internal state to the compiler as Alpha or even older RISCs (let alone pulling some of the nasty pranks on the compiler that Intel's trademark psycho architectures... i860 and IA64, or even old iAPX432... are wont to do). The problem is AMD64 has to keep the chunk of hardware that does the register renaming around anyway because it's still got to run IA32 code really fast.
Bummer, eh?
Xerox attempted to sue Apple over some GUI elements.
Apple sued Microsoft over some GUI elements.
This lead to Xerox suing Apple over claims Apple made in that lawsuit.
Xerox didn't sue Apple because they copied something from Xerox, they sued Apple because they believed Apple's lawsuit hurt Xerox's own rights.
Yes, but the 8086 and descendants is easier to make go fast than the PDP-11 could have been, because the memory-memory architecture turned out to be much much harder to pipeline. The VAX was even worse, which is why DEC came up with the lovely Alpha.
But artistically the PDP-11 was unsurpassed. Consider the strange beauty of these fragments:andandand
You're missing the point (that is, it doesn't matter if the mbone wasn't "for streaming media", it was still an early and significant use of the mbone and it still predated Real's unicast streaming media by years.
But not only are you missing that point, you're using an argument that makes absolutely no sense. You're arguing against points that aren't being made, and on top of that it's only correct in some kind of strict mathematic sense that's divorced from reality. For example:
It was designed to create a multicast infrastructure.
And what is a multicast infrastructure good for? What does it do really well, and what does it do badly? Well, what it does best is sending the same data to a bunch of different end-points at the same time. It's really good at streaming, but that's about it. Pretty much anything else it does badly because of the need for all the participants to be operating on the same schedule.
then who were all those people sharing music on the P2Ps? Or making copies of CDs , and before that, tapes?
Tell me, who is this person who can figure out how to make a copy of a tape but can't figure out how to plug that 3.5mm jack into the back of the computer instead of the back of the casette player?
Maybe not for you or me, but the average user has no idea how to record or rip streamed audio.
In other words DRM only provides protection against people who are not normally interested in abusing the video stream that are protected by it.
x86-64 Windows is completely incapable of running 16-bit DOS executbles. While you may think this is unimportant, unfortunately far too many dumb websites still distribute those "self extracting" archives that are 16-bit DOS executables.
Oh good, that means that maybe, just maybe, they'll have to quit using these Windows-specific malware-promoting abominations! Thank you' I really appreciate a bit of good news.
and I think "mark stack" made special use of R5
If I understand what you're talking about... you could use any register as the linkage register in the standard call/return model.
You also forgot that if you had EIS then some instructions only worked on even register pairs.