On Tue, 2003-12-16 at 13:15, Richard Ellis wrote: > On Tue, Dec 16, 2003 at 12:33:52AM -0700, Slepp Lukwai wrote: > >.. It's a dual Athlon, which inherently means 266FSB (DDR 266), > > though the memory is actually Hynix PC3200 w/ timings set as low as > > they go on this board (2-2-2), which gives me about 550MB/s memory > > bandwidth according to memtest, with a 13GB/s L1 and something like > > 6 or 8GB/s L2. The cache size is 256k/CPU, 64k L1. At 550MB/s, it > > SHOULD be able to push enough to keep the frames encoding at 100% > > CPU, in theory. > > Yes, but just one 720x480 DVD quality frame is larger than 256k in > size, so a 256k cache per CPU isn't helping too much overall > considering how many frames there are in a typical video to be > encoded. Plus, my experience with Athlon's is that they are actually > faster at mpeg2enc encoding that Intel chips of equivalent speed > ratings (the Athlon's 3dnow/mmx implimentation is faster) and so they > put a heavier stress on one's memory bandwidth than an equivalent > speed Intel chip would. It's possible that 275MB/s per CPU just > isn't fast enough to keep up with the rate that mpeg2enc can consume > data on an Athlon.
Yes, I expect the cache to only be able to fit the mpeg2enc code sections, not any of the data it uses. If the code keeps getting bumped out, then that's a problem. And 275MB/s may not be enough, true... It's too bad the Athlon dual chipset (AMD 768MPX) can't do above about 140 MHz bus speeds to see how much memory speed affects it. > Of course, Andrew would be much better suited to discuss mpeg2enc's > memory access patterns during encoding, which depending on how it > does go about accessing memory can better make use of the 256k of > cache, or cause the 256k of cache to be constantly thrashed in and > out. It could be interesting to use cachegrind on mpeg2enc and see what it declares for cache hit/miss, but I find cachegrind tends to make a 1 minute runtime hit 10 minutes, so I may not bother.. > > Now that's just silly. Why would you hurt the CPUs by running such bloat > > as Mozilla? I can't think of how many times Mozilla has gone nuts on me > > and used 100% CPU without reason, and you can't kill it any normal UI > > way.. Good ol' killall. However, I love it. It's a great browser. Just > > rather hungry at times. I suppose there's a reason the logo is a > > dinosaur. :> > > Hmm... Interesting. I've had it sometimes just stop but never go > nuts with 100% CPU, and although I usually do CLI kill it if need be, > FVWM2's "destroy" window command has never failed to get rid of it if > I don't bother to go CLI to do so. In fact, FVWM2's "destroy" has > never failed to get rid of anything that went wonky. It's the X > windows equivalent to a "kill -9" from the CLI. I've had it lock up and X becomes unresponsive since it's in a loop doing some expensive operation of some sort. It's strange. I don't see it nearly as often with the newer Mozillas as I did the old ones (in fact, haven't seen it in over a month). ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
