Though as a gamedeveloper. That computer lacked! Though, if the experience is better then the old. Good for you Then you can continue to make good games

Birger

very nice setup i have just updated my video card to NVidia GeForce 9600 GT and WOW  call of duty flys now i can see why every one was raving about the game now lol

 

32bit vista

2gig RAM

duel core 2.40

 

runs very nice thank you  

 

 

Na, for the resolutions you'll be working at a 9600 is perfect.

Curious. Why 32-bit Vista? That sort of caps your RAM at 3 gigs, so you'll have to replace again in probably less than a year.

And didn't I see a post a long while back by The Big Cheese himself complaining that Vista should have gone 64-bit only or something?

Curiouser and curiouser....

Dual Core / clock speed

They have hit a wall on practical cpu speed re heating issues, so they had no choice but to go down a multi core route to try and keep up overall processing speed. It is cheaper by far to provide a second core on silicon, than the investment currently needed to overcome a virtually impossible conundrum re physical limitations on increasing single core clock speed, due to heating effects.

Multi Core is though, a known dead end for consumer hardware. On a 2-5 year view new technologies that will overcome the immoveable laws of physics in current cpu designs, will be on stream - at that point watch multi core numbers drop through the floor.

So if you are at the software end of the pipe, your Return on Investment equation is based on a 2-5 year return, because you know multi core will go through the floor at consumer level, but dont yet know the detail of the new cpu designs coming down the pipe. Hence the number of applications that do now, or are in the works to, take advantage of more than two cores - the User Base will be too small on a 2-5 year view to make the Return on Investment worth it for most of them.

Now in the middle of this design/ROI nightmare the hardware guys are struggling with, along comes the 64 Bit hardware implications driven by the software end.... add to that a sprinkling on the desert from the software end struggling to get OEMs/Vendors to write applications, 32 bit drivers and compilers for Vista, let alone 64 Bit ones for an as yet unestablished market and unknown numbers of cpu cores as a "norm", and its not surprising that the guys accountable for a market space of Hundreds of Billions of Dollars are a little cautious.

As always there are no simple solutions, never mind anyone's favourite bandwagon, if there were they would be in place by now .... many things are technically possible, but fall over on closer scrutiny at a Business ROI level. Its always the latter where favourite bandwagons fall over ...

At the end of the day, I'm glad I am just the end user who uses this stuff, and not actually be accountable to work out the route through the related Business minefield to get it to me

Regards
Zy

No kidding. My computer sucks and come to think of it so does my wife's I wont even go into the kids computers as they get the handmedowns from us

Hell I will even shed a few croc tears along with the complaining   

I'm actually glad that Stardock doesn't buy thier game developers teh very top of the line.

Most of us users don't have that kind of rig and I think sometimes development house forget that.

Enjoy the new toy!

How so? The number of transistors that can be placed on a chip continues to increase, and multicore allows them to continue increasing the amount of processing power per watt. I would disagree. I think we will be seeing quite a bit of doubling in the next few years: 8, 16, 32, 64, even 128 cores I think is possible before they start hitting the next physical barrier. Multicore is not going away from consumer computing, not by a long shot. Especially not as multimedia applications become more common, and I know there are plenty of changes coming in programming languages that will allow developers to take much better advantage of multicore CPUs.



Applications can be written as 32 bit if they do not need 64 bit support. Vista is perfectly backwards compatible with 32 bit applications, and I'm sure future OSes will be as well. It will be quite some time before OSes start dropping 32 bit support. I'm thinking there are many years left for 32 bit compatibility. It's hard enough convincing Microsoft that 64 bit should be the new default, even though 4 gigs is becoming more common.

Drivers for Vista are not much of a problem anymore. If the computer meets the minimum requirements, chances are there are drivers for it. That argument is much less valid today than it was at Vista's launch. Ditto for compilers. As far as I know, both Microsoft and GNU's compilers have support for compiling to a 64 bit target.

I'm not sure "struggling" is the term I'd use. Developers make most of their money creating new software and rewriting existing software. Sure, it's a lot of work, but hey, hard work is what drives our economy. Writing software is what pays our bills. It is good that we "struggle" to write new software - it keeps food on our tables.

