Speaking of runtime optimization... what ever happened to HP's Dynamo (I think that's what is was called). Run your executable, and it profiles it, and (supposedly) it runs them faster than before... wasn't that originally supposed to be a cross-platform tool (like FX!-32)?
There was an article at Ars Technica a while back... Haven't heard much lately, though. It would be interesting to see what other efforts there are for code profiling/optimization in the same vein... --
>There are only 3 fights per episode. So at the absolute best, there's only 9 minutes of stuff to watch. Yet you were in front of the TV for 30 minutes. Feel cheated yet?
That's why the good lord Sony gave us picture-in-picture. Think of how much time is wasted at football and baseball games - P-i-P is the answer... of course, with soccer, you might as well change the channel, since nothing ever happens. Soccer make cricket look exciting...
Runs fine on my 300a @ 450... do you have one w/o an L2 cache? The FP unit is the same one as the rest of the PPro -> P!!! line... granted, it's not an Alpha or POWER RISC, but hey, better than the 486;-)
they are doing the smart thing by staying out of it - it isn't their product, their attempt at IP, etc.. The noise over it probably gets some more people in there, who end up with a catalog, too... they don't have a reason to object.
Ah, but you can use it for a lot of other things... scan the barcodes on all of your CDs, books, and DVDs to create a database of what you own - there a bunch of sites and utils that let yo convert the barcode info into titles and such.
I went out trap shooting for the first time this year - a 12 gague Browning - hit about 3 of evey 5 of them. We shot at a local gun club range (I have a 'city' lot - they don't appreciate firearm discharge in the limits...). I think just about anybody could fire a shotgun, given the proper instruction - I got a few minutes of safety ideas, then a quick 'this is how you should stand and nest the butt end'. In fact, I think the geek/nerd community would be pretty good at it - it's all just point/click;-)
My C=64 - no way to get in - no services, no monitor, no drives, no power supply, no function. After I case it in cement and drop in into the abyss, it should be pretty safe indeed... --
Well, your POC comment isn't too far off - this is not release-level hardware. It took a couple tries with the SDR chipset to get things performing correctly 750->751->751b. Once everything gets worked out on this one, we should see a more consistent improvement.
#4 is also pretty accurate, and can be further alleviated with better memory access management (think RISC) and pipelining (aka, P4). We are only RAM limted in certain situations, for much of what we do, a great deal is held in the L2 cache, so the accesses to main store are far less frequent.
You could always go look at the timing diagrams, and figure that out for the best case. Of course, most people aren't that concerned with the real technology, and are just concerned about how soon they can get 200fps at 1600x1200x32b 8^)
Seriously, though, the x86 architecture (the bus structure most notably) isn't the best optimized for memory transfers, though the I/O is much worse (the whole x86 addressing scheme is due for a rewrite). </rant> Oh well, that's another topic for another day. --
"A 533 PIII gets a 126 sysmark rating. A 1 Ghz PIII gets a 194 rating, nearly twice as fast when thechip is nearly twice as fast! If modern processors are really waiting for RAM so much, why is processor speed a linear progression up the performance chart? It would be tailing off, with performance gains of a 1GHz PIII only marginally faster than a 700 or 800Mhz at the top of the chart."
Sysmark ratings use a small enough working set that the memory isn't overly taxed (L2 cache is a big help). For some things, raw integer or fp power overwhelms the memory speed, but in a lot of real world situations, that memory speed does hold you back. The more multi-tasking that you plan to do, larger working sets (for db apps, etc), and faster through-data that you work with (streaming, virus scans, etc) the more important the memory speed becomes... Most benchmarks are greatly aided by L2 cache (as well they should for proc benchmarks), and it would be nice to see some other numbers.
The 'stream' numbers would be interesting, to see if the memory/chipset can really deliver close to the rated throughput. Run the same tests with the L2 disabled (yes, yes, then it isn't a real world example, but it isn't anyway) for 'normal' and DDR SDRAM - it would be interesting, if not revealing. A nice kernel compile (which is assumed to be CPU-bound) might reveal some interesting things.
RAM speed may not make a difference to fast processors, but it makes a difference to a fast system... --
>woudln't it be nice for someone to throw together an MB with 2 AGP ports, perhaps one for an addon card?
Hmmm, that would require a new northbridge, and the total pinout for that package would raise the cost considerably... not to mention the design complexity involved. Kind of an expensive 'throw together'...
>but what about PC2100 (2*133) which is supposed to be available
From the article...
"The Tyan Trinity A762 motherboard we used sported 128MB of Micron PC1600 DDR SDRAM in one of its four slots. This matches up on bandwidth with the 1600MBps of the 200MHz FSB of the Athlon Thunderbird 1.1GHz we used for testing. You will likely need to have a 266MHz FSB Athlon Thunderbird or Duron in order to use DDR2100 memory with the AMD 760 chipset."
>I'm not talking about outgoing bandwidth!!!
I wasn't either...
...that was just sort of an extra thought I tacked on at the end, the rest of it wasn't directed in that fashion...
I agree with your points here, as I had said, my previous posts were coming from a viewpoint where everyone had fairly high bandwidth, especially considering the increasing availability of DSL/cable modems. I know there are a lot of lower bandwidth links out there, and from a time perspective, they spend megapercentages more connected to each httpd. If you can afford the hardware to throw at it for gzipping and large dynamic generation, that's fine. I've found that you fill a (even large) pipe faster than you run out of CPU time on a fairly powerful system (which agrees with your assesments more than mine). I was trying to provide a different viewpoint (since almost none of the people who use my site are on anything slower than 256k DSL, and it runs with a small amount of mem/CPU reserve). If you have a quad-xeon with a couple of gigs of memory, or an S80, then, by all means, go right ahead - it can and will save the slow people time. I haven't run anything to the scale that would need any of this (mostly since I have 80% static content), and my end-user demographic is much more bandwith-enabled than the typical cross-section.
>Please go and read some real quality information on people who have worked with these high end solutions before thinking about replying again.
Thanks for the kind comment... I have read the mod_perl guide... relax a little, will ya?
Yeah, but I'm biased 8^) I spent 4 years on the campus LAN (with a few T3s), cable modem in the last year, and I'll probably be switching to DSL soon... Bandwith spoiled... There are always tradeoffs, and yes, if you are going to be running with a slow endpoint, there can be savings, but I still think that the overhead of gzipping all the files (from memory to CPU time) outweighs another httpd that is waiting for the client (since it is now waiting for the gzip before it waits for the client). Of course, if your server is behind a slow pipe, and you have static pages, it will save a bundle.
I'll have to see if I can get one of those modules, and give something a shot with webbench.
>Of course, for high-text, heavy traffic sites (for example, right here on/.), this may make some sense.
Ah, but (like I mentioned in another comment) when you have a page that is say 500k of text (a hundred or so comments), dynamically generated for each hit, the overhead of compression is rather dangerous, and if a server is already somewhat near capacity, it could slow it dramatically... if you can't cache it, and have high traffic, it's a big problem.
[Insert your own joke about Jon Katz wasting even more time with compression] --
The CPU usage on the server scares a lot of people away from this - it's not a big deal for static content (zip once and cache), but for dynamic sites (say,/.) gzipping 5-700K of text each time would kill a loaded server pretty quickly... --
They *have* lost, they are just rolling for double or nothing... appeals courts are the craps tables for the compulsive gamblers of the lower courts... you *could* win this time, and get your wife's ring out of the pawn shop, or you could end up without the car, too...
They lost, but right now they are playing with a line of credit from the house... I'd like to be on the collection end when they lose again. --
Slashdot Mirror
Yes, but here INTL was a typo...
--
Heck, I thought Intel had the lead, they even released a processor you can't purchase... (1.13GHz)
--
Speaking of runtime optimization... what ever happened to HP's Dynamo (I think that's what is was called). Run your executable, and it profiles it, and (supposedly) it runs them faster than before... wasn't that originally supposed to be a cross-platform tool (like FX!-32)?
There was an article at Ars Technica a while back... Haven't heard much lately, though. It would be interesting to see what other efforts there are for code profiling/optimization in the same vein...
--
>There are only 3 fights per episode. So at the absolute best, there's only 9 minutes of stuff to watch. Yet you were in front of the TV for 30 minutes. Feel cheated yet?
That's why the good lord Sony gave us picture-in-picture. Think of how much time is wasted at football and baseball games - P-i-P is the answer... of course, with soccer, you might as well change the channel, since nothing ever happens. Soccer make cricket look exciting...
Pro wrestling... well, now that's just silly.
--
Runs fine on my 300a @ 450... do you have one w/o an L2 cache? The FP unit is the same one as the rest of the PPro -> P!!! line... granted, it's not an Alpha or POWER RISC, but hey, better than the 486 ;-)
--
they are doing the smart thing by staying out of it - it isn't their product, their attempt at IP, etc.. The noise over it probably gets some more people in there, who end up with a catalog, too... they don't have a reason to object.
--
Ah, but you can use it for a lot of other things... scan the barcodes on all of your CDs, books, and DVDs to create a database of what you own - there a bunch of sites and utils that let yo convert the barcode info into titles and such.
--
Yeah - if you could... stop reading Slashdot, and get some work done...... that'd be great.
Oh, and I'll need you to be here Saturday...
--
I went out trap shooting for the first time this year - a 12 gague Browning - hit about 3 of evey 5 of them. We shot at a local gun club range (I have a 'city' lot - they don't appreciate firearm discharge in the limits...). I think just about anybody could fire a shotgun, given the proper instruction - I got a few minutes of safety ideas, then a quick 'this is how you should stand and nest the butt end'. In fact, I think the geek/nerd community would be pretty good at it - it's all just point/click ;-)
--
My C=64 - no way to get in - no services, no monitor, no drives, no power supply, no function. After I case it in cement and drop in into the abyss, it should be pretty safe indeed...
--
Well, your POC comment isn't too far off - this is not release-level hardware. It took a couple tries with the SDR chipset to get things performing correctly 750->751->751b. Once everything gets worked out on this one, we should see a more consistent improvement.
#4 is also pretty accurate, and can be further alleviated with better memory access management (think RISC) and pipelining (aka, P4). We are only RAM limted in certain situations, for much of what we do, a great deal is held in the L2 cache, so the accesses to main store are far less frequent.
--
You could always go look at the timing diagrams, and figure that out for the best case. Of course, most people aren't that concerned with the real technology, and are just concerned about how soon they can get 200fps at 1600x1200x32b 8^)
Seriously, though, the x86 architecture (the bus structure most notably) isn't the best optimized for memory transfers, though the I/O is much worse (the whole x86 addressing scheme is due for a rewrite). </rant> Oh well, that's another topic for another day.
--
"A 533 PIII gets a 126 sysmark rating. A 1 Ghz PIII gets a 194 rating, nearly twice as fast when thechip is nearly twice as fast! If modern processors are really waiting for RAM so much, why is processor speed a linear progression up the performance chart? It would be tailing off, with performance gains of a 1GHz PIII only marginally faster than a 700 or 800Mhz at the top of the chart."
Sysmark ratings use a small enough working set that the memory isn't overly taxed (L2 cache is a big help). For some things, raw integer or fp power overwhelms the memory speed, but in a lot of real world situations, that memory speed does hold you back. The more multi-tasking that you plan to do, larger working sets (for db apps, etc), and faster through-data that you work with (streaming, virus scans, etc) the more important the memory speed becomes... Most benchmarks are greatly aided by L2 cache (as well they should for proc benchmarks), and it would be nice to see some other numbers.
The 'stream' numbers would be interesting, to see if the memory/chipset can really deliver close to the rated throughput. Run the same tests with the L2 disabled (yes, yes, then it isn't a real world example, but it isn't anyway) for 'normal' and DDR SDRAM - it would be interesting, if not revealing. A nice kernel compile (which is assumed to be CPU-bound) might reveal some interesting things.
RAM speed may not make a difference to fast processors, but it makes a difference to a fast system...
--
>and they sink every 24 hrs usually
Wet servers are never a good thing...
s/sink/sync/
--
>woudln't it be nice for someone to throw together an MB with 2 AGP ports, perhaps one for an addon card?
Hmmm, that would require a new northbridge, and the total pinout for that package would raise the cost considerably... not to mention the design complexity involved. Kind of an expensive 'throw together'...
--
doh! damn preview!
--
hmmm...._ know></a>Q:01010000100101001000010111101 01101010101001111111110101101010100101010010010001 00111 0111 1011010111110001110101?
_ know></a>A:01010100101010010010001011010 10101001111100001001010010000101100111010001011110 10110 1010 10100111110100001001010101101010100101010010010001 001110111.
<a href="http://nothing.nothing.com/why _oh_why_does_it_count_binary_as_caps/i_will_never
<a href="http://nothing.nothing.com/why _oh_why_does_it_count_binary_as_caps/i_will_never
--
>but what about PC2100 (2*133) which is supposed to be available
From the article...
"The Tyan Trinity A762 motherboard we used sported 128MB of Micron PC1600 DDR SDRAM in one of its four slots. This matches up on bandwidth with the 1600MBps of the 200MHz FSB of the Athlon Thunderbird 1.1GHz we used for testing. You will likely need to have a 266MHz FSB Athlon Thunderbird or Duron in order to use DDR2100 memory with the AMD 760 chipset."
--
>I'm not talking about outgoing bandwidth!!!
I wasn't either...
...that was just sort of an extra thought I tacked on at the end, the rest of it wasn't directed in that fashion...
I agree with your points here, as I had said, my previous posts were coming from a viewpoint where everyone had fairly high bandwidth, especially considering the increasing availability of DSL/cable modems. I know there are a lot of lower bandwidth links out there, and from a time perspective, they spend megapercentages more connected to each httpd. If you can afford the hardware to throw at it for gzipping and large dynamic generation, that's fine. I've found that you fill a (even large) pipe faster than you run out of CPU time on a fairly powerful system (which agrees with your assesments more than mine). I was trying to provide a different viewpoint (since almost none of the people who use my site are on anything slower than 256k DSL, and it runs with a small amount of mem/CPU reserve). If you have a quad-xeon with a couple of gigs of memory, or an S80, then, by all means, go right ahead - it can and will save the slow people time. I haven't run anything to the scale that would need any of this (mostly since I have 80% static content), and my end-user demographic is much more bandwith-enabled than the typical cross-section.
>Please go and read some real quality information on people who have worked with these high end solutions before thinking about replying again.
Thanks for the kind comment... I have read the mod_perl guide... relax a little, will ya?
--
Yeah, but I'm biased 8^) I spent 4 years on the campus LAN (with a few T3s), cable modem in the last year, and I'll probably be switching to DSL soon... Bandwith spoiled... There are always tradeoffs, and yes, if you are going to be running with a slow endpoint, there can be savings, but I still think that the overhead of gzipping all the files (from memory to CPU time) outweighs another httpd that is waiting for the client (since it is now waiting for the gzip before it waits for the client). Of course, if your server is behind a slow pipe, and you have static pages, it will save a bundle.
I'll have to see if I can get one of those modules, and give something a shot with webbench.
--
>Of course, for high-text, heavy traffic sites (for example, right here on /.), this may make some sense.
Ah, but (like I mentioned in another comment) when you have a page that is say 500k of text (a hundred or so comments), dynamically generated for each hit, the overhead of compression is rather dangerous, and if a server is already somewhat near capacity, it could slow it dramatically... if you can't cache it, and have high traffic, it's a big problem.
[Insert your own joke about Jon Katz wasting even more time with compression]
--
The CPU usage on the server scares a lot of people away from this - it's not a big deal for static content (zip once and cache), but for dynamic sites (say, /.) gzipping 5-700K of text each time would kill a loaded server pretty quickly...
--
They *have* lost, they are just rolling for double or nothing... appeals courts are the craps tables for the compulsive gamblers of the lower courts... you *could* win this time, and get your wife's ring out of the pawn shop, or you could end up without the car, too...
They lost, but right now they are playing with a line of credit from the house... I'd like to be on the collection end when they lose again.
--
Brian Boitano
He's Kicking Ass For Slashdot
Only in Winter
--
True (I did see that), but one should read the actual source material... the authors here have a increasing tendency to not read it themselves...
--