the disassembled bits of rodent are already capable of level flight when hooked up to a simulator of an F-22.
BFD. So can a couple of PID loops. Now show me a rat brain that can navigate and fly the plane to a cheeze factory and I'll be impressed. Oh, but that involves a lot more than making a simple feedback loop...
A great musician can make a living doing live performances. People who need 6 takes of each line in a studio followed by some DSP cleanup and effects are the ones who want DRM to maximize profits through heavily advertised music sales. Several pop stars come to mind. When the music IS the product, you want DRM. When you sell yourself as a musician, you don't.
The video card makers can offload the vertex "shader" stuff back to a thread on the main CPU. Then you get a cheaper GPU by making use of the second/third core. Yes, this is a step in the wrong direction for them - moving graphics back to the CPU;-) Maybe Intel will do it with their integrated graphics - or did they drop that stuff?
Laws that require a bunch of exemptions need to be revisited. It's just like when software gets too many nested conditionals - you know the logic needs to be cleaned up or scrapped. Has anyone ever tried to apply complexity measures to portions of the law?
AFAIK, the only problem QCs are good at solving is factoring (and the discrete logarithm problem which is equivalent). Does anyone know a complete list of problems they are supposed to be good for? I don't think it's very long. OTOH, research may provide more over time.
Google already pays for high bandwidth to allow fast access for its users. Users already pay for more bandwidth if they're not happy with the response of web sites. ISPs already get theirs. Once again the information highway analogy works well. You don't make a lot of money building roads (though it is a reasonable business). You make money by having someplace people want to go using those roads.
ISPs are like toll roads, and now they want to charge more depending who you are. That isn't going to work. Fortunately there are other roads and ISPs.
Millions of people use Windows every day and don't see anything wrong with it. They think getting viruses is normal. They think Spyware is normal. They think paying for software to fix problems with other software they paid for is normal. They're in that mindset where they can't really see how an alternative could be better. Much like you with X.
BTW, I don't think X is bad either. Nor is it all that precious.
So now that it's been made a big deal... Politicians can start annonymously slaming their oponents on Wikipedia. They can change them back of course, but then they'll go edit the entry for their oponents too. Repeat, repeat, repeat. Do they track the frequency of article updates over there? This could get stupid real fast.
BTW, I'm really tired of seeing companies and products mentioned in Wikipedia. It's becoming another ad-rag.
You say that you'd only do the study if you had control over the methodology, and leave it to the customer (funding source) to decide if it's published or not. You point to benefits weather it's published or not. I would argue that you should only do work if you are allowed to publish the result no matter what. Why? Microsoft could afford any number of such studies (and probably does). This gives them the option of selecting ones for publication that make them look good. In this case, the GLIBC upgrade caused pain for the Linux side. Other researchers are bound to run across different problems with either OS. The practice of leaving publishing decisions to the funding source allows them to present only favorable results to the public if they so choose. I'll leave comments about your research methodology to others, but I insist that your publishing methodology is deeply flawed. By agreeing to such terms, you ensure that the public will only see results favorable to the funding source. How is that objective?
You suggest that a larger sample or other similar studies would be more insiteful, but you know that more were likely conducted. Your's was published because the results were favorable to MS - some others were probably not. By agreeing to let MS decide if people see the results, you are skewing the results that the public sees. If you're not concerned about what the public sees, then put it in the contract that the results will not be made public regardless of the outcome.
You're only one sample in the "metastudy" that MS conducted. They show the data selectively because you agreed to let them do so. That's just piss-poor research.
"And people who "meticulously hand optomize" their code annoy the crap out of me."
I'm one of those guys (sometimes). I have a library that has undergone many small performance improvements and is now 2-3 times as fast as when it started. There's even one little run of inline assembler in the most critical part. The code has gone from fairly easy to understand C++ to much less easy to comprehend, so I'd agree that code optimization all the time is not a good thing - it's a tradeoff. People who think there is NO value in optimization annoy the crap out of me.
4) People who actually run benchmarks
5) People who write lower level libraries
You may argue all day long because most people don't care about a 10 or even 50 percent performance difference. As long as the GUI responds in a time that approximates "instantly" people are generally happy.
Does this JAVA version of Q2 run so well on a Pentium?
1) The Itanium
2) HT - Hyper threading - see recent articles about turning it off.
3) The P4 long pipeline used to inflate clock speed with lower performance/cycle
4) The new P4 core (preshot) - more watts, didn't come close to target of 5GHz.
5) Failure to commit to x86-64 resulting in lesser performance.
6) Late to the dual core party.
7) Continued use of the old buss making dual cores suck
8) Late to the integrated memory controller party (comming in like 2007).
9) Oh, and that whole Rambus thing.
If Intel had done what AMD did, and AMD did what Intel did, there would only be one left standing today. IMHO Intel has been living on it's brand name and huge production capacity for some time now.
He could just create a branch that is for regressions and bug fixes only. Then new features could just keep going into the tip. Look at GCC for example. If you look on kernel.org, there's nothing there but the last stable version and the current development version. Where does he think people are going to want to submit their patchs for new stuff? Duh.
Some consideration should be given to portability before you even start. You say to use portable languages and libraries, but that means you've considered portability up front. OK, just doing that doesn't make your code portable, but it will keep you from being locked in when you do decide to port. If you're going to be reading/writing files, or communicating over a network it's also important to consider item #4 mentioned in the review and not lock yourself into any platform specific data structure layouts - otherwise you may release on one platform and find compatibility a BIG issue in the future when you do port. Declaring and using your own types isn't a big deal - I wish I'd learned about it much sooner than I did - it's a pain in the butt to go back and change every variable definition and every cast after the fact when you discover another architecture defines the "standard" types differently.
Some things really should be considered from the start - which you seem to agree with. Others can probably wait, so I don't think you're totally out of line either. Reading of a book like this is probably a good way for people to make reasonable decisions as to which things really should be done up front. I just wish everyone would at least consider portability up front even if they don't plan to do it. Plans change.
Factorization and Primality Testing
on
RSA-640 Factored
·
· Score: 1
The other book Amazon recommends with that one is a really good introduction to the topic. It can bring most slashdot readers up to speed on all the theory and practice up to the Multiple Polynomial Quadratic Seive (MPQS). It does not cover the more recent advances like GNFS which are similar in concept but require more math background.
When the numbers get large enough, is it practical to start writing these algorithms in Python? That would be really cool IMHO.
I was going from memory, but I recall reading that it was a misplace bracket that still allowed the code to compile but changed the meaning of it. A missing bracket of course would fail at compile time. A missing break in a switch statement would be similar and may have been what happened.
For a really interesting mess, I once saw a VB program that contained a conditional goto from the "then" portion of an "if" into the later half of the "else" portion. Yeah, I would have shot the guy if I didn't work for him at the time. OTOH, he knew just how bad it was - but it worked.
"All work produced by a person during the course of his/her employment is owned by the employer, not the employee. Unless this guy had a special employment contract, or coded in his free time?"
IANAL, but I don't think that happens by default. That's why companies have you sign something that makes it explicit.
I interpret this as good news. It means you should be free to modify stuff you bought to make it do your bidding regardless of what the copyright owner may want you to do with it. This would seem to include running DeCSS to make data usable - well if not for the DMCA. Actually, wouldn't the company in this case be guilty of circumventing the "locks" the programmer put in place? That'd be a DMCA violation wouldn't it?
Not enough details in the article about the "ownership" of the code or the charges brought against the company.
"...trained professionals with plenty of experience and oversight, but nevertheless very significant bugs occurred."
Some of the bugs reported in the story were not so much the fault of programmers, but of management. The phone network bug was a misplaced { character in a nested if-else construct. The code had already been though extensive testing, and then a small change was needed. Because it was a "minor" change someone said it didn't need to go through the extensive (expensive) testing again. It's always easy to point at the code or the guy who wrote it. Especially when the boss is the one tasked with finding out what went wrong.
These things don't look like they scale up very well. Wind power is all about swept area - or in this case profile area. To get more power you need more volume of air moving past. How does this type of design scale? Or is it limited to home use?
Exactly. Once the CPU can do everything the GPU can, why buy both? My reason for pointing out that a GPU wont run an OS is to make it obvious which of the 2 parts we will be buying, and which one we won't care about any more.
"1. On another note, as polygon counts skyrocket they approach single pixel size
This is not happening."
Because a GPU is too hard to program for recursively refining nurbs or doing subdivision surfaces on the fly.
I'll pass on #2. I'm not sure what to say - future engines using mutiple cores effectively is somewhat speculative at this point. But lets say you win, so it takes another generation to catch the GPU.
"3. multicore CPUs are nearing the point where full screen, real time ray tracing will be possible. GPUs will not stand a chance."
This might be true, but so what? Ray tracing offers few advantages over the current-gen programmable pipeline."
Once it happens, the GPU will be a redundant component. In spite of all this "general purpose GPU" stuff people keep harping about, it still can't run an OS.
I keep remembering an ad about 15-20 years ago for an add-in card that would do hardware JPEG encoding. It cost over $1000 but was way faster than a PC could do it. The GPUs reign will end. I assure you I am not hallucinating.
"Which approach is going to be most effective but economical for rendering fields of grasses or detailed jungles? How about a snowstorm with snow that gets denser and fog like into the distance? Sand dunes that give way and slide underfoot? Water that breaks around objects and coats them in a wet sheen?"
Most of that stuff can be done with OpenGL/DirectX or ray tracing. Grasses are sometimes done in OpenGL with instancing small clumps. In RT you'd use proceedural geometry or instancing.
For the snow, both renderes would probably do similar techniques.
Sand dunes - either method needs an engine with deformable geometry - both can support that.
Water simulation is something I don't know much about. For the FFT methods of simulating waves it's possible that a GPU has an advantage. Once it start interacting with objects, I don't know how people handle that.
Your quesitons all point toward vast detailed worlds with lots of polygons. RT scales better with scene complexity. To get more traditional methods to work well, you get into fancy culling techniques (HZB comes to mind) and RT starts to look simpler - because it is.
we need more general purpose massively parallel processing units to go beyond current hardware limitations.
Agreed. The current hardware limitation is power dissipation for both CPU and GPU. Hence multi-core from AMD and Intel.
Rendering a 1600x1200 4X AA scene with full filtering on a top tier dual core system would yield perhaps 1fps with an optimized software path.
Speculation. Besides, not many people run at that resolution with FSAA except GPU fanboys.
"You'll end up wanting a MMU" Nonsense.
I've already rendered a multi-millions polygon scene - requiring over 1GB of storage - at low (1-2fps) framerates on a 700MHz Athlon with only 128Meg RAM. MMU and swap was quite useful. I agree it's not a requirement to have scenes larger than main memory in most cases.
GPUs already do everything you need for raytracing. There are demos on the internet.
From the GPU ray tracing paper you point to: "Unfortunately, at the time of writing this, no current GLSL driver runs the ray tracer on GPUs without problems." In addition, they use a uniform grid for their acceleration structure because "there is minimal data access when traversing it". Grids are inferior for large scenes with small detailed objects (teapot in stadium problem). When you move on to real scense with real data structures the GPU will have more problems.
"Actually at that point it makes a lot of sense to move to raytracing " Nonsense. You're off by orders of magnitude.
Actually, thanks for making my case with the link. They used 20 AthlonXP 1800s, so it should run similarly with say 15 AMD64s or an 8 socket dual core box - available today but expensive. Their resolution was low (512x512), but the features of the renderer go beyond what you can do with a GPU.
Maybe they just haven't seen your fast code... *rolls eyes*
Here's my older code. The knight model is about 3000 triangles, so it demostrates the teapot-in-stadium problem (all other models are CSG quadrics). It was only meant as a sort of tech demo in 2001 and was entered in IGF. The RT library is at least 40 percent faster now - on scenes way bigger than a chess board. It's been extended to do photon mapping too (slow). rtChess is one of the only ray traced games out there, and it runs on a CPU not a GPU.
Real time ray tracing is probably not possible on todays CPUs, but in a few years it will be. At that point, why would anyone buy a CPU and a GPU? What OS and applications can you run on a GPU? Oh, they aren't really general purpose are they... *Rolls eyes*
"what, really, is the difference between a GPU and a standard CPU? What is the benefit to having a 3d~acellerator over having a dual~CPU system with one CPU dedicated to graphic processing?"
In a few years, there will be no real benefit to the GPU. Not too many people write optimized assembly level graphics code anymore, but it can be quite fast. Recall that Quake ran on a Pentium 90MHz with software rendering. It's only getting better since then. A second core that most apps don't know how to take advantage of will make this all the more obvious.
On another note, as polygon counts skyrocket they approach single pixel size. When that happens, the hardware pixel shaders - that GPUs have so many of - become irrelevant as the majority of the work moves up to the vertex unit. Actually at that point it makes a lot of sense to move to raytracing (something I have fast code for) which is also going to be quite possible in a few more years on the main CPU(s). Ray Tracing is one application that really shows why the GPU is NOT general purpose. You need data structures and pointers mixed with fast math - preferably double precision. You need recursive algorithms. You'll end up wanting a MMU. By the time you're done, the GPU really would need to be general purpose. The problem doesn't map to a GPU at all, and multicore CPUs are nearing the point where full screen, real time ray tracing will be possible. GPUs will not stand a chance.
Slashdot Mirror
BFD. So can a couple of PID loops. Now show me a rat brain that can navigate and fly the plane to a cheeze factory and I'll be impressed. Oh, but that involves a lot more than making a simple feedback loop...
A great musician can make a living doing live performances. People who need 6 takes of each line in a studio followed by some DSP cleanup and effects are the ones who want DRM to maximize profits through heavily advertised music sales. Several pop stars come to mind. When the music IS the product, you want DRM. When you sell yourself as a musician, you don't.
The video card makers can offload the vertex "shader" stuff back to a thread on the main CPU. Then you get a cheaper GPU by making use of the second/third core. Yes, this is a step in the wrong direction for them - moving graphics back to the CPU ;-) Maybe Intel will do it with their integrated graphics - or did they drop that stuff?
Laws that require a bunch of exemptions need to be revisited. It's just like when software gets too many nested conditionals - you know the logic needs to be cleaned up or scrapped. Has anyone ever tried to apply complexity measures to portions of the law?
AFAIK, the only problem QCs are good at solving is factoring (and the discrete logarithm problem which is equivalent). Does anyone know a complete list of problems they are supposed to be good for? I don't think it's very long. OTOH, research may provide more over time.
ISPs are like toll roads, and now they want to charge more depending who you are. That isn't going to work. Fortunately there are other roads and ISPs.
BTW, I don't think X is bad either. Nor is it all that precious.
BTW, I'm really tired of seeing companies and products mentioned in Wikipedia. It's becoming another ad-rag.
You suggest that a larger sample or other similar studies would be more insiteful, but you know that more were likely conducted. Your's was published because the results were favorable to MS - some others were probably not. By agreeing to let MS decide if people see the results, you are skewing the results that the public sees. If you're not concerned about what the public sees, then put it in the contract that the results will not be made public regardless of the outcome.
You're only one sample in the "metastudy" that MS conducted. They show the data selectively because you agreed to let them do so. That's just piss-poor research.
I'm one of those guys (sometimes). I have a library that has undergone many small performance improvements and is now 2-3 times as fast as when it started. There's even one little run of inline assembler in the most critical part. The code has gone from fairly easy to understand C++ to much less easy to comprehend, so I'd agree that code optimization all the time is not a good thing - it's a tradeoff. People who think there is NO value in optimization annoy the crap out of me.
For some people, execution time is money.
4) People who actually run benchmarks
5) People who write lower level libraries
You may argue all day long because most people don't care about a 10 or even 50 percent performance difference. As long as the GUI responds in a time that approximates "instantly" people are generally happy.
Does this JAVA version of Q2 run so well on a Pentium?
Tell me when it's ready for production - i.e. when it's actually used in volume production. Flexible displays have been around forever as vaporware.
1) The Itanium
2) HT - Hyper threading - see recent articles about turning it off.
3) The P4 long pipeline used to inflate clock speed with lower performance/cycle
4) The new P4 core (preshot) - more watts, didn't come close to target of 5GHz.
5) Failure to commit to x86-64 resulting in lesser performance.
6) Late to the dual core party.
7) Continued use of the old buss making dual cores suck
8) Late to the integrated memory controller party (comming in like 2007).
9) Oh, and that whole Rambus thing.
If Intel had done what AMD did, and AMD did what Intel did, there would only be one left standing today. IMHO Intel has been living on it's brand name and huge production capacity for some time now.
He could just create a branch that is for regressions and bug fixes only. Then new features could just keep going into the tip. Look at GCC for example. If you look on kernel.org, there's nothing there but the last stable version and the current development version. Where does he think people are going to want to submit their patchs for new stuff? Duh.
Some things really should be considered from the start - which you seem to agree with. Others can probably wait, so I don't think you're totally out of line either. Reading of a book like this is probably a good way for people to make reasonable decisions as to which things really should be done up front. I just wish everyone would at least consider portability up front even if they don't plan to do it. Plans change.
When the numbers get large enough, is it practical to start writing these algorithms in Python? That would be really cool IMHO.
For a really interesting mess, I once saw a VB program that contained a conditional goto from the "then" portion of an "if" into the later half of the "else" portion. Yeah, I would have shot the guy if I didn't work for him at the time. OTOH, he knew just how bad it was - but it worked.
IANAL, but I don't think that happens by default. That's why companies have you sign something that makes it explicit.
I interpret this as good news. It means you should be free to modify stuff you bought to make it do your bidding regardless of what the copyright owner may want you to do with it. This would seem to include running DeCSS to make data usable - well if not for the DMCA. Actually, wouldn't the company in this case be guilty of circumventing the "locks" the programmer put in place? That'd be a DMCA violation wouldn't it?
Not enough details in the article about the "ownership" of the code or the charges brought against the company.
Some of the bugs reported in the story were not so much the fault of programmers, but of management. The phone network bug was a misplaced { character in a nested if-else construct. The code had already been though extensive testing, and then a small change was needed. Because it was a "minor" change someone said it didn't need to go through the extensive (expensive) testing again. It's always easy to point at the code or the guy who wrote it. Especially when the boss is the one tasked with finding out what went wrong.
These things don't look like they scale up very well. Wind power is all about swept area - or in this case profile area. To get more power you need more volume of air moving past. How does this type of design scale? Or is it limited to home use?
Exactly. Once the CPU can do everything the GPU can, why buy both? My reason for pointing out that a GPU wont run an OS is to make it obvious which of the 2 parts we will be buying, and which one we won't care about any more.
This is not happening."
Because a GPU is too hard to program for recursively refining nurbs or doing subdivision surfaces on the fly.
I'll pass on #2. I'm not sure what to say - future engines using mutiple cores effectively is somewhat speculative at this point. But lets say you win, so it takes another generation to catch the GPU.
"3. multicore CPUs are nearing the point where full screen, real time ray tracing will be possible. GPUs will not stand a chance."
This might be true, but so what? Ray tracing offers few advantages over the current-gen programmable pipeline."
Once it happens, the GPU will be a redundant component. In spite of all this "general purpose GPU" stuff people keep harping about, it still can't run an OS.
I keep remembering an ad about 15-20 years ago for an add-in card that would do hardware JPEG encoding. It cost over $1000 but was way faster than a PC could do it. The GPUs reign will end. I assure you I am not hallucinating.
Most of that stuff can be done with OpenGL/DirectX or ray tracing. Grasses are sometimes done in OpenGL with instancing small clumps. In RT you'd use proceedural geometry or instancing.
For the snow, both renderes would probably do similar techniques.
Sand dunes - either method needs an engine with deformable geometry - both can support that.
Water simulation is something I don't know much about. For the FFT methods of simulating waves it's possible that a GPU has an advantage. Once it start interacting with objects, I don't know how people handle that.
Your quesitons all point toward vast detailed worlds with lots of polygons. RT scales better with scene complexity. To get more traditional methods to work well, you get into fancy culling techniques (HZB comes to mind) and RT starts to look simpler - because it is.
Agreed. The current hardware limitation is power dissipation for both CPU and GPU. Hence multi-core from AMD and Intel.
Rendering a 1600x1200 4X AA scene with full filtering on a top tier dual core system would yield perhaps 1fps with an optimized software path.
Speculation. Besides, not many people run at that resolution with FSAA except GPU fanboys.
"You'll end up wanting a MMU" Nonsense.
I've already rendered a multi-millions polygon scene - requiring over 1GB of storage - at low (1-2fps) framerates on a 700MHz Athlon with only 128Meg RAM. MMU and swap was quite useful. I agree it's not a requirement to have scenes larger than main memory in most cases.
GPUs already do everything you need for raytracing. There are demos on the internet.
From the GPU ray tracing paper you point to: "Unfortunately, at the time of writing this, no current GLSL driver runs the ray tracer on GPUs without problems." In addition, they use a uniform grid for their acceleration structure because "there is minimal data access when traversing it". Grids are inferior for large scenes with small detailed objects (teapot in stadium problem). When you move on to real scense with real data structures the GPU will have more problems.
"Actually at that point it makes a lot of sense to move to raytracing " Nonsense. You're off by orders of magnitude.
Actually, thanks for making my case with the link. They used 20 AthlonXP 1800s, so it should run similarly with say 15 AMD64s or an 8 socket dual core box - available today but expensive. Their resolution was low (512x512), but the features of the renderer go beyond what you can do with a GPU.
Maybe they just haven't seen your fast code... *rolls eyes*
Here's my older code. The knight model is about 3000 triangles, so it demostrates the teapot-in-stadium problem (all other models are CSG quadrics). It was only meant as a sort of tech demo in 2001 and was entered in IGF. The RT library is at least 40 percent faster now - on scenes way bigger than a chess board. It's been extended to do photon mapping too (slow). rtChess is one of the only ray traced games out there, and it runs on a CPU not a GPU.
Real time ray tracing is probably not possible on todays CPUs, but in a few years it will be. At that point, why would anyone buy a CPU and a GPU? What OS and applications can you run on a GPU? Oh, they aren't really general purpose are they... *Rolls eyes*
In a few years, there will be no real benefit to the GPU. Not too many people write optimized assembly level graphics code anymore, but it can be quite fast. Recall that Quake ran on a Pentium 90MHz with software rendering. It's only getting better since then. A second core that most apps don't know how to take advantage of will make this all the more obvious.
On another note, as polygon counts skyrocket they approach single pixel size. When that happens, the hardware pixel shaders - that GPUs have so many of - become irrelevant as the majority of the work moves up to the vertex unit. Actually at that point it makes a lot of sense to move to raytracing (something I have fast code for) which is also going to be quite possible in a few more years on the main CPU(s). Ray Tracing is one application that really shows why the GPU is NOT general purpose. You need data structures and pointers mixed with fast math - preferably double precision. You need recursive algorithms. You'll end up wanting a MMU. By the time you're done, the GPU really would need to be general purpose. The problem doesn't map to a GPU at all, and multicore CPUs are nearing the point where full screen, real time ray tracing will be possible. GPUs will not stand a chance.