NotebookForums.com › Forums › General Notebook Discussions › Notebook Forums - General › Gaming: Turion 64 vs Pentium M
New Posts  All Forums:Forum Nav:

Gaming: Turion 64 vs Pentium M - Page 3

post #41 of 65
Come on people this is getting ridiculous. Each processor will have it's pros/cons so some people will claim their Turion is the best thing ever and some will claim that the P-M is the number one chip. Honestly who cares? Just as long as everyone likes what they get and is happy. I could care less if a Turion owner gets 5 more FPS than me in Doom III, and I'm sure he doesn't care if I can encode video 30 seconds faster. There is no need to get into a "my dick is bigger than yours" fight on the internet.

On the notebookforums Counter Strike server there really needs to be an AMD v Intel game one of these games so we can just have fun instead of relying on bogus benchmarks and people's opinions.
post #42 of 65
Quote:
Originally Posted by Aurorix
Increased address space isn't the only thing that 64-bit brings to the table; remember, with the new 64-bit programming model comes 8 extra GPRs and 8 extra SIMD registers. This alone has the potential to contribute a noticable performance boost to many applications compiled 64-bit native, though mileage will obviously vary from app to app.
You are referring to the difference between K7 and K8, which does not necessarily have anything to do with 64-bit. AMD can make a 64-bit CPU with the same number of registers as K7 if they wanted to, but that certainly won't bring the same level of performance that K8 brings now.

K8 is a much better architecture, regardless whether it's a 64-bit or 32, just look at the difference between the Socket A and S754 Semprons, it's night and day. And with the Sempron 3400 due out soon, we will even see more of it.
post #43 of 65
Thread Starter 
Quote:
Originally Posted by Wiz33
In the case of gaming on a laptop. the CPU should be the last thing on the list. Pay more attention to the kind of GPU you can get with the size, weight and battery performance that you want. Even back when I have my Aspire 2025 with a 1.8G P-M and 128MB or MR9700. I have never seen it run at 100% during gaming as I run out of GPU power way before then
you are right about gaming... but one of the reasons I started this thread is because I run Gentoo Linux on all my systems and it would be great if I can take advantage of it while compiling my OS and applications for 64 bit.
Don't get me wrong at this time the XPS Gen2 kicks ass I would love to order it if prices go down because I belive that the price is good if it had a good screen.
post #44 of 65
Quote:
Originally Posted by HardBall
You are referring to the difference between K7 and K8, which does not necessarily have anything to do with 64-bit. AMD can make a 64-bit CPU with the same number of registers as K7 if they wanted to, but that certainly won't bring the same level of performance that K8 brings now.


This has EVERYTHING to do with 64-bit. With x86-64/EM64T comes a new programming model, with the extra GPRs and SIMD registers I mentioned. The poster above questioned whether 64-bit applications will have a performance benefit over 32-bit applications. You responded with "64-bit systems won't outperform the 32-bit ones by a single nano-second by itself", which, in fact, is not true; there is a potential performance increase when you compile 64-bit native. Nobody is arguing that AMD couldn't have built an 8 GPR 64-bit CPU had they wanted to; but they didn't, so it's irrelevant. We're talking about the benefits of using 64-bit applications over 32-bit applications. One of those benefits happens to be that there are twice as many programmer accessible registers available when running 64-bit.
post #45 of 65
Quote:
Originally Posted by Aurorix


This has EVERYTHING to do with 64-bit. With x86-64/EM64T comes a new programming model, with the extra GPRs and SIMD registers I mentioned. The poster above questioned whether 64-bit applications will have a performance benefit over 32-bit applications. You responded with "64-bit systems won't outperform the 32-bit ones by a single nano-second by itself", which, in fact, is not true; there is a potential performance increase when you compile 64-bit native. Nobody is arguing that AMD couldn't have built an 8 GPR 64-bit CPU had they wanted to; but they didn't, so it's irrelevant. We're talking about the benefits of using 64-bit applications over 32-bit applications. One of those benefits happens to be that there are twice as many programmer accessible registers available when running 64-bit.
That's what I have been saying all along.

64-bit CPU by itself, does squat, but the developers need to use the huge advantage that it affords in computation, especially of floats, and large data set manipulation in terms of the amount of virtual memory available for a single application.. It is not necessary to have 16 registers to be 64-bit, nor would a 32-bit processor necessarily be limited to using 8 registers.
post #46 of 65
FYI

Pentium M 64K L1 Cache / 2048KB L2 Cache
Turion 128K L1 Cache / 512KB or 1024KB L2 Cache
post #47 of 65
Quote:
Originally Posted by Aurorix


