Screamin' 64-bit Vista machine

  • Thread starter Thread starter Puppy Breath
  • Start date Start date
P

Puppy Breath

Suppose I were going to build a 64-bit Vista machine. Something along the
lines of 2 - 4 GB RAM and maybe a terabyte or more of SATA II storage. This
machine's main role would be sort of a "media central" server for all
household music, pix, videos, recorded TV. And while it's not just sitting
there being server-ish it will also be my main work/play machine for
creating/editing those kinds of files and perhaps some basic software and
Web site development stuff.



Number 1 priority is that it be screamin' fast (duh). But being able to run
all existing 32-bit apps would be a major plus. This machine serves no
business purpose so cost can't be too outrageous.



For those of you who have been around the 64-bit block a few times already,
my question is: What processor/chipset/motherboard combo would be a good
starting point for building such a beast?
 
Hmm... you're probably looking at something dual core definately. My honest
advice (and I presume Andre would say the same) - go AMD, because Intel is
no match for processors especially the 64-bit wave than AMD.

AMD Dual Core... deffo.

--
Zack Whittaker
» ZackNET Enterprises: www.zacknet.co.uk
» MSBlog on ResDev: www.msblog.org
» Vista Knowledge Base: www.vistabase.co.uk
» This mailing is provided "as is" with no warranties, and confers no
rights. All opinions expressed are those of myself unless stated so, and not
of my employer, best friend, Ghandi, my mother or my cat. Glad we cleared
that up!

--: Original message follows :--
 
Zack Whittaker said:
Hmm... you're probably looking at something dual core definately. My
honest advice (and I presume Andre would say the same) - go AMD, because
Intel is no match for processors especially the 64-bit wave than AMD.

AMD Dual Core... deffo.

--
Zack Whittaker
» ZackNET Enterprises: www.zacknet.co.uk
» MSBlog on ResDev: www.msblog.org
» Vista Knowledge Base: www.vistabase.co.uk
» This mailing is provided "as is" with no warranties, and confers no
rights. All opinions expressed are those of myself unless stated so, and
not
of my employer, best friend, Ghandi, my mother or my cat. Glad we cleared
that up!

--: Original message follows :--


Zach,
does intel even have the new 64's out yet? I heard something about
"Merom"?
 
Hello!

Puppy Breath said:
Suppose I were going to build a 64-bit Vista machine. Something along the lines of 2 - 4 GB RAM and maybe a terabyte or more of
SATA II storage. This machine's main role would be sort of a "media central" server for all household music, pix, videos, recorded
TV. And while it's not just sitting there being server-ish it will also be my main work/play machine for creating/editing those
kinds of files and perhaps some basic software and Web site development stuff.



Number 1 priority is that it be screamin' fast (duh). But being able to run all existing 32-bit apps would be a major plus. This
machine serves no business purpose so cost can't be too outrageous.



For those of you who have been around the 64-bit block a few times already, my question is: What processor/chipset/motherboard
combo would be a good starting point for building such a beast?

Wait for Conroe (first energy-friendly 64-bit dual-core desktop CPU with virtualization)
http://weblog.infoworld.com/virtualization/archives/2006/04/intels_vpro_vir.html
http://www.xbitlabs.com/news/cpu/display/20060428155928.html
http://www.digitimes.com/mobos/a20060428PR213.html

MB with AGP
http://www.ocworkbench.com/ocwbcgi/newspro/viewnews.cgi?newsid1145671352,37752,

MB with HDTV
http://www.ocworkbench.com/ocwbcgi/ultimatebb.cgi?ubb=get_topic;f=29;t=001356;p=0
http://www.xbitlabs.com/news/mainboards/display/20060425175704.html

Cheers, Roman
 
Intel's newest is the Pentium Extreme Edition.

EE 840 - 3.2 Ghz, dual core, hyperthreading, 2x1mb L2 cache.
EE 955 - 3.46 Ghz, dual core, hyperthreading, 2x2mb L2 cache.
EE965 - 3.7 Ghz, dual core, hyperthreading, 2x2mb L2 Cache.

All require the Intel 975X or 955X chipset.

Their newest, the D975XBX motherboard has 3PCIe slots, 3PCI slots, and both
Intel Raid Controller (ports 0-3) and the Silicon Image SoftRaid5 Controller
(ports 4-7) onboard, with gigabit ethernet & 4 USB on-board and pins for 4
more, and one IDE & one floppy header. Accepts up to 8GB of memory.

