Moore's Law

  • Comments posted to this topic are about the item Moore's Law

  • I don't know, multiple fast cores.. The only thing I find exciting is the number of cores.. Speeds have largely peeked..

    CEWII

  • Clock speed.. is not that relevant any more, at least not as it was some years ago. You might have noticed that nothing has happened with the clock for a few years time now.

    What is important is how the cpu performs during a variation of tests.

    Edit: And yes, I find it interesting.

  • desktops, servers it's really all the same at this point. I buy what I can afford... the most Cores and speed for the money. I do take a look at the on chip memory structures as well, but that's really about it.

    -Luke.

    To help us help you read this[/url]For better help with performance problems please read this[/url]

  • Every serious SQL task, wether it's OLTP or OLAP, has to deal with some nasty rotating plate along a tiny magnetic core: the hard disk! More memory solves this problem only partialy, and over the years hard disk access has become the bottle neck for SQL Server on many recent installations. Because the size of hard disks increases more rapidly than their speed, separate partitions for data and logs reside often on the same disks, making the access times even worse.

    Whenever you replace the hardware for SQL Server, how often this action was triggered by the lack of processing power? On several instances, replacing the hard disk controler, adding some diks and reconfiguring them to a RAID 10 set could postpone server replacement for years. Add some extra memory for your ever growing database will also increase the size of the other caches, allowing SQL Server to cache more procedures and queries thereby decreasing the computational load on the processor even further.

    Maybe some day Microsoft will add a 'back-up only' option to SQL Server that will allow you to keep your entire database with its transction log in memory; you'll still be able to restore it from your last full, differential and log back-ups but the disk access will not hamper your transactions any more. Then I will look for faster processors, more cores and a lot more memory in my SQL Server hardware!

  • I believe I am jaded about progress on the desktop because whenever we get faster hardware, we get slower software and the user experience is approximately the same. If you're a big gamer then I guess things still improve, and speech control will go mainstream one day (Vista has it as standard but they don't push it), and we'll have to use pronounceable variable names.

    But you can't pick a processor and order a good system around it, either. System building is a technical specialism, and basically you have to wait for a vendor to build the system that you want. That may never include the cute new processor that you heard about.

    So really, are you excited about the new system, versus the new processor?

    On top of that, tuning a new computer to get the best out of it is hard work. It really spoils the enjoyment.

    As for a whole new dimension of bugs to solve, I am ecstatic to leave that to Microsoft. In fact, the number of service pack fixes that say "This fixes a bug in parallelism" influences me strongly to not use parallelism in individual queries: there's got to be a bunch of bugs they didn't find yet. Anyway our servers have more users than there are processors, so the point of parallelism is? 🙂

  • My computer at home is primarily a gaming machine, and I build my own machines, so for that, I pay attention to the details, including the CPU specs.

    For the servers, I pay attention if the hardware is in any way my responsibility, which it currently is not.

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • Our environment is going to more and more virtual servers connected to our SAN. So, I find myself more concerned with VMWare's limitations on CPU cycles, memory allocation and the SAN's access speeds. And to be honest, the only time I concern myself with CPU is when we're processing a cube or when someone misconfigured the thread count on a Red Gate backup as the database engine itself rarely pushes the CPU utilization.

    -Jeff

  • As others have said, the CPU seldom is the bottleneck in a database server. The only interesting thing to me about newwer processors is the tendancy toward more efficiency. Performance per Watt will determine long term costs. The number of cores and gigahertz just aren't a determining factor for a database server unless it's on a shared machine that is also doing other processing.

    I/O and disk configuration are the real problems. I can't tell you how many times I've seen other people setup database servers with just a single RAID 5 array and say "now all reads and writes will be load balanced across all the disks!" and I just smack my forehead. The disk heads will be jumping back and forth constantly between TempDB, transaction log, data pages, index pages, etc, and will bog down disk I/O and thus your database. If your disk setup is bad, or network setup is bad, all those CPU cores will be twiddling their thumbs waiting for something to do.

  • ho hum.

    Certainly there is an interest in getting a fast new processor, but other than performance levels, it does not really change my job any. You deal with a slow processor just the same as you deal with a fast one.

    ...

    -- FORTRAN manual for Xerox Computers --

  • It seems that most people are like me. The CPU enhancements don't mean a lot to them.

    Except for the gamers out there, they want to squeeze out every cycle they can from silicon

  • I buy the best I can afford at the time, and then use it until it no longer handles the load. I only start shopping for a new system when I begin having problems doing something or I try to do something new and find the old machine/OS/Sql Server version can't handle it.

  • Order of magnitute clock speed increases and doubled hyper threading counts still send shivers through my inner geek.

    Do I order them for production SQL Servers so I can run on the bleeding edge? Not a chance. For me, servers are commodities, I want the best bang for the buck, I want it tuned for its' purpose and I want them reliable so they have a lifetime that makes ROI sense.

    I'd buy the bleeding edge for the dev labs, but I want the solids in the data centre.

    Regards,

    Derek.

  • I won't get excited until the software does something with the promised speed. I use a four processor machine for my dev workstation and there are plenty of times when the VS IDE just seems to bog down - with four processors! I get multi threading is hard, maybe we'll get to the point where multi threading works better than multiple VM's.

    I want a 64bit CPU on new purchases, but that's about the limit of my interest!

  • I don't care much since I don't spec out or have control of the hardware used here or at client sites. Most of my problems aren't CPU or IO, they are people and process issues. 😛

Viewing 15 posts - 1 through 15 (of 27 total)

You must be logged in to reply to this topic. Login to reply