This has EVERYTHING to do with 64-bit. With x86-64/EM64T comes a new programming model, with the extra GPRs and SIMD registers I mentioned. The poster above questioned whether 64-bit applications will have a performance benefit over 32-bit applications. You responded with "64-bit systems won't outperform the 32-bit ones by a single nano-second by itself", which, in fact, is not true; there is a potential performance increase when you compile 64-bit native. Nobody is arguing that AMD couldn't have built an 8 GPR 64-bit CPU had they wanted to; but they didn't, so it's irrelevant. We're talking about the benefits of using 64-bit applications over 32-bit applications. One of those benefits happens to be that there are twice as many programmer accessible registers available when running 64-bit.
programs don't just magically compile themselves to take advantage of the 64-bit registers, the developer has to code it for them to use that advantage.
post #48 of 65
8-way server would refer to a server with 8 processors.

I never challenged the technological benefit of 32bit vs 64bit architecture especially coming from a Digital Alpha background. My statement was in relationship to the topic of this thread. The thread is comparing the Turion vs Pent-M for gaming.

Are you saying that a 64bit proc will outperform a 32bit proc on any game available or any game in development? If you're answer is no then there is not reason to look at the benefit of the Turion being a 64bit proc in relationship to gaming performance.
post #49 of 65
Quote:
Originally Posted by HardBall
programs don't just magically compile themselves to take advantage of the 64-bit registers, the developer has to code it for them to use that advantage.
I'm not sure what you mean here. Do you mean take advantage of the 64-bit programming model (i.e. extra available GPRs), or take advantage of the increased width of the 64-bit registers?
post #50 of 65
The extra width of the 64 bit GPRs and the additional extended XMM registers (SSE) do no good, unless the software is written to run under the 64-bit long mode (as opposed to compatibility mode, which makes no use of the 64 bit advantage at all).

But otherwise, A64s are excellent 32-bit proc because of superior architecture not necessarily related to 64-bit registers.
post #51 of 65
Looking at the GamePC review, I'm seeing a difference of 1-2 frames in most games between the Dothan 2.0 GHz and the Athlon 64 3500+ (keep in mind that the NT-34 is probably a 3400+ and has a TDP of 25w and that the NL-37 is probably a 3700+ with a TDP of 35w.)

Now, looking at the TechReport one?

The Pentium M 2.0 GHz loses to the 3200+ in the Doom 3 test, and not by a particularly small margin. Same goes for the Far Cry test, with the margin being even more embarassingly in the A64's favour. Ditto for Unreal Tournament 2004, although the FRAPs results show that the 3200+ loses to the Pentium M by...0.5 FPS when it comes to the lowest framerate measured. Big loss (35.0 VS 34.5.) It did win in the Software Renderer test (UT2004), however, beating out even the FX-55.

The Pentium M at 2.0 GHz takes the bottom feeder score in 3DMark2005. In every category, though sometimes the margin isn't very large, I'll admit.

In WorldBench Overall, we see the 2.0 GHz Pentium M tie the 3200+, which seems to be more in its category. Clock by clock performance is nice, but then again, the Athlon 64s do get a boost in nearly every application on the planet in 64-bit mode, ranging from negligible to giant gains. Then again, this test is pre-Sonoma, which means that the Dothan isn't quite played out yet.

LAME encoding is the first big win for the Pentium M, with the 2.0 GHz Pentium M outperforming even the 4000+. Almost a full ten seconds faster than the 3200+, and five seconds faster than the 3500+ (which is, theoretically, a little faster than the 3400+ highest 25w Turion 64 model.) Of course, all of the times are under a minute, though that means that with more files encoded, the performance difference would be more pronounced.

But, then again, it pulls up dead last in MusicMatch Jukebox. Ouch. It's accompanied by the 3200+, which just barely squeaks ahead. Dead last again in XMPEG DivX encoding, and this time losing to the 3200+ by an appreciable margin.

It then beats the 3200+ in Windows Media Encoder by eight seconds (434 VS 442.) The 3500+ then, in turn, defeats it by twelve seconds. The Pentium M then goes on to beat even the 3500+ by eight seconds in Adobe Premiere (414 VS 422.)

Its winning streak is cut short, however, by being absolutely shut down in the Roxio test. Not even a competition there, with the overclocked PM losing out to the 3200+.

In Photoshop, it starts to earn back lost ground, beating the 3200+ by eight points and losing to the 3500+ by nine (340 VS 349 VS 357.)

The Pentium M then proceeds to simply embarass itself in the ACDSee test, pulling up dead last by a huge margin.