Larry
 
Make sure you get a motherboard with a PCI Express - get yourself a
screamingly fast graphics card... oooooh yeh ;o)

--
Zack Whittaker
» ZackNET Enterprises: www.zacknet.co.uk
» MSBlog on ResDev: www.msblog.org
» Vista Knowledge Base: www.vistabase.co.uk
» This mailing is provided "as is" with no warranties, and confers no
rights. All opinions expressed are those of myself unless stated so, and not
of my employer, best friend, Ghandi, my mother or my cat. Glad we cleared
that up!

--: Original message follows :--
 
Zack said:
Hmm... you're probably looking at something dual core definately. My honest
advice (and I presume Andre would say the same) - go AMD, because Intel is
no match for processors especially the 64-bit wave than AMD.

AMD Dual Core... deffo.

Seconded! :)
 
And then later this year , if you do decide to go quad-core, just
pop-out the dual core and pop-in the quadcore and reboot.
Very smooth

bobb
 
Hello!

- Bobb - said:
And then later this year , if you do decide to go quad-core, just pop-out the dual core and pop-in the quadcore and reboot.
Very smooth

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2748
[quote - concluding thoughts]
At AnandTech, we were pretty skeptical about the "threading is our only savior" future, as Tim Sweeney, the leading developer behind
the Unreal 3 engine, explained the challenges of multi-threaded development of the next generation of games. The fat, wide OoO core
running at high clockspeeds was buried a little too soon. Yes, Intel's Core does not use the aggressive domino and LVS
circuit-design strategy that NetBurst designs used to achieve stunning clockspeeds. At the same time, it is a fat, massive
reordering CPU which gives free lunch to developers who don't want to spend too much time on debugging heavily threaded
applications. Multi-core is here to stay, but getting better performance is once again the shared responsibility of both the
developer and the CPU designer. Yes, dual-core is nice, but single threaded performance is still important!
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2377

Writing multithreaded code means much higher software development costs while CPU development gets easier and thus cheaper (compared
to even more complex superscalar CPUs). No wonder that the CPU developers are very motivated to hype the multi-core route, but the
software development community is probably less enthusiastic.

Intel and other manufacturers should not simply push the costs of getting higher performance onto the software developers. Because,
in the end, it will be the consumer who will pay the final price: either more money or buggier software with more crashes and hangs.
One way that Intel and others can help to keep multithreaded development costs under control while offering increasing CPU
performance is to keep investing in ILP and thus higher IPC cores; another option is to improve the interCPU communications.

The easiest part of multithreading is using threads that are running completely independent, that don't share any data. But this
source of threading is probably already being used almost to the fullest. In order to tap into a new source of multithreading, such
as the largely unused potential of multithreaded AI, Phyics and animation, it is important that developers don't have to worry about
interthread messaging and synchronization lowering performance.

Very fast interprocessor communications to make sure that thread synchronization comes with little overhead will give a bigger
incentive to developers to invest the extra time in multithreading.

http://www.hardforum.com/showthread.php?t=983781

Since I purchased my X2 and then my dual core Opteron, I noticed that gaming performance suffers while running certain games.
[H]ardOCP noted this in one of their reviews as the "Benny Hill Effect." There is a certain amount of stuttering or random
speedup/slowdowns while running dual core CPU's in single threaded games. The reason for these problems has to do with power state
management in some form or another, as these fixes are designed to address specific power state management issues. This thread is
intended to consolidate a number of fixes I've come across in this forum and elsewhere.