I gotta go with CobraAI on this one. For a typical commercial desktop application, where devs would normally struggle with the issues of 32 vs. 64-bit, it's generally a non-issue. Think of QuickBooks, Goldmine, and other such event-driven applications here. These apps don't do a whole lot that's terribly CPU-intensive.

And the tools abstract the difficult tasks these days. Visual Basic, Delphi, C++ Builder, C#, etc. The devs usually don't need to worry about the low-level stuff. It's a rare situation that even an application written in Java will have CPU problems if it is just a desktop app. Generally slowness is going to stem from a design problem or disk I/O.

For those apps, there's no reason to worry about faster and faster processors, because on a multi-core system, they will get a full processor's 100% attention most of the time. And with so many libraries already out there for making apps multi-threaded, even these simplest of applications will be able to benefit.

For more low-level applications where CPU really is a problem, writing multi-threaded code has been a good idea (when applicable, of course) for a terribly long time. Seti@home uses multi-core systems very effectively, and has for at least a year or two. Not all apps will be able to make much use of a 256-core system, I'll wager, but many will take advantage of the dual and quad core systems we have today.

And the tools, man! Check out things like IBM's Thread Building Blocks for C++. Makes it dramatically easier to build a multi-threaded application than most old-school devs are used to. And because threaded apps don't need a single core per thread, as long as you can expect a dual-core system, your app will almost certainly perform a great deal better if you use threads everywhere it makes sense.

So when we get past the speed barrier once again, why would we stop with multi-core systems? Even for apps that don't need multiple cores, they allow Windows (or OS X or Linux or BSD or ...) to run more effectively just by being able to dedicate one core to the app in question.

Unless it somehow becomes significantly cheaper to have a single-core system, I just don't see any reason they'd go away. And unless the development tools turn out to be crap (and from my (admittedly limited) experience of TBB, I just don't think that'll happen), there's no reason for devs to avoid multi-threading their apps when the average household computer is at 2 cores today or will be soon.

Wow, and I thought I was a bit behind using a 6800 when everybody else was using 8 series and 9 series cards. By the way, the 9600 is a great card for a budget price. It's the card that finally convinced me to upgrade.



This is very true - the number of bits is largely abstracted away, and it's just a matter of flipping a switch in the compiler: The compiler will happily compile to both targets.

And talking about compilers - today's languages aren't even truly compiled that much anymore. Even C++ and C# are converted to bytecode for the CLR and not truly compiled if you're doing development using Microsoft's .NET tools. It'll happily translate itself into either architecture.



I'm gonna have to say be careful about multi-threaded libraries: Just because some code in a library is multi-threaded doesn't mean your own code is multi-threaded. Your own code can still be single threaded and can bottleneck a single CPU if you're not careful. The future will need to have a lot more support of threading in the language itself, not just the libraries. If you want to see where threaded programming languages may be headed in the future, take a look at Erlang, Squeak, and F#.



Yeah - the test machines should be separate from the development machines IMHO. The development machines do a lot of compiling and debugging, so you really want them to be good machines.

One thing I'm a bit worried about is developers just plunging into threads without knowing what they're doing. You don't actually want to divide any loop into a thread: The overhead will kill it if you're not doing much in the loop. There is a lot of overhead associated with creating and maintaining threads, so they are best used where there is a significant amount of computation is being done.

Another thing I'm a bit worried about is that developers will get too bent out of shape with concurrent primitives and the shared memory model. Erlang is a popular language for concurrent programming, but uses a message based model instead of the popular (but difficult to use) shared memory model. I'm a bit worried that too many developers will be stuck on the locks, semaphores, and other low level primitives rather than handling threads at a high level. Hopefully, future programming languages will make concurrent programming easier, perhaps even invisible, to the developer.

My computer :

Intel E4500 2.2Ghz O'cd at 2.97, 2 gb CORSAIR XMS2 PC6400 800Mhz O'cd at 900Mhz,Gigabyte P35-DS3L and Sapphire Ati 2600Xt 512Mb.