It makes a recovery in the picCOLOR benchmark, with an overall score that squeaks past the 3200+, though it loses to the 3500+ by a far larger margin. If you're interested in individual score comparisons, look at the article yourself, as it would take too long for my lazy mind and carpal tunnel afflicted fingers.

The MS office test puts the 3200+ barely in front of the Pentium M. It ties with the 3500+ in the Mozilla 1.4 test. The Pentium M performs almost exactly between the 3200+ (which lost to it) and the 3500+ (which beat it) in the Mozilla+Windows Media Encoder test.

The Pentium M stumbles in the Sphinx speech recognition test, with even the overclocked version losing to the 3200+ by a fairly significant margin. Amusingly enough, even for the AMD processors, the Intel compiler gets better results, with only Pentium 4 Extreme Editions not profiting from it. Whoops?

It makes up for that, though, by beating the 3800+ (by a small margin) in the Winzip test.

It loses in the Nero test, but the Athlon 64s don't do much better, with, bizarrely, the 3200+ being the leader of the A64/PM pack.

It faces a bigger loss in the Cinema 4D renderer test.

It comes back, though, by performing near the 3500+'s level on the Cinema 4D shader test.

It then drops behind the 3200+ in the OpenGL Hardware Shading test and drops farther behind in the OpenGL Software Shading test, where it takes last place with the 3200+ nowhere in sight.

In the DirectX test of 3Ds Max, the Pentium M loses to the 3200+, and in the OpenGL version, it wins, though by a smaller margin.

In the POV Ray test, it loses, again, to the 3200+.

The power consumption test is pointless, because the Turion's chief difference IS power consumption.

Though the link to both tests were provided earlier in this topic, the Tech Report one:
http://techreport.com/reviews/2005q1...f/index.x?pg=5

Feel free to verify the results for yourself, and to check for any mistakes I may have made/spin I put on it. I linked to the first page with benchmarks, by the way, rather than the first page in the article.

What I'm seeing is that, in select applications, the Pentium M performs well above a clock-for-clock level when compared to a 512 KB L2 cache A64 at the same clock frequency (I assumed that it was a Socket 939 3200+, by the way.) For most applications, though, the Pentium M performs around the same level, or loses. I'll note that the Pentium M loses significantly more often than the A64 does, by the way.

