The current glass in cars (for windshields) is SAFETY glass. Essentially, the glass itself is fragile on purpose, and the polyvinyl butyral in the middle only serves to hold the glass fragments together. The glass is supposed to disintegrate when faced with large stresses, but remain stuck to the polyvinyl butyral film. Plexiglass simply will not offer the disintegration behavior, as its designed for the exact opposite purpose and will not disintegrate.
So what? That doesn't stop you from using space partitioning, LODs or other tricks.
You can use them all you want.. it doesnt help even if you originally had 100 million polygons but culled that set down to only 1 million polygons and sent them to the renderer. Thats the number. 1 million to the renderer, which then must render everything its told to render. You dont get to cull the geometry twice.
You continue to fail to make the distinction between a game engine and a renderer. You seem to think that its the renderers job to cull the geometry. Nope. No it isn't. Its the renderers job to render the geometry its told to render. The culling happens elsewhere, and is certainly of great benefit, but has no bearing on the study in question which studied the number of polygons rendered.
We are talking about games here, not about moving a single object around. Games have hundreds of objects and easily thousands of particles flying around all over the place, they also have vertex shader running the bone deformation on every organic looking thing around and a physics engine crumpling your car. That is quite a different thing then having a tech demo where one object gets moved a little a bit.
One object? Looks to me like a few dozen animated soldiers walking around at the beginning, and above the far building where all those soldiers are walking around, a particle effect with what looks like thousands of individual independently moving particles. This is right in the first 30 seconds or so of the video. Perhaps you should actually watch it.
You are also grasping here because you are now trying to invoke larger numbers of objects, but that doesnt help the rasterizer any. The more objects there are, the better raytracing does in comparison at actual rendering. Both engines need to visit each dynamic object each frame and update them, so they are both at O(n) already.
You dont seem to understand runtime complexity either. You are arguing over constants here. If we cared about the constants, we would all be using insertion sort, because it has the cheapest constant. Sure.. for large N a sort algorithm with better runtime complexity like quicksort wins.. but why care about that.. lets focus on the constants like you want. Lets all use insertion.
Sunspider shows Safari as fastest, V8 Chrome as fastest (at least last I checked), and the Mozilla bench was a more mixed result.
On my Windows 7 system (AMD 1055T) with latest Release versions, Opera edges ahead of both at their own games, and Firefox isnt even in the running yet on those but its performance has increased substantially in the last year.
I understand that Safari is much better on Mac's than it is PC's.
The thing about Dromeao, Mozilla's previous benchmark suite, was that it incorporated these others. Firefox's javascript speed improved substantially since Dromaeo.. and now I think that they have lost their way, as if they have unofficially given up matching performance and are now going to grade themselves on a curve.
I actually have read the article, and it doesn't invalidate my statement.
...'cept for the fact that its not a press release... the entire premise of your post... yeah, other than that your statements arent invalidated at all.
Academic fairy land. Polycounts will never get high enough. There is a physical limit on how many polygons a animator/modeller/rigger can actually handle in a sane way.
Arent you making an assumption here? Most models these days are not generated 1 polygon at a time. They use advanced packages that generate most of the geometry for them, where the modeller's job is more like a supervisor than a carpenter.
A LOD only needs enough polygons to look good on screen, if you add more detail that isn't visible from a distance,
The fact that you cant get over this LOD stuff is mind-boggling, but I think I know why. You dont know the difference between a game engine and a renderer. A renderer renders the polygons it is told to render, which is what was under study. All game engines have a renderer behind them, by it OpenGL, DirectX, etc... these API's do not reduce detail/etc.
The research was quite clear. The sweet spot where raytracing (a rendering method, not a game engine) better scalability begins to pass rasterization (a rendering method, not a game engine) is 1 million polygons.
A raytracer is only fast for static scenes, if you have something dynamic and need to update your space partitioning for the raytracer, the whole O(log n) magic kind of falls apart.
We are talking about O(dynamic objects) here, not O(triangles).. which is why many videos of realtime raytracing since 2007 or so have included.. dynamic scenes.. such as the one linked to in this article.. which I guess you didn't watch.
Or it could just do LOD with a geometry shader on the GPU.
LOD doesnt absolve the scaling problem. Lets say you have a system set up for 25% LOD versions of the geometry, but then double the number of polygons in the geometry.. well you have also doubled up the polygons in the LOD versions as well.
Your thinking only applies if "Double Polygons" = "Double-Sized World"... whereas the study was on the visible geometry itself, which has nothing to do with the size of the world, where "Double Polygons" = "Double Detail"
Game developers no longer worry about the number of polygons "in the world".. there are plenty of log n algorithms for ignoring that issue (bsp's, quad tree's, and a plethora of other common scene graphs). The issues they face are dealing with the number of polygons "on screen right now".. There are few unexplored tricks to faking more geometry than is actually there... pixel shaders are more than enough these days to do almost anything you can think of. The techniques are what they are, and each polygon must be visited and sent to the renderer (because its on screen!) and thats why its O(triangles) for rasterization.
The problem is that you don't just want high polygon counts, but high polygon counts for dynamic objects. And ray tracing itself has its strength in static objects, as soon as stuff moves and deforms, ray tracing runs into quite a few issues, not necessary unsolvable issues, but that demo was rather lacking in that aspect as the particle system looked like complete garbage compared to todays games.
They also didnt spend a hundred million making the game. Sure, raytracing has issues... I think the biggest one that you missed is the much higher cost of anti-aliasing.. for rasterizers, anti-aliasing techniques pretty much fall right out of it.. for raytracers they either need to do super-sampling or actually implement a hybrid with cone-tracing for when a ray hits a polygon edge.. (which has its own issues with regard to reflections and refractions, where the size of the cone possibly becomes nearly 360-degrees after a few bounces)
In the end it is inevitable tho, and it is precisely because of how things scale.. for rasterizers every doubling of visible geometry doubles the computational resources required.. but for raytracers increasing geometry can almost be shrugged off as inconsequential... to put this as clear as day, a raytracer spends 20 iterations per ray for a million polygons, and 30 iterations for a billion polygons. A thousand-fold increase in geometry only requires 50% more computational resources. Once we hit that sweet spot where rasterization and raytracing are about equal in performance, it becomes dumb not to start piling on as much geometry as memory permits.
What makes DSL "crap"? It's usually cheaper than cable and if the ISP knows their stuff you'll always get what you pay for.
The same can be said for Cable as far as getting what you pay for. In both cases your connection merges into a fatter shared line.. the only difference is where, physically, that this happens.
Telephone copper has its upsides in that often the sharing point is at the switches themselves, so its at a centralized location where upgrades and reconfigurations are cheaper overall. It also has its downsides, for example if the dedicated portion of your wire is unusually noisy, well then you are only 1 customer.. and the problem could be anywhere between you and the switch that is miles away.. you have the leverage of a toothpick and are unlikely to get it resolved any time soon.
For cable coax.. the upside is that if you are having problems, either the entire neighborhood is having the same problems (lots of leverage to get it resolved) or the problem is between the telephone pole and your modem (much simpler/cheaper to find and resolve).. the data carrying capacity of cable is also certainly much greater, even if the current hardware doesnt take advantage. The downside is of course that upgrades are much more expensive for the provider because the network is far less centralized, with a couple more routine levels too.
This is the true advantages of raytracing. A rasterizer would have to deal with each and every triangle in that chandelier.
Rasterizers scale on O(triangles) while raytracers scale on O(pixels * log triangles). I dont remember if it was Microsoft Research or something out of Intel, but 5 or so years ago they did some scalability testing and concluded that about 1 million polygons was the sweet-spot where raytracing and rasterization were about equal in efficiency using the per iteration constants derived in their testing.
This was based on visible geometry only, so no pretending that the fact that rasterizers can use logarithmic data structures for hidden surface removal, that that makes any bit of difference.
Since then, triangle counts have remained about the same in games (with more per-pixel processing being done to simulate more geometry,) but the number of pixels have quadrupled as higher and higher resolution displays have become common. Yet they are reaching the limits with the fakes that can be done with shaders, and resolution is probably not going to go through another quadrupling, so raytracing really is comming.. just not quite yet.
When the polygon counts do get high enough, there will be no looking back. Raytracing will be here to stay after that because of the way it scales. At 1 million polygons, a raytracer spends 20 iterations per ray cast using a logarithmic structure.. doubling the number of polygons to 2 million only adds 1 more iteration.. or about 5% more processing power required, and doubling again only adds another ~4.5%, and so on.. meanwhile each doubling of polygons on the rasterizer literally doubles the processing power required.
Ah but that's a direct refusal to utilize the software repos as a trusted source. Just because a user refuses to get their software from a trusted source does not constitute a flaw in the trusted source.
The original argument was that this worm represented an actual security flaw in Windows, rather than a willingness to run untrusted code.
Windows users run untrusted code because most of them dont have critical files, or in the case of work machines, they aren't their critical files. Calling their nephew to clean up the infected machine is all the effort they need to put in to fix the problem.
Additionally, a single central repository wont work for windows. The amount of demand from all sides would be too high. On the one side the number of package maintainers for a typical linux repository is relatively small because there arent a thousand new submissions per day. For windows, there would literally be way more than 1000 per day. On the other side, Linux repositories don't have a the better part of a billion people downloading programs so the bandwidth costs arent prohibitive.
The mainly-repository idea just doesnt work for Windows, and there are repositories that dont have package managers for windows that already exist (TUCOWS, etc.. this is nothing new.) The scale of the windows market is just too big for these to have a prophylactic effect, and also too big for these repositories to even keep up (most have given up.)
1. a planning and acting together secretly, esp. for an unlawful or harmful purpose, such as murder or treason
2. the plan agreed on; plot
3. the group taking part in such a plan
4. a combining or working together: the conspiracy of events
Only one of these requires secrecy.
I realize that an active defender of these scientists behavior doesnt like the word being used, but you cannot deny that it is being used correctly and does apply to these scientists.
I question your motives. Can I presume that you have a strong opinion about the veracity of the AGW theory? Me, not so much either way. I do however have a strong opinion about the corruption of the peer review process that permeates more than this field (its much worse in the Pharmaceutical journals) and simply will not tolerate or give-a-pass to conspiracies that interfere with what is supposed to be a forthright process.
The fact that the Journal published some shit at the behest of one of its opinionated editors is of less concern. If the choice is between Opinionated Editors and Manipulated Editors, I choose opinionated.
What would you call the western side of Antarctica?
Down there, West = East.
West is towards the setting sun, and when its doing that whole "setting" thing down there, it revolves many times around the entire 360 degrees of horizon. East is towards the rising sun, and when its doing that whole "rising" thing down there, it also revolves many times around the entire 360 degrees of horizon.
So I guess I would call the west side of Antarctica the end result of a disastrously rapid continental drift that somehow managed to not kill me.
Never read anything there before, and apparently you didnt either since the article you are linking to is anything but recent: A version of this article appeared in the DC Examiner on December 2, 2009.
That says very little unless you also say why they did it.
Does it actually matter why? There was an organized conspiracy against a scientific journal that was intended to manipulate its editorial board, with financial harm used as the weapon.
The message the scientists sent to the journals was very clear.. "we have the power to hurt you".. its one thing if they conspired not to cite the paper they disagreed with.. its another to conspire to not cite any paper published by the journal if it prints even one that they disagree with.
There is no doubt that they conspired to manipulate the journal Climate Research. Its right there in the emails in plain cant-be-taken-out-of-context English. What you are citing is that they were cleared of wrong-doing by the very university (UEA = University of East Anglia) that was hacked to attain these emails and plays host the the CRU.
I realize that the many acronym's are confusing and that you thought the UEA was most-likely independent of the CRU.. but its not.
Some bright researchers managed to refine a previous model and come up with better and more accurate predictions. You may want to note how, contrary to some "skeptics" beliefs this wasn't suppressed or refused publication or any other such shenanigans.
It is now a known fact that at least one journal (Climate Research), when publishing papers that the "top dog" climate scientists didn't like, then faced retribution from those same "top dogs" who conspired to then boycott said publication (to not publish in it, or even cite any publications in it) to manipulate its editorial staff. This came to light less than a year ago when communications between those "top dogs", which were lifted from the University of East Anglia's servers, contained emails documenting their conspiracy against this publication.
It should come as no surprise that more dissenting papers are being published now than were before, as those conspiring "top dogs" have lost much of their influence.
holding back the product to build up demand can work as an intentional strategy, I suppose it can also work as an unintentional strategy
This is like saying that Prohibition was an intentional or unintentional organized crime profit strategy.
It was the radio stations that refused to play them, not the Beatles producers or agents. The radio stations didnt benefit one way or the other. The Beatles had a stroke of luck befall them, pure and simple. Not that they werent good, but they just wouldnt have been nearly as successful... probably more like Eric Clapton level of success instead of Beatles Mania level of success.
The real kicker is that the ISP's would rather not have people tricked into P2P sharing either, and they also have a vested interest in seeing the demise of intentional P2P sharing as well.
Bittorrent especially is bad for ISP's because it is designed to fully saturate any endpoint they could dream up. No matter how much they invest in your local connection, bittorrent will saturate it, and by design it doesnt require the senders to have made the same sort of investment that was put into the receiving connection (my 6mbit cable is no match for a thousand disparate 56K modems all throwing data at me.)
It is no surprise that ISP's throttle P2P programs. It used to be that when a thousand machines all started sending data to the same address, we called it a Denial of Service Attack. Now we expect it as a "feature."
I like the idea of Bittorrent.. but I'm not an ISP. They don't like the idea of Bittorrent for obvious reasons.
Well I can tell you this about the Beatles and the "mania" of the United States.
For a significant period of time American radio stations would not play any Beatles songs, and this was in spite of the fact that in England they had many #1 hits. 4-piece guitar bands were "on the way out."
When American radio stations DID decide to start playing The Beatles, they introduced many of those #1 hits to the American audience at the same time. And thus, Beatle Mania was born. There was a period where half of the top-10 was Beatles, and not because of marketing genius, but because of the initial reluctance to play them.
For CISC you need more bytes per instruction, because there are more instructions.
pssst... not true. RISC machines have more registers to offset their lack of read/modify/write instructions. Doubling the number of registers has a greater effect on instruction size (2 more bits needed to encode twice the source (+1) and destination (+1) regs) than doubling the number of instructions (1 more bit needed)
Slashdot Mirror
Perhaps finally we have here a magnetic strip that isn't prone to being stripped of its information?
The current glass in cars (for windshields) is SAFETY glass. Essentially, the glass itself is fragile on purpose, and the polyvinyl butyral in the middle only serves to hold the glass fragments together. The glass is supposed to disintegrate when faced with large stresses, but remain stuck to the polyvinyl butyral film. Plexiglass simply will not offer the disintegration behavior, as its designed for the exact opposite purpose and will not disintegrate.
So what? That doesn't stop you from using space partitioning, LODs or other tricks.
You can use them all you want.. it doesnt help even if you originally had 100 million polygons but culled that set down to only 1 million polygons and sent them to the renderer. Thats the number. 1 million to the renderer, which then must render everything its told to render. You dont get to cull the geometry twice.
You continue to fail to make the distinction between a game engine and a renderer. You seem to think that its the renderers job to cull the geometry. Nope. No it isn't. Its the renderers job to render the geometry its told to render. The culling happens elsewhere, and is certainly of great benefit, but has no bearing on the study in question which studied the number of polygons rendered.
We are talking about games here, not about moving a single object around. Games have hundreds of objects and easily thousands of particles flying around all over the place, they also have vertex shader running the bone deformation on every organic looking thing around and a physics engine crumpling your car. That is quite a different thing then having a tech demo where one object gets moved a little a bit.
One object? Looks to me like a few dozen animated soldiers walking around at the beginning, and above the far building where all those soldiers are walking around, a particle effect with what looks like thousands of individual independently moving particles. This is right in the first 30 seconds or so of the video. Perhaps you should actually watch it.
You are also grasping here because you are now trying to invoke larger numbers of objects, but that doesnt help the rasterizer any. The more objects there are, the better raytracing does in comparison at actual rendering. Both engines need to visit each dynamic object each frame and update them, so they are both at O(n) already.
You dont seem to understand runtime complexity either. You are arguing over constants here. If we cared about the constants, we would all be using insertion sort, because it has the cheapest constant. Sure.. for large N a sort algorithm with better runtime complexity like quicksort wins.. but why care about that.. lets focus on the constants like you want. Lets all use insertion.
You obviously dont know x86 assembly, because if you did you would then know that descriptors are a reference to kernel level assembly language.
Sunspider shows Safari as fastest, V8 Chrome as fastest (at least last I checked), and the Mozilla bench was a more mixed result.
On my Windows 7 system (AMD 1055T) with latest Release versions, Opera edges ahead of both at their own games, and Firefox isnt even in the running yet on those but its performance has increased substantially in the last year.
I understand that Safari is much better on Mac's than it is PC's.
The thing about Dromeao, Mozilla's previous benchmark suite, was that it incorporated these others. Firefox's javascript speed improved substantially since Dromaeo.. and now I think that they have lost their way, as if they have unofficially given up matching performance and are now going to grade themselves on a curve.
Pointers are so 1980's... real programmers use descriptors.
I actually have read the article, and it doesn't invalidate my statement.
Academic fairy land. Polycounts will never get high enough. There is a physical limit on how many polygons a animator/modeller/rigger can actually handle in a sane way.
Arent you making an assumption here? Most models these days are not generated 1 polygon at a time. They use advanced packages that generate most of the geometry for them, where the modeller's job is more like a supervisor than a carpenter.
A LOD only needs enough polygons to look good on screen, if you add more detail that isn't visible from a distance,
The fact that you cant get over this LOD stuff is mind-boggling, but I think I know why. You dont know the difference between a game engine and a renderer. A renderer renders the polygons it is told to render, which is what was under study. All game engines have a renderer behind them, by it OpenGL, DirectX, etc... these API's do not reduce detail/etc.
The research was quite clear. The sweet spot where raytracing (a rendering method, not a game engine) better scalability begins to pass rasterization (a rendering method, not a game engine) is 1 million polygons.
A raytracer is only fast for static scenes, if you have something dynamic and need to update your space partitioning for the raytracer, the whole O(log n) magic kind of falls apart.
We are talking about O(dynamic objects) here, not O(triangles) .. which is why many videos of realtime raytracing since 2007 or so have included .. dynamic scenes .. such as the one linked to in this article .. which I guess you didn't watch.
Or it could just do LOD with a geometry shader on the GPU.
LOD doesnt absolve the scaling problem. Lets say you have a system set up for 25% LOD versions of the geometry, but then double the number of polygons in the geometry.. well you have also doubled up the polygons in the LOD versions as well.
... whereas the study was on the visible geometry itself, which has nothing to do with the size of the world, where "Double Polygons" = "Double Detail"
.. there are plenty of log n algorithms for ignoring that issue (bsp's, quad tree's, and a plethora of other common scene graphs). The issues they face are dealing with the number of polygons "on screen right now" .. There are few unexplored tricks to faking more geometry than is actually there... pixel shaders are more than enough these days to do almost anything you can think of. The techniques are what they are, and each polygon must be visited and sent to the renderer (because its on screen!) and thats why its O(triangles) for rasterization.
Your thinking only applies if "Double Polygons" = "Double-Sized World"
Game developers no longer worry about the number of polygons "in the world"
The problem is that you don't just want high polygon counts, but high polygon counts for dynamic objects. And ray tracing itself has its strength in static objects, as soon as stuff moves and deforms, ray tracing runs into quite a few issues, not necessary unsolvable issues, but that demo was rather lacking in that aspect as the particle system looked like complete garbage compared to todays games.
They also didnt spend a hundred million making the game. Sure, raytracing has issues... I think the biggest one that you missed is the much higher cost of anti-aliasing.. for rasterizers, anti-aliasing techniques pretty much fall right out of it.. for raytracers they either need to do super-sampling or actually implement a hybrid with cone-tracing for when a ray hits a polygon edge.. (which has its own issues with regard to reflections and refractions, where the size of the cone possibly becomes nearly 360-degrees after a few bounces)
In the end it is inevitable tho, and it is precisely because of how things scale.. for rasterizers every doubling of visible geometry doubles the computational resources required.. but for raytracers increasing geometry can almost be shrugged off as inconsequential... to put this as clear as day, a raytracer spends 20 iterations per ray for a million polygons, and 30 iterations for a billion polygons. A thousand-fold increase in geometry only requires 50% more computational resources. Once we hit that sweet spot where rasterization and raytracing are about equal in performance, it becomes dumb not to start piling on as much geometry as memory permits.
What makes DSL "crap"? It's usually cheaper than cable and if the ISP knows their stuff you'll always get what you pay for.
The same can be said for Cable as far as getting what you pay for. In both cases your connection merges into a fatter shared line.. the only difference is where, physically, that this happens.
.. the data carrying capacity of cable is also certainly much greater, even if the current hardware doesnt take advantage. The downside is of course that upgrades are much more expensive for the provider because the network is far less centralized, with a couple more routine levels too.
Telephone copper has its upsides in that often the sharing point is at the switches themselves, so its at a centralized location where upgrades and reconfigurations are cheaper overall. It also has its downsides, for example if the dedicated portion of your wire is unusually noisy, well then you are only 1 customer.. and the problem could be anywhere between you and the switch that is miles away.. you have the leverage of a toothpick and are unlikely to get it resolved any time soon.
For cable coax.. the upside is that if you are having problems, either the entire neighborhood is having the same problems (lots of leverage to get it resolved) or the problem is between the telephone pole and your modem (much simpler/cheaper to find and resolve)
This is the true advantages of raytracing. A rasterizer would have to deal with each and every triangle in that chandelier.
Rasterizers scale on O(triangles) while raytracers scale on O(pixels * log triangles). I dont remember if it was Microsoft Research or something out of Intel, but 5 or so years ago they did some scalability testing and concluded that about 1 million polygons was the sweet-spot where raytracing and rasterization were about equal in efficiency using the per iteration constants derived in their testing.
This was based on visible geometry only, so no pretending that the fact that rasterizers can use logarithmic data structures for hidden surface removal, that that makes any bit of difference.
Since then, triangle counts have remained about the same in games (with more per-pixel processing being done to simulate more geometry,) but the number of pixels have quadrupled as higher and higher resolution displays have become common. Yet they are reaching the limits with the fakes that can be done with shaders, and resolution is probably not going to go through another quadrupling, so raytracing really is comming.. just not quite yet.
When the polygon counts do get high enough, there will be no looking back. Raytracing will be here to stay after that because of the way it scales. At 1 million polygons, a raytracer spends 20 iterations per ray cast using a logarithmic structure.. doubling the number of polygons to 2 million only adds 1 more iteration.. or about 5% more processing power required, and doubling again only adds another ~4.5%, and so on.. meanwhile each doubling of polygons on the rasterizer literally doubles the processing power required.
Ah but that's a direct refusal to utilize the software repos as a trusted source. Just because a user refuses to get their software from a trusted source does not constitute a flaw in the trusted source.
The original argument was that this worm represented an actual security flaw in Windows, rather than a willingness to run untrusted code.
Windows users run untrusted code because most of them dont have critical files, or in the case of work machines, they aren't their critical files. Calling their nephew to clean up the infected machine is all the effort they need to put in to fix the problem.
Additionally, a single central repository wont work for windows. The amount of demand from all sides would be too high. On the one side the number of package maintainers for a typical linux repository is relatively small because there arent a thousand new submissions per day. For windows, there would literally be way more than 1000 per day. On the other side, Linux repositories don't have a the better part of a billion people downloading programs so the bandwidth costs arent prohibitive.
The mainly-repository idea just doesnt work for Windows, and there are repositories that dont have package managers for windows that already exist (TUCOWS, etc.. this is nothing new.) The scale of the windows market is just too big for these to have a prophylactic effect, and also too big for these repositories to even keep up (most have given up.)
Conspiracies by definition are secret.
1. a planning and acting together secretly, esp. for an unlawful or harmful purpose, such as murder or treason
2. the plan agreed on; plot
3. the group taking part in such a plan
4. a combining or working together: the conspiracy of events
Only one of these requires secrecy.
I realize that an active defender of these scientists behavior doesnt like the word being used, but you cannot deny that it is being used correctly and does apply to these scientists.
I question your motives. Can I presume that you have a strong opinion about the veracity of the AGW theory? Me, not so much either way. I do however have a strong opinion about the corruption of the peer review process that permeates more than this field (its much worse in the Pharmaceutical journals) and simply will not tolerate or give-a-pass to conspiracies that interfere with what is supposed to be a forthright process.
The fact that the Journal published some shit at the behest of one of its opinionated editors is of less concern. If the choice is between Opinionated Editors and Manipulated Editors, I choose opinionated.
What would you call the western side of Antarctica?
Down there, West = East.
West is towards the setting sun, and when its doing that whole "setting" thing down there, it revolves many times around the entire 360 degrees of horizon. East is towards the rising sun, and when its doing that whole "rising" thing down there, it also revolves many times around the entire 360 degrees of horizon.
So I guess I would call the west side of Antarctica the end result of a disastrously rapid continental drift that somehow managed to not kill me.
What crap. Been reading Cato.org much recently? http://www.cato.org/pub_display.php?pub_id=11022
Never read anything there before, and apparently you didnt either since the article you are linking to is anything but recent: A version of this article appeared in the DC Examiner on December 2, 2009.
That says very little unless you also say why they did it.
Does it actually matter why? There was an organized conspiracy against a scientific journal that was intended to manipulate its editorial board, with financial harm used as the weapon.
The message the scientists sent to the journals was very clear.. "we have the power to hurt you".. its one thing if they conspired not to cite the paper they disagreed with.. its another to conspire to not cite any paper published by the journal if it prints even one that they disagree with.
There is no doubt that they conspired to manipulate the journal Climate Research. Its right there in the emails in plain cant-be-taken-out-of-context English. What you are citing is that they were cleared of wrong-doing by the very university (UEA = University of East Anglia) that was hacked to attain these emails and plays host the the CRU.
I realize that the many acronym's are confusing and that you thought the UEA was most-likely independent of the CRU.. but its not.
Some bright researchers managed to refine a previous model and come up with better and more accurate predictions. You may want to note how, contrary to some "skeptics" beliefs this wasn't suppressed or refused publication or any other such shenanigans.
It is now a known fact that at least one journal (Climate Research), when publishing papers that the "top dog" climate scientists didn't like, then faced retribution from those same "top dogs" who conspired to then boycott said publication (to not publish in it, or even cite any publications in it) to manipulate its editorial staff. This came to light less than a year ago when communications between those "top dogs", which were lifted from the University of East Anglia's servers, contained emails documenting their conspiracy against this publication.
It should come as no surprise that more dissenting papers are being published now than were before, as those conspiring "top dogs" have lost much of their influence.
holding back the product to build up demand can work as an intentional strategy, I suppose it can also work as an unintentional strategy
This is like saying that Prohibition was an intentional or unintentional organized crime profit strategy.
It was the radio stations that refused to play them, not the Beatles producers or agents. The radio stations didnt benefit one way or the other. The Beatles had a stroke of luck befall them, pure and simple. Not that they werent good, but they just wouldnt have been nearly as successful... probably more like Eric Clapton level of success instead of Beatles Mania level of success.
The real kicker is that the ISP's would rather not have people tricked into P2P sharing either, and they also have a vested interest in seeing the demise of intentional P2P sharing as well.
Bittorrent especially is bad for ISP's because it is designed to fully saturate any endpoint they could dream up. No matter how much they invest in your local connection, bittorrent will saturate it, and by design it doesnt require the senders to have made the same sort of investment that was put into the receiving connection (my 6mbit cable is no match for a thousand disparate 56K modems all throwing data at me.)
It is no surprise that ISP's throttle P2P programs. It used to be that when a thousand machines all started sending data to the same address, we called it a Denial of Service Attack. Now we expect it as a "feature."
I like the idea of Bittorrent.. but I'm not an ISP. They don't like the idea of Bittorrent for obvious reasons.
Well I can tell you this about the Beatles and the "mania" of the United States.
For a significant period of time American radio stations would not play any Beatles songs, and this was in spite of the fact that in England they had many #1 hits. 4-piece guitar bands were "on the way out."
When American radio stations DID decide to start playing The Beatles, they introduced many of those #1 hits to the American audience at the same time. And thus, Beatle Mania was born. There was a period where half of the top-10 was Beatles, and not because of marketing genius, but because of the initial reluctance to play them.
Fuck! The Apple store is closer! I'm screwed!
With amd64 assembly, you have rax, rbx, rcx, and rdx. If you need to juggle more than that, you go to memory.
You are short a few.
For x86 we've got 8 "general purpose" registers, 8 more SSE registers, and the FPU shares with the 8 MMX registers.
AMD expanded the register space to 16 "general purpose" registers, 16 SSE registers, and continues with 8 MMX registers.
So 40 registers in all, many of them vectors of multiple words.
AVX will likely add another set of 256-bit registers.
For CISC you need more bytes per instruction, because there are more instructions.
pssst... not true. RISC machines have more registers to offset their lack of read/modify/write instructions. Doubling the number of registers has a greater effect on instruction size (2 more bits needed to encode twice the source (+1) and destination (+1) regs) than doubling the number of instructions (1 more bit needed)