I believe Ctrl-F5 is supposed to do a hard-refresh (or something like that), where if a proxy server gets the request, it won't use its own cache, but it will fetch from the source (since there are often a couple of caches along the way, the same instruction needs to be passed along)
Whether or not a proxy obeys it is another issue altogether.
So do you really want to have to tell your os which threads to run on which CPU? It doesn't really scale very well when you have a ga-ba-gillion threads running.
The ability to set affinity is more of a sign that the system isn't perfect yet (it is better than something I could design, but that doesn't mean that I can't say it isn't perfect)
... assuming the OS chooses which threads are executed on which core well enough. If two threads depend on each other heavily and they are running on different cores, you can get really crappy performance.
So the obvious answer would be to move one of the processes to the other core. However, this isn't trivial. You either have one scheduler per core or one scheduler per operating system. (You can't have a single thread sent to both cores easily - if both cores run the same thing at the same time there will be chaos)
If you have one per core, then the scheduler trying to get rid of the thread will have to synchronise with the other core, waiting for the other scheduler to come into context, it then has to tell it to add this new process. Obviously, there is a fair bit of overhead, and if my memory serves me correctly, each core in the current chip has its own cache - so now all the stuff which was cached has to be sent to memory (since it is in the wrong cache) and now there is nothing in the cache, making every memory access slow for the next little while. End result - you can transfer a thread between CPUs, but it is costly.
It is possible to have a single scheduler which can then just dispatch threads to each core as it gets run by each core. The big one here is making the scheduler threadsafe - both CPUs could run the scheduler at the same time, so you have to make sure they don't crap on each other. This is a problem which we have solved already with common synchro-primitives. But, if you just lock the list of threads to run (*), then you will get a whole lot of CPU time wasted just waiting to run the scheduler. It might be acceptable for 2 cores, but it doesn't scale at all.
(*) You may realise (just as I realised) that a scheduler is more than just a list of threads to run (it is typically implemented as a couple of lists for each priority). The same problem still occurs with more than one list of threads, it is just a bit harder for me to express (proof by bad English skills).
Finally, I'm expecting someone to tell me that I'm wrong about something I just said. That person is probably correct. My only experience with this stuff is a 3rd year undergrad operating systems course where we played around with OS161 (a toy operating system basically). But, hopefully the end conclusion will be the same: twice the number of processors won't equal twice as much performance, and it is tough to get a fast algorithm that will scale.
I haven't RTFA (it was longer than my attention span), so assuming the headline is correct (big assumption), then it would seem that there are currently some people in India who currently hold software patents.
If this is the case, then do these patentsnow have no value? Were they compensated? Or are they ceasing to grant new software patents but old ones are still enforcable?
On the bright side, I like to think that this technology is going to fail miserably. Convincing people to buy into this new technology when people are already happy with DVDs will be tough. Just look at DVD-Audio and SACD. People don't care about quality higher than they can discern.
So, now when (hopefully I don't regret writing "when" instead of "if") the technology fails, they can see that it wasn't due to not having enough restrictions on the media.
Suppose player X has been revoked. Now, I'm assuming that any disks released after this won't work on it right? So, does the packaging for the disk say: "Plays on any player except blah"?
Now, how does this scale, suppose players AAA through ZZZ have been revoked. Do we need larger DVD cases just so we can fit a list of all the players that won't work on it?
Right now the prototype builds a wall which is pretty cool. But how well will this scale to a whole house (or row of houses as the article claims)? Will you need to keep on replenishing its supply of bricks and cement? There still has to be some amount of labour getting this stuff to the machine in such a way that the machine can actually use it.
So if I invented a magical cure which fixed all known diseases then I suppose I would be irresponsible because I'm putting all those medical professionals out of a job?
Yes, if such a thing becomes big (which I doubt, based on no evidence whatsoever), then there will be higher unemployment in this field, and the number of people replacing them in other fields (fields related to these robots) will probably be less. But, society has survived through plenty of changes much bigger than this.
4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
Does this mean that CherryOS has already lost their license to use the source code from PearPC?
Slashdot Mirror
Whether or not a proxy obeys it is another issue altogether.
The ability to set affinity is more of a sign that the system isn't perfect yet (it is better than something I could design, but that doesn't mean that I can't say it isn't perfect)
I just want to make sure people don't think that multicore is a simple thing as your (correct) post makes it out to be.
So the obvious answer would be to move one of the processes to the other core. However, this isn't trivial. You either have one scheduler per core or one scheduler per operating system. (You can't have a single thread sent to both cores easily - if both cores run the same thing at the same time there will be chaos)
If you have one per core, then the scheduler trying to get rid of the thread will have to synchronise with the other core, waiting for the other scheduler to come into context, it then has to tell it to add this new process. Obviously, there is a fair bit of overhead, and if my memory serves me correctly, each core in the current chip has its own cache - so now all the stuff which was cached has to be sent to memory (since it is in the wrong cache) and now there is nothing in the cache, making every memory access slow for the next little while. End result - you can transfer a thread between CPUs, but it is costly.
It is possible to have a single scheduler which can then just dispatch threads to each core as it gets run by each core. The big one here is making the scheduler threadsafe - both CPUs could run the scheduler at the same time, so you have to make sure they don't crap on each other. This is a problem which we have solved already with common synchro-primitives. But, if you just lock the list of threads to run (*), then you will get a whole lot of CPU time wasted just waiting to run the scheduler. It might be acceptable for 2 cores, but it doesn't scale at all.
(*) You may realise (just as I realised) that a scheduler is more than just a list of threads to run (it is typically implemented as a couple of lists for each priority). The same problem still occurs with more than one list of threads, it is just a bit harder for me to express (proof by bad English skills).
Finally, I'm expecting someone to tell me that I'm wrong about something I just said. That person is probably correct. My only experience with this stuff is a 3rd year undergrad operating systems course where we played around with OS161 (a toy operating system basically). But, hopefully the end conclusion will be the same: twice the number of processors won't equal twice as much performance, and it is tough to get a fast algorithm that will scale.
"finish paperwork" is a euphemism for "posting at slashdot"
If this is the case, then do these patentsnow have no value? Were they compensated? Or are they ceasing to grant new software patents but old ones are still enforcable?
(Though it does have 9 too many buttons)
Give them some time, then the malware authors will start writing SP2 dependant stuff and we'll all be much better off.
So, now when (hopefully I don't regret writing "when" instead of "if") the technology fails, they can see that it wasn't due to not having enough restrictions on the media.
Now, how does this scale, suppose players AAA through ZZZ have been revoked. Do we need larger DVD cases just so we can fit a list of all the players that won't work on it?
In a battle between WiMax and Doppler shift, I'm putting my money on Doppler.
Avoiding flash, popups and cookies gives you IT_literacy++.
Me too
-1 meme-bait.
Right now the prototype builds a wall which is pretty cool. But how well will this scale to a whole house (or row of houses as the article claims)? Will you need to keep on replenishing its supply of bricks and cement? There still has to be some amount of labour getting this stuff to the machine in such a way that the machine can actually use it.
Yes, if such a thing becomes big (which I doubt, based on no evidence whatsoever), then there will be higher unemployment in this field, and the number of people replacing them in other fields (fields related to these robots) will probably be less. But, society has survived through plenty of changes much bigger than this.
Andy
"Overwhelming Demand" Not being anal, but I don't think they were ever popular.
4. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
Does this mean that CherryOS has already lost their license to use the source code from PearPC?