You apparently have not ever looked at the VOLUMES of information Intel publishes about optimizing for their processors. You think they'd rather have you write sub-optimal code so their CPUs look slower than they could look? Intel benefits when you write optimal code on their platforms.
HLE is emulating. As long as the final behavior is the same, you have a true emulator. What you seem to be describing is a simulator - something that works exactly like an N64 at the lowest levels... which just isn't possibly without MUCH faster hardware.
In order to keep track of what I had to do, I threw together a PHP HomeworkTracker that I used until I learned the patterns for each class (e.g. homeworks due Tuesday, next one out Thursday). The interface is crude, but it does support multiple users on the same server. Maybe someone can take this and improve on it.
Obviously some people will not remember to put their stuff into the tracker, but for me, that was not really a problem.
Just the first "if" block should be added to the "done" function.
Basically, it asks you if you wouldn't mind staying connected a bit longer to seed after you finsh downloading and haven't uploaded as much as you download. This would make it more clear to n00bs that staying connected helps everyone download faster. I'm not good enough with Python to add a "Do not ask me in the future" checkbox though:(
def done(self, event):
if ((35,142,35) != self.shareRatingText.GetForegroundColour()): #it is not green
result = wxMessageBox("You have not yet shared as much as you downloaded. Leaving the client running a bit longer will help the BitTorrent community as a whole. Quit anyway?", "Confirm quit", wxYES_NO, self.frame)
if (result == wxNO): #Don't want to quit. Get out of the quit function.
return
First, it reads the entire file to generate the SHA hashes of the file chunks so it can verify the file integrity.
I poked around the source a bit (I wrote a small patch which Bram didn't accept) and IIRC, the reason for the first 3 problems you have is the way he has it quits. First, the GUI disappears. Then, it talks to the tracker to say, "Bye Bye!". After that, it is supposed to quit for real. I think you can have quite a large delay saying goodbye to the tracker.
I have no idea WTF is with #4 - I've never heard of it.
The majority of the information in a torrent is SHA-1 hashes of the file chunks... using only printable characters would mean a huge filesize inflation. If you look at the format of a.torrent it really is very simple.
Actually, cas 2 is more than a few percent faster in applications that depend on latency. He ONLY used a bandwidth test - changing latencies OBVIOUSLY wouldn't have much effect there.
Had he used a program that accessed many little bits of data throughout RAM (such as a scientific simulation) he might have found that CAS latency had a much larger role.
I think he would have found more interesting results if he had chosen a different benchmark. The test he used only tested bandwidth, and latency was not a factor. However, most of the memory settings (other than clock speed) affect latency more than bandwidth. CAS is a major factor in latency. Had he used a benchmark that hit a few words at random memory locations rapidly, he would have seen the other effects of the settings he tweaked.
If you've heard the quote, "Never underestimate the bandwidth of a 747 full of DVDs" (updated for modern times), you can see that it is an example of why bandwidth is not the only important factor. On the benchmark he used, a 747 full of DVDs probably would have scored pretty well.
If you're going to play with latency settings, at least use a test that measures latency.
At work, before changes are made to test, it is sync'd from production, and then the changes are made, to be sure that we know EXACTLY what will happen when the changes are made to production, with the data that is used in production.
In any properly managed environment, developers don't get to [i]touch[/i] the production environment. If they do, it should be read-only. All changes are made in the dev environment (developers can do what they want), put into test (developers are seriously limited), and then finally into production. Prod should be a physically separate set of servers from dev & test.
If stuff breaks on Mondays, either someone is skipping steps, or there is more going on.
I didn't know that GPUs did that many operations per pass. Cool. Anyway, there are sets of operations that would be faster on the P4, which I'm too lazy to think about right now.;)
Re:The difference between a CPU and GPU
on
Future of 3d Graphics
·
· Score: 3, Insightful
Sorry to reply to myself, but a really simple example just occured to me.
Take your 486SX without a coprocessor... you can get an FPU (coprocessor) which does floating point operations MUCH faster than you can emulate them. However, you can't just use an FPU and ditch the 486, since the FPU can't do anything but floating point ops - it can't boot MS-DOS... it can't run Windows 3.1... it can't fetch values from memory... it can't even add 1+1 precisely!
The difference between a CPU and GPU
on
Future of 3d Graphics
·
· Score: 4, Informative
GPUs are highly specialized. In graphics processing, you generally perform the same set of operations over and over again. Also, pixels can be rendered concurrently - as such, graphics hardware can be extremely parallel in nature. Also, in graphics hardware, there isn't much (if any) branching in code. Simple shader code just runs through the same set of operations over and over again.
"Normal" code, such as a game engine, compiler, word processor or MP3/DivX encoder does all sorts of different operations, in a different order each time, many which are inherently serial in nature and don't scale well with parallel processing. This type of code is full of branches.
To optimize graphics processing, you can really just throw massively parallel hardware at it. Modern cards do what, 16 pixels/texels per cycle? 4+ pipelines for each stage all doing the EXACT same thing?
Regular code just isn't like that. Because different operations have to happen each time and in each program, you can't optimize the hardware for one specific thing. In serial applications, extra pipelines just go to waste. Also, frequent branch instructions mean that you have to worry about things like branch prediction (which takes up a fair amount of space). When you do have operations that can happen in parallel (such as make -j 4), the different pipelines are doing differnet things.
Take your GeForce GPU and P4 and see which can count to 2 billion faster. In a task like this, where both processors can probably do one add per cycle (no parallelizing in this code), the 2GHz P4 will take one second, and the 500MHz GeForce will take four seconds (assuming it can be programmed for a simple operation like "ADD"). Even if you throw in more instructions but the code cannot be parallelized, the CPU will probably win.
Basically, since you can't target one specific application, a general purpose processor will always be slower at some things - but can do a much wider range of things. Heck, up until recently, "GPUs" were dumb and couldn't be programmed by users at all. I haven't looked at what operations you can do now, but IIRC you are still limited to code with at most 2000 instructions or so.
Re:short term - new clients are too configurable
on
BitTorrent Guide
·
· Score: 1
Unfortunately, on 768/128 ADSL, leaving my upload uncapped results in crappy download speeds... so I have to limit uploads to ~5kB/s or lower for decent download performance. On the school lan, however, uploading doesn't cause any trouble.
However, it shouldn't be long before more anti-leech apps come out that slow you down if you don't share yourself.
Anyway, I wrote this because I was bored and wanted to see what a good price point was for current Athlons. If you examine the graphs carefully you might note that the XP's are not properly differentiated. Some are 333s and marked as that, others aren't marked properly, etc. With the new 400s, it gets worse. For the P4s, I got a little luckier because the speed ranges don't overlap as much. I think I'm going to not differnetiate between the various FSBs of Athlon XPs because the prices are close enough anyway.
Anyway, it has served its purpose by helping me find a point where the processors are reasonably fast, and the bang for the buck is decent.
gnuplot.script
#Copyright CTho9305 2003. You are given permission to redistribute this file provided this copyright notice is left intact. You may modify it as you want. Please share any modifications (you are not required to).set terminal png color set xlabel "Speed (MHz or rating)" set ylabel "Cost ($USD)" set title "Speed vs. Cost" set grid set time set linestyle 1 lw 3 plot "XP.dat" using 2:1 title "XP" with linespoints, \ "XP333.dat" using 2:1 title "XP333" with linespoints, \ "celeron.dat" using 2:1 title "celeron" with linespoints, \ "MP.dat" using 2:1 title "MP" with linespoints, \ "pentium4.dat" using 2:1 title "P4" with linespoints
Anyone know how to change the text font, or the thickness of the lines?
NTFS is a journalling file system... at least since Win2k. I think older versions were journalling FSes but I don't remember. Journalling in Longhorn is nothing new - the Yukon-based filesystem, however, is.
These boards are really cool (Stayton is used on the CMU TagBots). We (CMU Robotics Club) normally use a board designed by robotics club members to control robots, but they are based on 20MHz PICs, and don't have and wireless support (at least presently). When combined with the Intel board, however, the big processing can be done there, and the Cerebellum can just be used as a smart motor driver and sensor interface board.
This lets the robots run more complex code and communicate with each other wirelessly. Intel has provided CMU with enough boards for a LOT of cool projects.
Yes, this is unfortunately true, but sharing IS illegal - would you rather be a leech or risk having to pay thousands of dollars in fines to the **AA? Their scare tactics definitely work. Without a completely anonymous P2P system, sharing is a big risk.
At my university, they posted signs in all the dorms explaining how to turn off uploading in Kazaa, and put up a web page with a list of common P2P apps and how to disable sharing. This was mostly done to address an upstream bandwidth problem, but I would imagine it would have the result you want as well.
See, what you're missing is that when Intel says a chip is only stable at 2.4GHz, they mean that in an improperly cooled case in the Sahara in summer, with a weak power supply, it is stable at 2.4GHz (and should live as long as the warranty). With a proper cooling setup and good power, it may in fact be stable at 3GHz. Overclockers take advantage of these margins to get more for their money.
Slashdot Mirror
You apparently have not ever looked at the VOLUMES of information Intel publishes about optimizing for their processors. You think they'd rather have you write sub-optimal code so their CPUs look slower than they could look? Intel benefits when you write optimal code on their platforms.
HLE is emulating. As long as the final behavior is the same, you have a true emulator. What you seem to be describing is a simulator - something that works exactly like an N64 at the lowest levels... which just isn't possibly without MUCH faster hardware.
In order to keep track of what I had to do, I threw together a PHP HomeworkTracker that I used until I learned the patterns for each class (e.g. homeworks due Tuesday, next one out Thursday). The interface is crude, but it does support multiple users on the same server. Maybe someone can take this and improve on it.
Obviously some people will not remember to put their stuff into the tracker, but for me, that was not really a problem.
Just the first "if" block should be added to the "done" function.
:(
Basically, it asks you if you wouldn't mind staying connected a bit longer to seed after you finsh downloading and haven't uploaded as much as you download. This would make it more clear to n00bs that staying connected helps everyone download faster. I'm not good enough with Python to add a "Do not ask me in the future" checkbox though
def done(self, event):
if ((35,142,35) != self.shareRatingText.GetForegroundColour()): #it is not green
result = wxMessageBox("You have not yet shared as much as you downloaded. Leaving the client running a bit longer will help the BitTorrent community as a whole. Quit anyway?", "Confirm quit", wxYES_NO, self.frame)
if (result == wxNO): #Don't want to quit. Get out of the quit function.
return
First, it reads the entire file to generate the SHA hashes of the file chunks so it can verify the file integrity.
I poked around the source a bit (I wrote a small patch which Bram didn't accept) and IIRC, the reason for the first 3 problems you have is the way he has it quits. First, the GUI disappears. Then, it talks to the tracker to say, "Bye Bye!". After that, it is supposed to quit for real. I think you can have quite a large delay saying goodbye to the tracker.
I have no idea WTF is with #4 - I've never heard of it.
The majority of the information in a torrent is SHA-1 hashes of the file chunks... using only printable characters would mean a huge filesize inflation. If you look at the format of a .torrent it really is very simple.
The experimental client addresses a few of these issues.
Actually, cas 2 is more than a few percent faster in applications that depend on latency. He ONLY used a bandwidth test - changing latencies OBVIOUSLY wouldn't have much effect there.
Had he used a program that accessed many little bits of data throughout RAM (such as a scientific simulation) he might have found that CAS latency had a much larger role.
I think he would have found more interesting results if he had chosen a different benchmark. The test he used only tested bandwidth, and latency was not a factor. However, most of the memory settings (other than clock speed) affect latency more than bandwidth. CAS is a major factor in latency. Had he used a benchmark that hit a few words at random memory locations rapidly, he would have seen the other effects of the settings he tweaked.
If you've heard the quote, "Never underestimate the bandwidth of a 747 full of DVDs" (updated for modern times), you can see that it is an example of why bandwidth is not the only important factor. On the benchmark he used, a 747 full of DVDs probably would have scored pretty well.
If you're going to play with latency settings, at least use a test that measures latency.
LOL :) ;).
Fixed my sig. I don't live in the dorms over summer.... so I don't think checking back Tuesday will help much
At work, before changes are made to test, it is sync'd from production, and then the changes are made, to be sure that we know EXACTLY what will happen when the changes are made to production, with the data that is used in production.
In any properly managed environment, developers don't get to [i]touch[/i] the production environment. If they do, it should be read-only. All changes are made in the dev environment (developers can do what they want), put into test (developers are seriously limited), and then finally into production. Prod should be a physically separate set of servers from dev & test.
If stuff breaks on Mondays, either someone is skipping steps, or there is more going on.
I didn't know that GPUs did that many operations per pass. Cool. Anyway, there are sets of operations that would be faster on the P4, which I'm too lazy to think about right now. ;)
Sorry to reply to myself, but a really simple example just occured to me.
Take your 486SX without a coprocessor... you can get an FPU (coprocessor) which does floating point operations MUCH faster than you can emulate them. However, you can't just use an FPU and ditch the 486, since the FPU can't do anything but floating point ops - it can't boot MS-DOS... it can't run Windows 3.1... it can't fetch values from memory... it can't even add 1+1 precisely!
GPUs are highly specialized. In graphics processing, you generally perform the same set of operations over and over again. Also, pixels can be rendered concurrently - as such, graphics hardware can be extremely parallel in nature. Also, in graphics hardware, there isn't much (if any) branching in code. Simple shader code just runs through the same set of operations over and over again.
"Normal" code, such as a game engine, compiler, word processor or MP3/DivX encoder does all sorts of different operations, in a different order each time, many which are inherently serial in nature and don't scale well with parallel processing. This type of code is full of branches.
To optimize graphics processing, you can really just throw massively parallel hardware at it. Modern cards do what, 16 pixels/texels per cycle? 4+ pipelines for each stage all doing the EXACT same thing?
Regular code just isn't like that. Because different operations have to happen each time and in each program, you can't optimize the hardware for one specific thing. In serial applications, extra pipelines just go to waste. Also, frequent branch instructions mean that you have to worry about things like branch prediction (which takes up a fair amount of space). When you do have operations that can happen in parallel (such as make -j 4), the different pipelines are doing differnet things.
Take your GeForce GPU and P4 and see which can count to 2 billion faster. In a task like this, where both processors can probably do one add per cycle (no parallelizing in this code), the 2GHz P4 will take one second, and the 500MHz GeForce will take four seconds (assuming it can be programmed for a simple operation like "ADD"). Even if you throw in more instructions but the code cannot be parallelized, the CPU will probably win.
Basically, since you can't target one specific application, a general purpose processor will always be slower at some things - but can do a much wider range of things. Heck, up until recently, "GPUs" were dumb and couldn't be programmed by users at all. I haven't looked at what operations you can do now, but IIRC you are still limited to code with at most 2000 instructions or so.
Unfortunately, on 768/128 ADSL, leaving my upload uncapped results in crappy download speeds... so I have to limit uploads to ~5kB/s or lower for decent download performance. On the school lan, however, uploading doesn't cause any trouble.
However, it shouldn't be long before more anti-leech apps come out that slow you down if you don't share yourself.
No checksums? It uses SHA-1 to verify file integrity. That is pretty reliable!
Resuming with another p2p app? What apps let you do that anyway? When would you want to resume with another app?
Forced to upload? That is what makes downloads so fast. If everyone leeches, nobody gets good download speeds.
WARNING: You can see I write crappy perl / shell script. I make no guarantees about this code.
/' ABC cut -f1,3- -d ' ' ABC perl -pe 's/\[.*\]//' ABC perl -pe 's/\s+/ /' ABC grep -i xp ABC grep 333 ABC cut -f1,4 -d ' ' > XP333.dat /' ABC cut -f1,3- -d ' ' ABC perl -pe 's/\[.*\]//' ABC perl -pe 's/\s+/ /' ABC grep -i xp ABC grep -v 333 ABC cut -f1,4 -d ' ' > XP.dat /' ABC cut -f1,3- -d ' ' ABC perl -pe 's/\[.*\]//' ABC perl -pe 's/\s+/ /' ABC grep -i mp ABC perl -pe 's/\.//' ABC perl -pe 's/GHz/00/' ABC cut -f1,4 -d ' ' > MP.dat /' ABC cut -f1,3- -d ' ' ABC perl -pe 's/\[.*\]//' ABC perl -pe 's/\s+/ /' ABC grep -i celeron ABC cut -f 1,3 -d ' ' ABC perl -pe 's/ 1GHz/ 1.0GHz/;s/\.//;s/GHz/00/' > celeron.dat /' ABC cut -f1,3- -d ' ' ABC perl -pe 's/\[.*\]//;s/\s+/ /' ABC grep -i 'pentium 4' ABC egrep -i "sockABC2\.ABC3\." ABC grep -v -i 400MHz ABC perl -pe 's/ 533MHz//;s/GHz/00/;s/ Sock 478//;s/\.//' ABC cut -f1,4 -d ' ' ABC cut -b -8 > pentium4.dat
NOTE: replace all instances of "ABC" with "|".
parse.sh:
#!/bin/bash
#Copyright CTho9305 2003. You are given permission to redistribute this file provided this copyright notice is left intact. You may modify it as you want. Please share any modifications (you are not required to).
#barton
lynx -dump http://www.pricewatch.com/menus/m3.htm ABC egrep 'upABCdnABC - ' ABC cut -b5- ABC perl -pe 's/\s+/
#XP
lynx -dump http://www.pricewatch.com/menus/m3.htm ABC egrep 'upABCdnABC - ' ABC cut -b5- ABC perl -pe 's/\s+/
#Apparently I have too many junk characters
#MP
lynx -dump http://www.pricewatch.com/menus/m3.htm ABC egrep 'upABCdnABC - ' ABC cut -b5- ABC perl -pe 's/\s+/
# Celeron
lynx -dump http://www.pricewatch.com/menus/m3.htm ABC egrep 'upABCdnABC - ' ABC cut -b5- ABC perl -pe 's/\s+/
#P4
lynx -dump http://www.pricewatch.com/menus/m3.htm ABC egrep 'upABCdnABC - ' ABC cut -b5- ABC perl -pe 's/\s+/
gnuplot gnuplot.script > ~/www/out.png
Anyway, I wrote this because I was bored and wanted to see what a good price point was for current Athlons. If you examine the graphs carefully you might note that the XP's are not properly differentiated. Some are 333s and marked as that, others aren't marked properly, etc. With the new 400s, it gets worse. For the P4s, I got a little luckier because the speed ranges don't overlap as much. I think I'm going to not differnetiate between the various FSBs of Athlon XPs because the prices are close enough anyway.
Anyway, it has served its purpose by helping me find a point where the processors are reasonably fast, and the bang for the buck is decent.
gnuplot.script
#Copyright CTho9305 2003. You are given permission to redistribute this file provided this copyright notice is left intact. You may modify it as you want. Please share any modifications (you are not required to).set terminal png color
set xlabel "Speed (MHz or rating)"
set ylabel "Cost ($USD)"
set title "Speed vs. Cost"
set grid
set time
set linestyle 1 lw 3
plot "XP.dat" using 2:1 title "XP" with linespoints, \
"XP333.dat" using 2:1 title "XP333" with linespoints, \
"celeron.dat" using 2:1 title "celeron" with linespoints, \
"MP.dat" using 2:1 title "MP" with linespoints, \
"pentium4.dat" using 2:1 title "P4" with linespoints
Anyone know how to change the text font, or the thickness of the lines?
Sample output
Check this out... a laptop cooling pad.
NTFS is a journalling file system... at least since Win2k. I think older versions were journalling FSes but I don't remember. Journalling in Longhorn is nothing new - the Yukon-based filesystem, however, is.
I know. That is the problem. If you decided to route files through other hosts (to increase anonymity), the bandwidth usage would be absurd.
These boards are really cool (Stayton is used on the CMU TagBots). We (CMU Robotics Club) normally use a board designed by robotics club members to control robots, but they are based on 20MHz PICs, and don't have and wireless support (at least presently). When combined with the Intel board, however, the big processing can be done there, and the Cerebellum can just be used as a smart motor driver and sensor interface board.
This lets the robots run more complex code and communicate with each other wirelessly. Intel has provided CMU with enough boards for a LOT of cool projects.
Yes, this is unfortunately true, but sharing IS illegal - would you rather be a leech or risk having to pay thousands of dollars in fines to the **AA? Their scare tactics definitely work. Without a completely anonymous P2P system, sharing is a big risk.
At my university, they posted signs in all the dorms explaining how to turn off uploading in Kazaa, and put up a web page with a list of common P2P apps and how to disable sharing. This was mostly done to address an upstream bandwidth problem, but I would imagine it would have the result you want as well.
See, what you're missing is that when Intel says a chip is only stable at 2.4GHz, they mean that in an improperly cooled case in the Sahara in summer, with a weak power supply, it is stable at 2.4GHz (and should live as long as the warranty). With a proper cooling setup and good power, it may in fact be stable at 3GHz. Overclockers take advantage of these margins to get more for their money.