Are they both excellent processors? Well, yeah. Is the Pentium M noticeably faster? Not by any stretch of the imagination, unless you use a very specific list of applications, and we're not even looking at the 64-bit advantage here. I used this old benchmark because I couldn't find a more recent one (with the 2.13 GHz Pentium M or a 533 MHz FSB Pentium M CPU that wasn't overclocked.) If you'd like, I could also go through such a benchmark, though I would be made a sad panda by the amount of data crawling involved.

What makes the choice for me? Price, primarily. If I can pick up a 3400+ for about the price of a 2.0 GHz Dothan, judging by those results, I'll probably beat it in nearly every application, sometimes by very respectable margins. Even with a 3200+ (which will probably be cheaper,) I'd hardly be looking at huge performance losses when compared to the Pentium M.

I think that too many people are looking at the 2.4 GHz Pentium M results and assuming that they're indicative of anything. They aren't. They were just put in to try and get a feel for the future of a Pentium M-based desktop processor. They have very little relevance in a discussion of laptops.

Hopefully wearing an effective Fire camo suit,
YuriSEAL.
post #52 of 65
Quote:
Originally Posted by HardBall
The extra width of the 64 bit GPRs and the additional extended XMM registers (SSE) do no good, unless the software is written to run under the 64-bit long mode (as opposed to compatibility mode, which makes no use of the 64 bit advantage at all).
That's a given. But weren't we discussing the advantage of 64-bit apps over 32-bit apps in the first place? The comparison itself implies that the application has been developed for, or ported to, 64-bit in addition to 32-bit; otherwise we would have nothing to compare!

Taking advantage of 64-bit architecture doesn't involve as much work as you might think, either. In most cases, for applications-level software, all that is required is a bit of tweaking to ensure everything is 64-bit clean, followed by a recompile. That's it. You've now got a 64-bit binary and you're using 16 GPRs instead of 8. I do this every day; I regularly cross-port code I've developed on 32-bit x86 to a 16-bit embedded target. The compiler does most, if not all, of the work for you -- your job, as the porter, is to work out any inconsistancies between the compilers. For example, does the target compiler assume an integer is 16- or 32-bits wide? That kind of stuff. With the appropriate type definitions in place for each platform, cross-porting code becomes a matter of setting a platform flag (e.g. "x86", "M16C") and recompiling. You can also run into trouble if the endian-ness of the two platforms differ, but we'll leave that one alone since we're talking about application software here, not drivers.

These are some of the problems you face cross-porting from one platform to another. In the case of 32-bit x86 to 64-bit x86, the compiler is (we will assume) identical, and the platform is very similar, so the task becomes easier still. AMD even had the good foresight to define the default operand size as 32-bits, even when running in long mode, which should help to reduce teething problems going from 32- to 64-bit.

Of course, it goes without saying that anything that has been hand-optimised, e.g. SIMD code, will have to be rewritten to take full advantage of the extra 8 XMM regs. But this is the price you pay for favouring performance over portability.
post #53 of 65
Quote:
Originally Posted by Aurorix
That's a given. But weren't we discussing the advantage of 64-bit apps over 32-bit apps in the first place? The comparison itself implies that the application has been developed for, or ported to, 64-bit in addition to 32-bit; otherwise we would have nothing to compare!

Taking advantage of 64-bit architecture doesn't involve as much work as you might think, either. In most cases, for applications-level software, all that is required is a bit of tweaking to ensure everything is 64-bit clean, followed by a recompile. That's it. You've now got a 64-bit binary and you're using 16 GPRs instead of 8. I do this every day; I regularly cross-port code I've developed on 32-bit x86 to a 16-bit embedded target. The compiler does most, if not all, of the work for you -- your job, as the porter, is to work out any inconsistancies between the compilers. For example, does the target compiler assume an integer is 16- or 32-bits wide? That kind of stuff. With the appropriate type definitions in place for each platform, cross-porting code becomes a matter of setting a platform flag (e.g. "x86", "M16C") and recompiling. You can also run into trouble if the endian-ness of the two platforms differ, but we'll leave that one alone since we're talking about application software here, not drivers.

These are some of the problems you face cross-porting from one platform to another. In the case of 32-bit x86 to 64-bit x86, the compiler is (we will assume) identical, and the platform is very similar, so the task becomes easier still. AMD even had the good foresight to define the default operand size as 32-bits, even when running in long mode, which should help to reduce teething problems going from 32- to 64-bit.

Of course, it goes without saying that anything that has been hand-optimised, e.g. SIMD code, will have to be rewritten to take full advantage of the extra 8 XMM regs. But this is the price you pay for favouring performance over portability.
You and I don't disagree after all then. We have just been taken different aspects of the issue.
post #54 of 65
How about we wait until the Turion is actually available for people to use?
post #55 of 65
um that techreport comparison is crap there is no 2.4ghz pm so most likely they are lying
when a tomshardware review/comparison comes out then i will trust it
post #56 of 65
Another interesting thing is that (as of now) AMD hasn't done anything to improve the speed of their laptop processors since at least June of last year. Then, as now, AMD's fastest (true) mobile offering was the Athlon 64 3400+.

Intel, meanwhile, has been fiddling around with the Pentium-M since then, cranking up the clockspeed and releasing Dothan.

... and AMD's year-old processors still (in benchmarks) edge out the newest Intel processors by a slight margin.


Intel right now has the lead in power efficiency, but they're still trying to catch up to AMD in performance.
post #57 of 65
Quote:
Originally Posted by Entropius
Another interesting thing is that (as of now) AMD hasn't done anything to improve the speed of their laptop processors since at least June of last year. Then, as now, AMD's fastest (true) mobile offering was the Athlon 64 3400+.

Intel, meanwhile, has been fiddling around with the Pentium-M since then, cranking up the clockspeed and releasing Dothan.

... and AMD's year-old processors still (in benchmarks) edge out the newest Intel processors by a slight margin.


Intel right now has the lead in power efficiency, but they're still trying to catch up to AMD in performance.
The Mobile (62w) 3700+ should be out with the new venice core (called Newark) this spring, guess they decided to skip the Winchester with the mobile cores; and the DTR 4000+ will naturally be out with the san diego core as well, since it's really the same chip as the Desktop version. The true LV cores will all be released under Turion.
post #58 of 65
So where are the Turion64 X800/6800 notebooks?
post #59 of 65
Quote:
Originally Posted by Pclover8891
when a tomshardware review/comparison comes out then i will trust it
Trust? Hate to break it to ya buddy, Tom's Hardware Guide isn't exactly the most trusted review site on the web.
post #60 of 65
Gaming: Turion 64 vs Pentium M. Winner? Whichever is paired w/ the better video card... hehe
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Notebook Forums - General
NotebookForums.com › Forums › General Notebook Discussions › Notebook Forums - General › Gaming: Turion 64 vs Pentium M