3. Use an affinity masking tool such as
ImageCFG (http://www.robpol86.com/Pages/imagecfg.php for instructions on how to use). Backup your .exe before using this program.
Imagecfg has a problem with some directories with spaces in them, so its easiest to stick it in the folder with the *.exe file you
want to change. Then use the command you need (knowledge of the DOS prompt is a must ):

imagecfg -a 0x1 game.exe for core 1
imagecfg -a 0x2 game.exe for core 2

This will alter your .exe file, so make a backup of it. Especially since future game patches might not work with a patched .exe
[/quote]

http://forums.amd.com/index.php?act=Print&client=printer&f=31&t=60070
[quote (by MrWicked1968) ]
I think you are half right. This isn't AMD's problem, the problem is the lack of games designed to take advantage of the dual core
cpu. And it's not just games, either, though they seem to create the biggest problems.

I've seen a lot of threads where people are having trouble gaming with an X2, which is why it makes sense to me to avoid an X2 until
games become multi-threaded or the developers begin releasing patches (an unlikely scenario).
[/quote]


Best regards, Roman
 
Hello!

Zack Whittaker said:
Hmm... you're probably looking at something dual core definately. My honest advice (and I presume Andre would say the same) - go
AMD, because Intel is no match for processors especially the 64-bit wave than AMD.

AMD Dual Core... deffo.

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2748
[quote - concluding thoughts]
The Intel Core architecture is clearly the heir and descendant of the hugely successful P6 architecture. However, it has state of
the art technology on board such as micro-op/macro-op fusion, memory disambiguation and massive SIMD/FP power.

Compared to the excellent AMD K8/Hammer architecture, the Core CPU is simply a wider, more efficient and more out of order CPU. When
I suggested to Jack Doweck that the massive execution resources may not be fully used until SMT is applied, he disagreed completely.
Memory disambiguation should push the current limits of ILP in integer loads a lot higher, and the massive bandwidth that the L1 and
L2 can deliver should help Core to come close to the execution utilization percentages of the current P-M. 33% more execution
potential could thus come very close to 33% more performance, clock-for-clock.

So is it game over for AMD? Well, if you read the previous pages, it is pretty clear that there are some obvious improvements that
should happen in AMD's next generation. However, there is no reason at all to assume that the current K8 architecture is at the end
of its life. One obvious upgrade possibility is to enhance the SSE/SIMD power by increasing the wideness of each unit or by simply
implementing more of them in the out of order FP pipeline.

To sustain the extra (SIMD) FP power, AMD should definitely improve the bandwidth of the two caches further. The K7 had a pretty
slow L2-cache, and the K8 doubled the amount of bandwidth that the L2 could deliver for example. It's not unreasonable to think a
256-bit wide cache bus could be added to a near-future AMD design.

Finally, there is also a lot of headroom for increasing integer performance. The fact that Loads can hardly be reordered has been a
known weak point since the early K7 days. In fact, we know that engineers at AMD were well aware of it then, and it is surprising
that AMD didn't really fix this in the K8 architecture. Allowing a much more flexible reordering of Loads - even without memory
disambiguation - would give a very healthy boost to IPC (5% and more). It is one of the main reasons why the P-M can beat the Athlon
64 clock-for-clock in certain applications.
[/quote]

Cheers, Roman
 
Whatever he's saying below,
how about you go to
http://multicore.amd.com/WhatIsMC/en/Default.aspx
and you can check AMD info for yourself.
or http://multicore.amd.com/Products/AMD_Opteron_Overview.pdf
shows a CPU block diagram.

www.amd.com/benchmarks etc lots of info on their site.

Bobb



roman modic said:
Hello!

- Bobb - said:
And then later this year , if you do decide to go quad-core, just
pop-out the dual core and pop-in the quadcore and reboot.
Very smooth

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2748
[quote - concluding thoughts]
At AnandTech, we were pretty skeptical about the "threading is our
only savior" future, as Tim Sweeney, the leading developer behind the
Unreal 3 engine, explained the challenges of multi-threaded
development of the next generation of games. The fat, wide OoO core
running at high clockspeeds was buried a little too soon. Yes, Intel's
Core does not use the aggressive domino and LVS circuit-design
strategy that NetBurst designs used to achieve stunning clockspeeds.
At the same time, it is a fat, massive reordering CPU which gives free
lunch to developers who don't want to spend too much time on debugging
heavily threaded applications. Multi-core is here to stay, but getting
better performance is once again the shared responsibility of both the
developer and the CPU designer. Yes, dual-core is nice, but single
threaded performance is still important!
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2377

Writing multithreaded code means much higher software development
costs while CPU development gets easier and thus cheaper (compared to
even more complex superscalar CPUs). No wonder that the CPU developers
are very motivated to hype the multi-core route, but the software
development community is probably less enthusiastic.

Intel and other manufacturers should not simply push the costs of
getting higher performance onto the software developers. Because, in
the end, it will be the consumer who will pay the final price: either
more money or buggier software with more crashes and hangs. One way
that Intel and others can help to keep multithreaded development costs
under control while offering increasing CPU performance is to keep
investing in ILP and thus higher IPC cores; another option is to
improve the interCPU communications.

The easiest part of multithreading is using threads that are running
completely independent, that don't share any data. But this source of
threading is probably already being used almost to the fullest. In
order to tap into a new source of multithreading, such as the largely
unused potential of multithreaded AI, Phyics and animation, it is
important that developers don't have to worry about interthread
messaging and synchronization lowering performance.

Very fast interprocessor communications to make sure that thread
synchronization comes with little overhead will give a bigger
incentive to developers to invest the extra time in multithreading.

http://www.hardforum.com/showthread.php?t=983781

Since I purchased my X2 and then my dual core Opteron, I noticed that
gaming performance suffers while running certain games. [H]ardOCP
noted this in one of their reviews as the "Benny Hill Effect." There
is a certain amount of stuttering or random speedup/slowdowns while
running dual core CPU's in single threaded games. The reason for these
problems has to do with power state management in some form or
another, as these fixes are designed to address specific power state
management issues. This thread is intended to consolidate a number of
fixes I've come across in this forum and elsewhere.


3. Use an affinity masking tool such as
ImageCFG (http://www.robpol86.com/Pages/imagecfg.php for instructions
on how to use). Backup your .exe before using this program. Imagecfg
has a problem with some directories with spaces in them, so its
easiest to stick it in the folder with the *.exe file you want to
change. Then use the command you need (knowledge of the DOS prompt is
a must ):

imagecfg -a 0x1 game.exe for core 1
imagecfg -a 0x2 game.exe for core 2

This will alter your .exe file, so make a backup of it. Especially
since future game patches might not work with a patched .exe

http://forums.amd.com/index.php?act=Print&client=printer&f=31&t=60070
[quote (by MrWicked1968) ]
I think you are half right. This isn't AMD's problem, the problem is
the lack of games designed to take advantage of the dual core cpu. And
it's not just games, either, though they seem to create the biggest
problems.

I've seen a lot of threads where people are having trouble gaming with
an X2, which is why it makes sense to me to avoid an X2 until games
become multi-threaded or the developers begin releasing patches (an
unlikely scenario).
[/quote]


Best regards, Roman
[/QUOTE]
 
I am a programmer, I don't write device drivers etc so I don't go deep down
into the threading, but, I do know that mores law will not save us any more.

When CPUs get faster eg high clock speed, then single threaded application
get a good boost.

When CPUs get more cores, eg dual core, the clock speed stays the same, so
our apps don't get a good boast.

So, we have to think about this, and think about context switching, every
time a thread switches it wipes the CPU cache, I am not expert, but if your
interested, do a Google.

I was at a longhorn server conference, and one of the talks touched on this
issue.

Write code the will scale, if you go from single core to dual core and scale
if you stay with single core but ramp up clock speed, is tricky.



roman modic said:
Hello!

And then later this year , if you do decide to go quad-core, just pop-out the dual core and pop-in the quadcore and reboot.
Very smooth

http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2748
[quote - concluding thoughts]
At AnandTech, we were pretty skeptical about the "threading is our only
savior" future, as Tim Sweeney, the leading developer behind
the Unreal 3 engine, explained the challenges of multi-threaded
development of the next generation of games. The fat, wide OoO core
running at high clockspeeds was buried a little too soon. Yes, Intel's
Core does not use the aggressive domino and LVS
circuit-design strategy that NetBurst designs used to achieve stunning
clockspeeds. At the same time, it is a fat, massive
reordering CPU which gives free lunch to developers who don't want to
spend too much time on debugging heavily threaded
applications. Multi-core is here to stay, but getting better performance
is once again the shared responsibility of both the
developer and the CPU designer. Yes, dual-core is nice, but single
threaded performance is still important!
http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2377

Writing multithreaded code means much higher software development costs
while CPU development gets easier and thus cheaper (compared
to even more complex superscalar CPUs). No wonder that the CPU developers
are very motivated to hype the multi-core route, but the
software development community is probably less enthusiastic.

Intel and other manufacturers should not simply push the costs of getting
higher performance onto the software developers. Because,
in the end, it will be the consumer who will pay the final price: either
more money or buggier software with more crashes and hangs.
One way that Intel and others can help to keep multithreaded development
costs under control while offering increasing CPU
performance is to keep investing in ILP and thus higher IPC cores; another
option is to improve the interCPU communications.
The easiest part of multithreading is using threads that are running
completely independent, that don't share any data. But this
source of threading is probably already being used almost to the fullest.
In order to tap into a new source of multithreading, such
as the largely unused potential of multithreaded AI, Phyics and animation,
it is important that developers don't have to worry about
interthread messaging and synchronization lowering performance.

Very fast interprocessor communications to make sure that thread
synchronization comes with little overhead will give a bigger
incentive to developers to invest the extra time in multithreading.

http://www.hardforum.com/showthread.php?t=983781

Since I purchased my X2 and then my dual core Opteron, I noticed that
gaming performance suffers while running certain games.
[H]ardOCP noted this in one of their reviews as the "Benny Hill Effect."
There is a certain amount of stuttering or random
speedup/slowdowns while running dual core CPU's in single threaded games.
The reason for these problems has to do with power state
management in some form or another, as these fixes are designed to address
specific power state management issues. This thread is
intended to consolidate a number of fixes I've come across in this forum and elsewhere.


3. Use an affinity masking tool such as
ImageCFG (http://www.robpol86.com/Pages/imagecfg.php for instructions on
how to use). Backup your .exe before using this program.
Imagecfg has a problem with some directories with spaces in them, so its
easiest to stick it in the folder with the *.exe file you
want to change. Then use the command you need (knowledge of the DOS prompt is a must ):

imagecfg -a 0x1 game.exe for core 1
imagecfg -a 0x2 game.exe for core 2

This will alter your .exe file, so make a backup of it. Especially since
future game patches might not work with a patched .exe
http://forums.amd.com/index.php?act=Print&client=printer&f=31&t=60070
[quote (by MrWicked1968) ]
I think you are half right. This isn't AMD's problem, the problem is the[/QUOTE]
lack of games designed to take advantage of the dual core
cpu. And it's not just games, either, though they seem to create the biggest problems.

I've seen a lot of threads where people are having trouble gaming with an
X2, which is why it makes sense to me to avoid an X2 until
games become multi-threaded or the developers begin releasing patches (an unlikely scenario).


Best regards, Roman
[/QUOTE]
 
Hello!


- Bobb - said:
Whatever he's saying below,
how about you go to
http://multicore.amd.com/WhatIsMC/en/Default.aspx
and you can check AMD info for yourself.
or http://multicore.amd.com/Products/AMD_Opteron_Overview.pdf
shows a CPU block diagram.

www.amd.com/benchmarks etc lots of info on their site.

Thanks for the links.

Here is another example:
http://groups.google.com/group/borl...technical/browse_frm/thread/f32db22eff1c7ce9/
"FWIW Delphi 7 compile times suffer on dual-core, I'm running it with
affinity adjusted to single-core, but this requires in turn adjusting
the affinity of debugged applications (as by default, they inherit the
affinity of the debugger)."

BTW, I'm not against dual-core, I just want to say that
with older apps you should be careful...

[quote - from the same link]
Don't doubt it a second, that's the way to go :)
And since it's new hardware, get 64bit compatible parts and a WinXP64 Pro (same
price as XP32) while you're at it, the OS is just way more responsive that XP32
(it's as responsive as Win2k3, without having to down-tweak a server OS).

In the first two days after installing, the combination of the 64bit OS
strictness, full DEP and dual-core allowed me to catch a dozen bugs that had
gone "unnoticed" for months, maybe years (they might have been noticed, but only
as non-reproducible random crashes).
...

The application I observed the slowdown for is about 950k lines, thousandths of
units: a whole build happens in around 35 seconds with D7's affinity adjusted to
single-core, about 45-50 seconds without, so it's not a fatal slowdown, but it's
noticeable.
As for why it's slower, I'm not sure, but I suspect it could be the same issue
that affected InterBase/FireBird some time ago: when Delphi 7 is compiling
without affinity limitation, it occupies both cores at about 40%, with affinity
set, I get one core at 100% (same pattern InterBase had on dual CPUs).
So it could be time wasted by compiler process/thread getting flipped constantly
between the two cores by the OS. Another possibility could be that some file
access patterns used by the compiler gets in the way of efficient disk I/O when
ran on "truly" multi-thread capable hardware.
[/quote]

Best regards, Roman
 
Back
Top