"Non-expandable"? Ha! Maybe until we get it home. How many Xboxes will have their warantees invalidated as new users buy them for $199 and hack them up? I suspect to see an article about one week after the initial rollout where somebody has hacked this, and reverse-engineered that and has Linux/FreeBSD/BEOS/Aethos running on the thing. Then everyone will run out and buy one and stick an extra 80-GB hard drive or two into it and hack video4linux into it. We will remake it in our own image and feel all the more smug about it.
It will happen. This community will co-opt *anything* and use it for our own purposes. Moreover, this treads in a technology domain that the community knows all too well. Once the nut is cracked, everyone will flock to buy up Xboxes/Homestations and use them for non-MS-endorsed purposes. Then we will all sit around and pat each other on the back and marvel at how great it is to be ruining Microsoft's profitability.
No matter what, MS will be "stupid" in our book.
So this is a bit cynical, but I think it is realistic. MS will profit by this. Our niche will hack something "better" from it. We will be self congratulatory and derisive. The great cycle of life continues on/.
If you remove limit cycle type series of moves where pieces just oscillate through repetitive states, then the chess is in fact a finite game. Now, the number of possible games is truly enormous and is effectively infinite as far as humans and current computers are concerned, but the same may not always be true. If one where so motivated and sufficiently funded, one could build a database of all possible chess games. But, it would be a very big database!
..is the enormous traffic generated by all of the/. folks hitting reload on the incidents.org website!
Re:Doesn't sound too hard...
on
ICFP 2001 Task
·
· Score: 1
First pass optimizations should be able to guard against stupidity. My first cut just clears out whitespace and trivial redundancies, like:
<B></B>This is not Bold<B></B>
or
<B><B>This was already Bold</B></B>
The first pass optimization will worst case include all of the original tags and should therefore pass the stupidity test. Of course, after this initial cleanup, then the real work has to start.
Re:Oh, OK. Sometimes I'm just really stupid.
on
ICFP 2001 Task
·
· Score: 1
I see what I'm missing. Color nesting makes it hard.
Hint: There are also EM/S nesting, size nesting, and underline nesting optimizations.
Local optimizations can be done on the fly as you initially indicated. The global optimization problems for nesting are algorithmically "hard." My guess is it is NP. The global optimization problem can be stated as a path minimization problem in a fairly large state space (naive size is 2x2x2x2x2x4x10x8) with ordered waypoints. The state space is actually a bit smaller than that.
Oh, and the state transition distances are different. A <B>,</B> pair costs 7 bytes, but a <PL>,</PL> pair costs 9. I bet that linear programming will choke on this problem too. There are a bunch of local minima. Time to dust off my Numerical Recipes book and read up on simulated annealing.
JMS said that "we" supernova it on purpose...something about opening jumppoints next to the surface of the sun and bleeding off material. The idea (I guess) is to reduce the mass of the sun and/or set up some sort of resonant behavior which trips off a supernova. At that point, humans and Minbari have reached "First One" status...or "Second One" status...I guess. That is what JMS said. You can find his comments on midwinter.com for that ep.
My personal guess is that the Rangers are tidying up. I think that they have learned first hand how very bad it is to allow advanced technology (Shadow tech, Vorlon tech, Telepathic ability, all of the crap Crusade was digging up) to fall into the hands of younger races. In Deconstruction, Earth and presumably the Sol system had been abandoned...humanity has "passed beyond the rim"...living in hyperspace or whatever the heck semi-deities do. I think that the Rangers came back to clean up...just to make sure that none of the advanced human tech lies around where younger races can find it. That is the lesson that humans and Minbari learned from the failure of the Shadows and Vorlons: Clean up after yourselves.
I thought about something similar. Perhaps it was brought up some months ago when HP started telling people about Dynamo. I was thinking how interesting it could be to apply this as a post-compilation optimization technique. There is every reason to believe that the same techniques can be used to analyze and improve native code performance too.
In fact, this could be an interesting kernel module development project. Allow the Linux kernel to optimize running executables on the fly. Create permanent entries in the filesystem to store optimized binaries and perhaps a running binary diff so that the optimizer could undo something if need be. If enough of the research is in the literature and someone in the audience is frantically searching for a PhD research project...
I am guessing at a real implementation. Otherwise, there are many other sources of "noise" that can be used to indirectly illuminate a source which are much better than cell towers. A large powerful transmitter (radio or TV station) will certainly light it up, but it also lights up everything else! Reflections and ground effects are the reason that we can receive signal over the horizon. If we had identifiable frequencies with associated station locations, it would greatly assist in noise rejection (think spread spectrum) as well as triangulation.
But, I haven't done any RF engineering for many years now...and I wasn't that good at it back then anyway.
You could encode a base station signature in a modulation of the radar frequency. Straight AM could easily and reliably encode at least thousands of signatures. Also, the modulation technique could be designed to not significantly reduce the average radiated power. Moreover, it might be good to frequency-hop to make it harder for the enemy to target and kill the base stations. Also, that would make it difficult for the enemy to use the system against you. The "listener" would need to know which stations were using which frequency and when in order to track anything.
I was impressed with the features of both, but the price is a little steep. I think that a straight MicroATX BookPC is a better deal. Unicomp has two nice BookPC cases for the similarly budget minded.
Now, I just have to bring myself to buy a PC Chips motherboard. Anyone have recommendations for a P3 or Athlon MicroATX motherboard with integrated Video, 100 Mbps, sound with working Xservers and Linux drivers?
My mention of war was because war is often the other great instigator of technology. The amount of technical development we've had from the two world wars alone is staggering, simply because the necessity arose.
I would argue that JFK's "goal" of reaching the moon was, in fact, motivated by war. The Cold War was in full swing in the early sixties. NASA was a logical extention of the DOD's missile development programs. The USSR's space program even moreso. When we shot a missile into space with a human aboard, we were demonstrating our technical acumen. We were demonstating that we can go faster, higher, farther...just like with the U2 spy planes. JFK's goal was as much to avoid a "Red Moon" as it was to land a man there.
This leads one to conclude that war (hot or cold) was the primary driving force in technology during that period. Now, we could probably argue that technological developments, while still progressing rapidly in military arenas, are now largely dominated by hardware/software improvements in the private sector. And these are brought about solely by the almighty buck.
That said, going to Mar...or even going back to the Moon, is not going to be a priority in the near future. We don't have to beat the "ruskies" there, and there is no profit in it. The only goal is to fulfill some Star Trek fantasies...and why bother, Hollywood does this for the greater mass of the population...$8 for a movie ticket, or $25 billion for a interplanetary mission?
NASA will continue to be a hard sell. I don't necessarily like the situation, but the conclusions are pretty inescapable.
Truthfully, if I opted for AMD, I would stay with the KT133a. I have not tested the SiS chipset, but stream numbers seem to correlate tightly with my application performance. The VIA and Ali Magik chipsets both have lower stream numbers than the 760. If the SiS stream numbers are higher, I might take another look. But the 760 only gave me about a 10% improvement over a KT133a with CAS3 SDRAM. I would probably go with the Asus KT133a board, four cheap sticks of ECC CAS2 256 DIMMs, and a 1.33. I would end up with about the same performance I got from DDR.
In other words, DDR is offically a "waste of money" in my book, until someone shows me otherwise. Right now, the P4/RDRAM combo is way out in front and I suspect that the 1.7 GHz chip will put it even further ahead for my application. I am going to be buying Intel and Rambus...even if it is against my will.
I can see your point about the ethical issues here, but I am spending my customers' money. I am obligated to put the best solution on their desk for the best price. There is no room for me to prop up substandard technology.
And the 10% increase that I mention is a measured quantity for my application. I ran the same benchmarks on a KT133a motherboard with PC133 and a AMD760 motherboard with DDR. The DDR system was about 10% faster. I could probably have seen the same increase by moving to CAS2 PC133 on the KT133a.
And where on Crucial's website may I find 512 MB ECC PC133 DDR SDRAM DIMMs?
Search, the web and tell me where I can buy 512 MB DDR SDRAM DIMMs for less than $600 to $700 each. The point is that I need 1 GB of RAM. The motherboard has two slots for DDR.
I know, I know. We all hate P4s. We all love Athlons. We all love DDR. We all hate RDRAM.
Well, I finally broke down and bought test equipment. A 1.5 P4, i850 motherboard, 640 MB RDRAM and 1.33 Athlon, AMD760 motherboard, 512 MB DDR SDRAM. I built them, installed Linux, installed the CFD software my customers use, and did some benchmarking.
The long and short is this: for this application, the P4 was the winner by a huge margin. The 1.5 P4 with RDRAM was over 60% faster than than 1.33 Althon/DDR rig.
So, this is important to me and to other scientific computing folks for a number of reasons:
P4 prices are in a freefall
I can put 1 GB of RDRAM on an i850 board with a 1.7 GHz for $1400 (CPU $400, RDRAM $800, MoBo $200)
The only DDR motherboards worth anything are based on the AMD chipset and they only have two DDR sockets. So, to get to 1 GB DDR, it costs about $600 each for two DDR DIMMs...$1200 just for RAM!
Even the "best" DDR implementation is only the slightest improvement over SDR. (about 10% in my tests)
So, I am sure that this will infuriate the lemmings who wander in to moderate. I have been waiting for the dual AMD setup with anticipation, but when it comes, it desparately needs decent DDR support. At least for my application, Intel and RDRAM are doing something very right.
So, RAMBUS sucks as a company. Intel isn't much better. For Unreal Tornament and Office Bench-O-Rama 2000, the Athlon might be the easy choice, but I think Intel has a viable platform in the i850 and they may well evolve it into an outstanding dual system. They have the kinks out of their RDRAM implementation. AMD and VIA should take note. Their DDR implementations are worthless.
Well, I am a scientist. I try to read papers without prejudice. I only know that looking over Ridder's paper pointed out an obvious defect in P2P query strategies, namely the need to broadcast queries. Without some intelligent routing protocol, there is no way to avoid this. We can try to fix this by throwing more bandwidth at the problem (via broadband and Reflector), but that really only moves the saturation level a bit higher.
Though I recognize the deficiency, I do not view it as unassailable, which seems to be Ridder's conclusion. In my paper, you will also see a reference to Clip2's analysis pointing to the same fundamental scaling problems with Gnutella. Like Clip2, I believe it is fixable. I simply offer a different approach then they are pursuing. And one that I believe would compliment ongoing P2P development efforts.
My point is that there is a problem with the query strategy, or the parallel algorithm, if you will permit me to borrow terminology from my area of expertise. It is unnecessary to impose such sizable bandwidth requirements on the network when the same query can be effectively processed with a more efficient algorithm. You don't buy a Origin2000 to allow you to run BubbleSort faster. You implement QuickSort and run in on your PC.
And, yes, I have read the specification. There is very little there that has anything to do with query acceleration at an algorithmic level. The lack of respect that you have shown me by flatly accusing me of ignorance without even bothering to examine my paper simply underscores the point I made earlier in this thread--the developers at work here are too caught up in religious zeoltry and clannishness to open their minds to new ideas and constructive criticism.
Should you bother to read my paper, you will see that I am not motivated by any political calling. I honestly don't have time to use Napster, Gnutella, or any of the rest. This is merely an interesting problem. My purpose is solely to add to the discussion and encourage the P2P development community to question some of the assumptions that they have made. Judge my ideas if you care to. My motivation is simply to see P2P technology advance and contribute if I am able.
...too many P2P implementors are either ignorant or disdainful of related work...
...there's still way too much fad-following in the P2P community and not enough solid science or engineering.
I have to concur. I know a little about networking, but mostly my experience is in high-performance computing. In parallel programming, avoiding unnecessary communication is a way of life. Once I looked at the P2P query problem, I hit upon an interesting approach to remove the broadcast requirement by using an approximate query routing scheme. This has the potential to fix P2P network scaling problems at a fundamental level. So I wrote up a paper outlining the approach. I politely sent off email to the Clip2, OpenP2P, etc. briefly explaining the idea, directing them to the paper, and asking for comments. I've got nothing. Now, maybe it is not much of an idea. I am an outsider in that community, but I really wonder if anyone bothered to read it.
In particular, everyone seems so focused on the "super-peer" concept with Reflector that they ignore underlying scaling problem that will still be there with super-peers. As a network becomes larger, it will not be able to tolerate broadcast queries...even with super-peers. Here is a nice explanation why.
In a fully P2P system, which would require a fixed port for incoming transactions, you can only have one participating machine behind the firewall.
I don't follow. Why would a fully P2P system require that the open port be fixed? Each system is going to have be enumerated on the network in some fashion...some other system(s) is(are) going to at least have to have your IP address. Why can't it also have a port number. From a firewall standpoint, each system behind the firewall could have its own forwarded port on the external interface.
Can't we spoof return packets (with the IP of the server that the other node is connected to) in order to create outgoing NAT entries and tunnel back through existing NATed routes on the other end? This probably breaks several RFCs, but it might still work.
But I think that raw UDP is probably a better solution. Ask a Gnutella user on a 56k modem how "reliable" TCP is.
This is not necessarily truth. Fully peer-to-peer networks *can* work in a scalable manner if we do a better job of searching. Query processing is the limiting issue for all truly P2P networks. I have been working on an idea to address this which involves query routing (instead of broadcasting) to reduce bandwidth requirements. Essentially, only nodes in the network which have a high probability of satisfying a query will recieve it.
Although gaming is important, I already have two Nvidia/NT systems that do a fine job. Right now, I want to build a Linux OpenGL (err...MESA) development system and plan to use XF86 4.0 and DRI to take advantage of windowed hardware acceleration. Can anyone recommend a solution here? I am seriously looking at the G400 or G450 from Matrox as their DRI drivers seem fairly mature. The only other option is a Voodoo5. I am willing to try either (though the dual head Matrox is really tempting). I would like some feedback from other people who have done more than run fullscreen gaming benchmarks. I am especially interested in windowed rendering performance and stability. The article mentions lockups with the Matrox card which, of course, is unacceptable. Any input is welcome.
Well, I have built two RAID servers for our computational modeling group. They used a dual celeron board, one Promise ATA66 controller, and four IBM 37.5 GB/Maxtor 40.0 GB drives. I used software RAID5 to get 112/120 GBs of redundant space. Of course, Samba and NFS for file serving. Including a nice UPS (software RAID dislikes power failures), the 112 GB system was a little over $2k.
If you build some simple brackets, you can probably use a second Promise controller and add four more drives. Plus, IBM is shipping 75 GB EIDE drives in the next few weeks. That would be 525 GB RAID5 with eight drives. Oh, I recommed that you NOT use the HPT controller on the Abit BP6. I had a lot of problems getting it to work reliably.
Finding representative input may be impossible for a randomly choosen application from Freshmeat, but those are not the applications that need the optimization.
They are concerned with SPEC...which contains lots of time consuming calculations buried in nested loops. Consider a less esoteric example that has a similar program structure. 3D software (Povray, Quake, whatever) goes through long lists of polygons. The instructions in these loops will be hit thousands or millions of times. These oft-touched bits of code will be optimized and have several fragments that correspond to the various common branching configurations. Any trip through these tight loops is going to be "representative." If the two or more branchings occur frequently, each will be encapsulated in a fragment. If the loop is exhaustive enough, every possible branching may be optimized. Amdahl's law is at work here. The parts of the entire code that get run the most are the locations for potential bottlenecks, and hence they attract the most attention from the optimizer. This is in direct contrast to a priori compiler optimization approaches which have a very narrow focus and have no idea how often a particular bit of code will be executed.
Again, the proof of the efficacy of this approach is in the HP results. Those results will only get better when you dump the runtime overhead. Furthermore, it is quite understandable that these types of optimizations will be orthogonal to those made by compile-type optimizations. The squeaky wheels will get the oil. And, there is NO possibility of a performance penalty. If the "optimized" fragments are slower than original code, they can be discarded. And these optimization will be resilent to parametric changes, otherwise the HP software wouldn't be seeing any speedup. It has to have a cache of pre-ordered instruction blocks that is hit many times in order for the initial optimization/translation time to be amortized.
There is a lot of potential here I think, especially for computational physics codes that I work on.
Slashdot Mirror
"Non-expandable"? Ha! Maybe until we get it home. How many Xboxes will have their warantees invalidated as new users buy them for $199 and hack them up? I suspect to see an article about one week after the initial rollout where somebody has hacked this, and reverse-engineered that and has Linux/FreeBSD/BEOS/Aethos running on the thing. Then everyone will run out and buy one and stick an extra 80-GB hard drive or two into it and hack video4linux into it. We will remake it in our own image and feel all the more smug about it.
/.
It will happen. This community will co-opt *anything* and use it for our own purposes. Moreover, this treads in a technology domain that the community knows all too well. Once the nut is cracked, everyone will flock to buy up Xboxes/Homestations and use them for non-MS-endorsed purposes. Then we will all sit around and pat each other on the back and marvel at how great it is to be ruining Microsoft's profitability.
No matter what, MS will be "stupid" in our book.
So this is a bit cynical, but I think it is realistic. MS will profit by this. Our niche will hack something "better" from it. We will be self congratulatory and derisive. The great cycle of life continues on
Sure glad it's Friday.
If you remove limit cycle type series of moves where pieces just oscillate through repetitive states, then the chess is in fact a finite game. Now, the number of possible games is truly enormous and is effectively infinite as far as humans and current computers are concerned, but the same may not always be true. If one where so motivated and sufficiently funded, one could build a database of all possible chess games. But, it would be a very big database!
..is the enormous traffic generated by all of the /. folks hitting reload on the incidents.org website!
First pass optimizations should be able to guard against stupidity. My first cut just clears out whitespace and trivial redundancies, like:
<B></B>This is not Bold<B></B>
or
<B><B>This was already Bold</B></B>
The first pass optimization will worst case include all of the original tags and should therefore pass the stupidity test. Of course, after this initial cleanup, then the real work has to start.
I see what I'm missing. Color nesting makes it hard.
Hint: There are also EM/S nesting, size nesting, and underline nesting optimizations.
Local optimizations can be done on the fly as you initially indicated. The global optimization problems for nesting are algorithmically "hard." My guess is it is NP. The global optimization problem can be stated as a path minimization problem in a fairly large state space (naive size is 2x2x2x2x2x4x10x8) with ordered waypoints. The state space is actually a bit smaller than that.
Oh, and the state transition distances are different. A <B>,</B> pair costs 7 bytes, but a <PL>,</PL> pair costs 9. I bet that linear programming will choke on this problem too. There are a bunch of local minima. Time to dust off my Numerical Recipes book and read up on simulated annealing.
Of course, what do I know?
JMS said that "we" supernova it on purpose...something about opening jumppoints next to the surface of the sun and bleeding off material. The idea (I guess) is to reduce the mass of the sun and/or set up some sort of resonant behavior which trips off a supernova. At that point, humans and Minbari have reached "First One" status...or "Second One" status...I guess. That is what JMS said. You can find his comments on midwinter.com for that ep.
My personal guess is that the Rangers are tidying up. I think that they have learned first hand how very bad it is to allow advanced technology (Shadow tech, Vorlon tech, Telepathic ability, all of the crap Crusade was digging up) to fall into the hands of younger races. In Deconstruction, Earth and presumably the Sol system had been abandoned...humanity has "passed beyond the rim"...living in hyperspace or whatever the heck semi-deities do. I think that the Rangers came back to clean up...just to make sure that none of the advanced human tech lies around where younger races can find it. That is the lesson that humans and Minbari learned from the failure of the Shadows and Vorlons: Clean up after yourselves.
I thought about something similar. Perhaps it was brought up some months ago when HP started telling people about Dynamo. I was thinking how interesting it could be to apply this as a post-compilation optimization technique. There is every reason to believe that the same techniques can be used to analyze and improve native code performance too.
In fact, this could be an interesting kernel module development project. Allow the Linux kernel to optimize running executables on the fly. Create permanent entries in the filesystem to store optimized binaries and perhaps a running binary diff so that the optimizer could undo something if need be. If enough of the research is in the literature and someone in the audience is frantically searching for a PhD research project...
I am guessing at a real implementation. Otherwise, there are many other sources of "noise" that can be used to indirectly illuminate a source which are much better than cell towers. A large powerful transmitter (radio or TV station) will certainly light it up, but it also lights up everything else! Reflections and ground effects are the reason that we can receive signal over the horizon. If we had identifiable frequencies with associated station locations, it would greatly assist in noise rejection (think spread spectrum) as well as triangulation.
But, I haven't done any RF engineering for many years now...and I wasn't that good at it back then anyway.
You could encode a base station signature in a modulation of the radar frequency. Straight AM could easily and reliably encode at least thousands of signatures. Also, the modulation technique could be designed to not significantly reduce the average radiated power. Moreover, it might be good to frequency-hop to make it harder for the enemy to target and kill the base stations. Also, that would make it difficult for the enemy to use the system against you. The "listener" would need to know which stations were using which frequency and when in order to track anything.
Of course, what do I know?
I just found this last Friday. They also have the "espresso" pocket PC which may or may not have been on /. previously. It is even smaller!
y ID=25&SubCatagoryID=135
y ID=2&SubCatagoryID=244
http://www.unicomplabs.com/parts/main.asp?Catagor
I was impressed with the features of both, but the price is a little steep. I think that a straight MicroATX BookPC is a better deal. Unicomp has two nice BookPC cases for the similarly budget minded.
http://www.unicomplabs.com/parts/main.asp?Catagor
Now, I just have to bring myself to buy a PC Chips motherboard. Anyone have recommendations for a P3 or Athlon MicroATX motherboard with integrated Video, 100 Mbps, sound with working Xservers and Linux drivers?
My mention of war was because war is often the other great instigator of technology. The amount of technical development we've had from the two world wars alone is staggering, simply because the necessity arose.
I would argue that JFK's "goal" of reaching the moon was, in fact, motivated by war. The Cold War was in full swing in the early sixties. NASA was a logical extention of the DOD's missile development programs. The USSR's space program even moreso. When we shot a missile into space with a human aboard, we were demonstrating our technical acumen. We were demonstating that we can go faster, higher, farther...just like with the U2 spy planes. JFK's goal was as much to avoid a "Red Moon" as it was to land a man there.
This leads one to conclude that war (hot or cold) was the primary driving force in technology during that period. Now, we could probably argue that technological developments, while still progressing rapidly in military arenas, are now largely dominated by hardware/software improvements in the private sector. And these are brought about solely by the almighty buck.
That said, going to Mar...or even going back to the Moon, is not going to be a priority in the near future. We don't have to beat the "ruskies" there, and there is no profit in it. The only goal is to fulfill some Star Trek fantasies...and why bother, Hollywood does this for the greater mass of the population...$8 for a movie ticket, or $25 billion for a interplanetary mission?
NASA will continue to be a hard sell. I don't necessarily like the situation, but the conclusions are pretty inescapable.
Truthfully, if I opted for AMD, I would stay with the KT133a. I have not tested the SiS chipset, but stream numbers seem to correlate tightly with my application performance. The VIA and Ali Magik chipsets both have lower stream numbers than the 760. If the SiS stream numbers are higher, I might take another look. But the 760 only gave me about a 10% improvement over a KT133a with CAS3 SDRAM. I would probably go with the Asus KT133a board, four cheap sticks of ECC CAS2 256 DIMMs, and a 1.33. I would end up with about the same performance I got from DDR.
In other words, DDR is offically a "waste of money" in my book, until someone shows me otherwise. Right now, the P4/RDRAM combo is way out in front and I suspect that the 1.7 GHz chip will put it even further ahead for my application. I am going to be buying Intel and Rambus...even if it is against my will.
I can see your point about the ethical issues here, but I am spending my customers' money. I am obligated to put the best solution on their desk for the best price. There is no room for me to prop up substandard technology.
And the 10% increase that I mention is a measured quantity for my application. I ran the same benchmarks on a KT133a motherboard with PC133 and a AMD760 motherboard with DDR. The DDR system was about 10% faster. I could probably have seen the same increase by moving to CAS2 PC133 on the KT133a.
And where on Crucial's website may I find 512 MB ECC PC133 DDR SDRAM DIMMs?
Search, the web and tell me where I can buy 512 MB DDR SDRAM DIMMs for less than $600 to $700 each. The point is that I need 1 GB of RAM. The motherboard has two slots for DDR.
Read...think...then respond.
From Pricewatch: DDR 512
I really need ECC which is even more expensive. There is always grossly nonlinear cost behavior at the high density end of the RAM market.
Well, I finally broke down and bought test equipment. A 1.5 P4, i850 motherboard, 640 MB RDRAM and 1.33 Athlon, AMD760 motherboard, 512 MB DDR SDRAM. I built them, installed Linux, installed the CFD software my customers use, and did some benchmarking.
The long and short is this: for this application, the P4 was the winner by a huge margin. The 1.5 P4 with RDRAM was over 60% faster than than 1.33 Althon/DDR rig.
So, this is important to me and to other scientific computing folks for a number of reasons:
- P4 prices are in a freefall
- I can put 1 GB of RDRAM on an i850 board with a 1.7 GHz for $1400 (CPU $400, RDRAM $800, MoBo $200)
- The only DDR motherboards worth anything are based on the AMD chipset and they only have two DDR sockets. So, to get to 1 GB DDR, it costs about $600 each for two DDR DIMMs...$1200 just for RAM!
- Even the "best" DDR implementation is only the slightest improvement over SDR. (about 10% in my tests)
So, I am sure that this will infuriate the lemmings who wander in to moderate. I have been waiting for the dual AMD setup with anticipation, but when it comes, it desparately needs decent DDR support. At least for my application, Intel and RDRAM are doing something very right.So, RAMBUS sucks as a company. Intel isn't much better. For Unreal Tornament and Office Bench-O-Rama 2000, the Athlon might be the easy choice, but I think Intel has a viable platform in the i850 and they may well evolve it into an outstanding dual system. They have the kinks out of their RDRAM implementation. AMD and VIA should take note. Their DDR implementations are worthless.
I didn't. Where is it?
Well, I am a scientist. I try to read papers without prejudice. I only know that looking over Ridder's paper pointed out an obvious defect in P2P query strategies, namely the need to broadcast queries. Without some intelligent routing protocol, there is no way to avoid this. We can try to fix this by throwing more bandwidth at the problem (via broadband and Reflector), but that really only moves the saturation level a bit higher.
Though I recognize the deficiency, I do not view it as unassailable, which seems to be Ridder's conclusion. In my paper, you will also see a reference to Clip2's analysis pointing to the same fundamental scaling problems with Gnutella. Like Clip2, I believe it is fixable. I simply offer a different approach then they are pursuing. And one that I believe would compliment ongoing P2P development efforts.
My point is that there is a problem with the query strategy, or the parallel algorithm, if you will permit me to borrow terminology from my area of expertise. It is unnecessary to impose such sizable bandwidth requirements on the network when the same query can be effectively processed with a more efficient algorithm. You don't buy a Origin2000 to allow you to run BubbleSort faster. You implement QuickSort and run in on your PC.
And, yes, I have read the specification. There is very little there that has anything to do with query acceleration at an algorithmic level. The lack of respect that you have shown me by flatly accusing me of ignorance without even bothering to examine my paper simply underscores the point I made earlier in this thread--the developers at work here are too caught up in religious zeoltry and clannishness to open their minds to new ideas and constructive criticism.
Should you bother to read my paper, you will see that I am not motivated by any political calling. I honestly don't have time to use Napster, Gnutella, or any of the rest. This is merely an interesting problem. My purpose is solely to add to the discussion and encourage the P2P development community to question some of the assumptions that they have made. Judge my ideas if you care to. My motivation is simply to see P2P technology advance and contribute if I am able.
I have to concur. I know a little about networking, but mostly my experience is in high-performance computing. In parallel programming, avoiding unnecessary communication is a way of life. Once I looked at the P2P query problem, I hit upon an interesting approach to remove the broadcast requirement by using an approximate query routing scheme. This has the potential to fix P2P network scaling problems at a fundamental level. So I wrote up a paper outlining the approach. I politely sent off email to the Clip2, OpenP2P, etc. briefly explaining the idea, directing them to the paper, and asking for comments. I've got nothing. Now, maybe it is not much of an idea. I am an outsider in that community, but I really wonder if anyone bothered to read it.
In particular, everyone seems so focused on the "super-peer" concept with Reflector that they ignore underlying scaling problem that will still be there with super-peers. As a network becomes larger, it will not be able to tolerate broadcast queries...even with super-peers. Here is a nice explanation why.
In a fully P2P system, which would require a fixed port for incoming transactions, you can only have one participating machine behind the firewall.
I don't follow. Why would a fully P2P system require that the open port be fixed? Each system is going to have be enumerated on the network in some fashion...some other system(s) is(are) going to at least have to have your IP address. Why can't it also have a port number. From a firewall standpoint, each system behind the firewall could have its own forwarded port on the external interface.
Can't we spoof return packets (with the IP of the server that the other node is connected to) in order to create outgoing NAT entries and tunnel back through existing NATed routes on the other end? This probably breaks several RFCs, but it might still work.
But I think that raw UDP is probably a better solution. Ask a Gnutella user on a 56k modem how "reliable" TCP is.
This is not necessarily truth. Fully peer-to-peer networks *can* work in a scalable manner if we do a better job of searching. Query processing is the limiting issue for all truly P2P networks. I have been working on an idea to address this which involves query routing (instead of broadcasting) to reduce bandwidth requirements. Essentially, only nodes in the network which have a high probability of satisfying a query will recieve it.
Full details are in a draft paper here. I welcome comments.
Although gaming is important, I already have two Nvidia/NT systems that do a fine job. Right now, I want to build a Linux OpenGL (err...MESA) development system and plan to use XF86 4.0 and DRI to take advantage of windowed hardware acceleration. Can anyone recommend a solution here? I am seriously looking at the G400 or G450 from Matrox as their DRI drivers seem fairly mature. The only other option is a Voodoo5. I am willing to try either (though the dual head Matrox is really tempting). I would like some feedback from other people who have done more than run fullscreen gaming benchmarks. I am especially interested in windowed rendering performance and stability. The article mentions lockups with the Matrox card which, of course, is unacceptable. Any input is welcome.
Thanks.
Well, I have built two RAID servers for our computational modeling group. They used a dual celeron board, one Promise ATA66 controller, and four IBM 37.5 GB/Maxtor 40.0 GB drives. I used software RAID5 to get 112/120 GBs of redundant space. Of course, Samba and NFS for file serving. Including a nice UPS (software RAID dislikes power failures), the 112 GB system was a little over $2k.
If you build some simple brackets, you can probably use a second Promise controller and add four more drives. Plus, IBM is shipping 75 GB EIDE drives in the next few weeks. That would be 525 GB RAID5 with eight drives. Oh, I recommed that you NOT use the HPT controller on the Abit BP6. I had a lot of problems getting it to work reliably.
Finding representative input may be impossible for a randomly choosen application from Freshmeat, but those are not the applications that need the optimization.
They are concerned with SPEC...which contains lots of time consuming calculations buried in nested loops. Consider a less esoteric example that has a similar program structure. 3D software (Povray, Quake, whatever) goes through long lists of polygons. The instructions in these loops will be hit thousands or millions of times. These oft-touched bits of code will be optimized and have several fragments that correspond to the various common branching configurations. Any trip through these tight loops is going to be "representative." If the two or more branchings occur frequently, each will be encapsulated in a fragment. If the loop is exhaustive enough, every possible branching may be optimized. Amdahl's law is at work here. The parts of the entire code that get run the most are the locations for potential bottlenecks, and hence they attract the most attention from the optimizer. This is in direct contrast to a priori compiler optimization approaches which have a very narrow focus and have no idea how often a particular bit of code will be executed.
Again, the proof of the efficacy of this approach is in the HP results. Those results will only get better when you dump the runtime overhead. Furthermore, it is quite understandable that these types of optimizations will be orthogonal to those made by compile-type optimizations. The squeaky wheels will get the oil. And, there is NO possibility of a performance penalty. If the "optimized" fragments are slower than original code, they can be discarded. And these optimization will be resilent to parametric changes, otherwise the HP software wouldn't be seeing any speedup. It has to have a cache of pre-ordered instruction blocks that is hit many times in order for the initial optimization/translation time to be amortized.
There is a lot of potential here I think, especially for computational physics codes that I work on.