View Single Post
  #3 (permalink)  
Old 10-14-2006, 09:32 PM
Jan
Guest
 
Posts: n/a
Default Re: CPU Cache vs Ghz for database speed?

Server and Client is the same machine as there's only one user. At the
moment I'm using MS-Access which is not a client-server system in the
same way like SQL, might consider SQL in the future when table volume
increases.

Paul wrote:
> Jan wrote:
> >
> > Looking for a standalone workstation PC for a single user running heavy
> > database queries, likely Windows 32bit. Is it best to have a CPU with
> > plenty of cache or plenty of GHZ?
> >
> > AMD X2 4800 with 2x1MB cache is double the price of X2 5000 2x512KB
> > cache. But would 1MB cache be much faster than 512KB cache?
> >
> > Also would Intel be significantly better, usually Intel is a bit more
> > expensive.
> >
> > The database system might not have much use for RAM beyond 2GB on
> > WindowsXP, but cache or Ghz?

>
> I probably don't understand your application all that well. In a
> database situation, there is the client (making the query) and
> the database itself (the server). The database itself does a lot
> more work per query than the client. If both the client and server
> were to live on the same machine, then the problem might be
> more "interesting". Otherwise, I would expect the client to be
> a pretty lightweight application.
>
> To see the impact of cache in the real world, you could look at
> some benchmarks. Here, for example, you can see that the 4800+
> beat the 5000+, in converting MSword to PDF. For whatever reason,
> the extra cache helped here, much more than the clock rate difference.
>
> http://www23.tomshardware.com/cpu.ht...=466&chart=189
>
> In other cases, it is just the pure MHz that is helping:
>
> http://www23.tomshardware.com/cpu.ht...=466&chart=171
>
> Doubling the cache might be worth several hundred MHz of equivalent
> performance. But modern processors are pretty fickle when it
> comes to collecting on that promise of performance. There
> are some games, for example, where extra cache doesn't help.
> Thus, the best insurance, is to select the processor with the
> highest clock rate as the first priority (for a given architecture
> and instruction per clock rating). If someone is "giving the cache away",
> then take it.
>
> I would choose the 5000+ unless I had a benchmark, like
> the first (counterintuitive) benchmark result, to guide me to a
> different choice.
>
> Also, by looking at that table, you can see that the Conroe/Allendale
> processors are faster than the processors you are considering.
> That is, even though their absolute clock rate is lower than a lot
> of other processors in the list. Conroe has better instruction level
> parallelism (higher IPC), and you can only compare Conroe clockrates
> to other Conroes. Using a benchmark table like the one on Tomshardware
> is one way to discover how they all compare, in general computing
> terms.
>
> Is it possible to compare existing computers doing queries ?
> Do you see any appreciable difference between them ?
> Gathering data from your present computing platform may
> also help you decide whether client processor speed is a
> factor at all. Maybe your most demanding application on the
> new machine, is running a web browser.
>
> If the database server is also going to live on that machine,
> then you would be best advised to find an entirely different
> benchmarking site. Databases are more likely to be benchmarked
> on server machines, with an emphasis on supporting multiple users.
> You will only occasionally find someone benchmarking a database
> on a desktop machine.
>
> Paul



Reply With Quote