Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (535)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  All these new n-core CPU systems...  (Read 6593 times)
0 Members and 1 Guest are viewing this topic.
Offline appel

JGO Wizard


Medals: 50
Projects: 4


I always win!


« Posted 2006-09-30 03:57:05 »

I'm wondering what the difference is for the normal programmer?

Almost every new system out there has a multi-core architecture; but does that mean we can start cutting our games up into bunch of threads?

One thread running the game-logic-loop, and one thread running the render-buffer-loop?

Intel said there will be 80-core systems out within 5 years (for datacenters though only), but for desktop computers we already have multi-core systems (2-4 cores). I wonder when those 80-core systems will be out for desktops, we'll be able to not only run game-logic and render in seperate threads, but also individual game objects, or other calculations.

It sure seems old to run a game in a linear fashion.

Has there any research been done into, hm, what can I call it, "Parallel Game Engines" | "Multicore Game Engines"?

Also, are modern OO languages outdated because of the complexity of writing synchronized multi-threaded applications? Will we all be programming in some other type of languages within 5 years?

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Offline appel

JGO Wizard


Medals: 50
Projects: 4


I always win!


« Reply #1 - Posted 2006-09-30 04:03:02 »

Of course, 1 google query gives me a good article to read; http://harkal.sylphis3d.com/2006/02/16/multithreading-game-engines-for-multicore-machines/

Still a very interesting topic, although not a new one, but has become more interesting in recent months.

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Offline woogley
« Reply #2 - Posted 2006-09-30 05:43:21 »

I'm not very hardware savvy, but don't n-core processors share the same data bus? so there may be *some* improvement with 2-4 cores, but any higher would probably cost performance instead of gain it. it may be a good rule of thumb to keep your games at a max of 2 threads (logic/render). I personally keep mine 1-threaded, as AWT is doing its own collection of threads anyway (but this doesnt apply to lwjgl users etc..)
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline appel

JGO Wizard


Medals: 50
Projects: 4


I always win!


« Reply #3 - Posted 2006-09-30 06:08:07 »

Well, it's very simple really. If you have 1 CPU, then that 1 CPU is only capable of linear processing, that is, 1 calculation at a time. If you have many threads on a 1 CPU system, then only 1 thread will be processed at any given time. The multi-threaded architecture in operating systems makes sure that (depending on priority) all threads running on the system gets some CPU time.

The bad thing about threads on a 1 CPU system is that they're all competing for CPU time, since only 1 of them can be processed at a given time. The rest sits idle, eagerly waiting. And when some idle thread gets the goahead to be processed, then the CPU needs to get prepared for a) put away the thread it was working on b) get prepared for the new thread to work on. This is a delay time, and this is wasted time, our CPU is basically idle during this, and this is a expensive maneuver.

The more threads we have on our system, then the more thread(process)-switching we need to do, and hence we have more delay time that starts to accumulate.

This is one of the reason you don't do multi-threaded games on a single-core system.


However, if you have two processors, then you can have two threads in process at any given time. This would be really good for games, so on one CPU you could have the game-logic-thread, and on the other CPU you could have the render-thread. (or some other arrangement)

Imagine if you have 80 CPUs(cores), and you could have 80 threads in process at any given time.

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Offline appel

JGO Wizard


Medals: 50
Projects: 4


I always win!


« Reply #4 - Posted 2006-09-30 06:13:30 »

Sorry, didn't answer your question.

...don't n-core processors share the same data bus?

I don't really know how that works. My guess is yes, they share the same data bus, since those n-core processors are in one package, they have to be connected to the same data bus.

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Offline woogley
« Reply #5 - Posted 2006-09-30 06:22:39 »

Imagine if you have 80 CPUs(cores), and you could have 80 threads in process at any given time.

true, but like I was saying, the bandwidth of the data bus I think would negate the parallelization, assuming they share the same bus

with 2 to 4 cores, i dont think there's much problem. I think I read somewhere that dual-cores range from a 40% to 70% improvement

edit: aha! found that article (dated April 2005): http://news.com.com/AMD+releases+dual-core+server+chips/2100-1006_3-5678562.html

5th paragraph down..

Quote
Overall, a dual-core Opteron will outperform a single-core version running at the same speed by 40 percent to 70 percent, depending on the application, said Ben Williams, vice president of the commercial business at AMD.

also in that article..
Quote
The additional core, however, will not lead to data bottlenecks, Williams said. HyperTransport was recently sped up from 800MHz to 1GHz. "Even at 800MHz, we weren't saturating the bus," he said.

so maybe they can go above 4 cores, but I think 80 might be a stretch for today's buses Smiley
Offline appel

JGO Wizard


Medals: 50
Projects: 4


I always win!


« Reply #6 - Posted 2006-09-30 06:44:08 »

Yes, "depending on the application", hehe, only if the application supports multithreading, which a lot don't do.

Also, I've noticed many of these high-end multicore CPU's being sold as a "powerful gaming computer". Appearently, targeting end-users that don't know any better.
Quote
Unlike Intel, AMD will not bring the dual-core concept to its Athlon 64 FX line of gamer chips yet because most games aren't threaded for dual-core operations.

The fact that most of these multicore systems are also (or mainly) targeted for servers shows the difference between the desktop and server enviroment, and that desktop enviroment is yet not ready for multicore systems.

In 5-6-7 years, who knows, maybe we'll have some new type of system buses that have better support for a high number of cores.


I find this to be interesting, how to use all these new multicore CPU's on the market on the desktop, and how a programmer can make use of multicore systems without the hazzle of multi-threaded programming. :>

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Offline appel

JGO Wizard


Medals: 50
Projects: 4


I always win!


« Reply #7 - Posted 2006-09-30 16:57:08 »

Here is a nice video showing a game designed to run on a multicore system, pretty amazing;

http://www.youtube.com/watch?v=D3HybhZjcGE&eurl=

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Offline CommanderKeith
« Reply #8 - Posted 2006-09-30 17:12:14 »

wow, that's pretty amazing. 

When they say 'we use a core just for the physics' do you think that they can actually secure the core for the physics thread or would it be done by the operating system & they'd just schedule a thread for physics like we would, hoping that it gets its own core?

Offline appel

JGO Wizard


Medals: 50
Projects: 4


I always win!


« Reply #9 - Posted 2006-09-30 17:22:53 »

Does anyone know how Java supports multicore architectures? Can you create a thread and assign it to be always run on a defined core? Or do you have to simply hope the JVM/OS assign the thread to a unoccupied core?


Anyway, here's a awesome article exactly about what I'm wondering about: http://www.gamasutra.com/features/20060906/monkkonen_01.shtml

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline CommanderKeith
« Reply #10 - Posted 2006-09-30 18:28:41 »

No, its not possible to do this in Java AFAIK.  You just schedule a thread & then its all up to the OS.  Thread priorities can be used however.

For example, you can't even tame the garbage collector thread to run when you want  Sad.

Offline PeterB

Junior Member





« Reply #11 - Posted 2006-09-30 18:57:01 »

I you look on google video for QuakeCon 2006, John Carmack from id software talks a bit about his research into using multi-core processors.
For example in a dual-core system one would be used for the graphics rendering loop and the other for everything else.

Vault101 / Mace The Game
There are 10 kinds of people in the world. Those who understand binary and those who don't.
Offline appel

JGO Wizard


Medals: 50
Projects: 4


I always win!


« Reply #12 - Posted 2006-09-30 20:19:46 »

For example in a dual-core system one would be used for the graphics rendering loop and the other for everything else.

Yes, but if you design your game to work only for dual-core systems, then it won't make use of the other two cores if you're running the game on quad-core systems.

You need some game-engine design that can work for all multicore systems, even if they only have 1 processor, or 2, or 80. The game engine needs to be able to spread as much processing around. That sort of a *problem* is what I'm interested in.

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Offline appel

JGO Wizard


Medals: 50
Projects: 4


I always win!


« Reply #13 - Posted 2006-09-30 20:38:42 »

No, its not possible to do this in Java AFAIK.  You just schedule a thread & then its all up to the OS.  Thread priorities can be used however.

For example, you can't even tame the garbage collector thread to run when you want  Sad.

Ok, hm, what is the future in Java then if you cannot control the threads on a lower-level, like dedicate a whole core to a defined thread? Multicore systems are appearently the future and the way to go, so are we seeing Java dying out?

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #14 - Posted 2006-09-30 20:48:46 »

No, its not possible to do this in Java AFAIK.  You just schedule a thread & then its all up to the OS.  Thread priorities can be used however.

For example, you can't even tame the garbage collector thread to run when you want  Sad.

Ok, hm, what is the future in Java then if you cannot control the threads on a lower-level, like dedicate a whole core to a defined thread? Multicore systems are appearently the future and the way to go, so are we seeing Java dying out?
What, exactly, would you gain by being able to control the threads on such a low level?

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline PeterB

Junior Member





« Reply #15 - Posted 2006-10-01 00:15:49 »

This topic has got me interested as I'd always thought that new threads created in a java app may be 'assigned' a different cpu core if the operating system sees fit.
Well, one quick test project on an Intel Centrino Duo (Win XP) shows that 2 worker threads kicked off will use all of ONE core only.

Looking on the Java Technology forums,  there are quite a few posts where people have indicated:

- Whether or not your application's multiple threads will be allocated its own CPU depends on both your OS and the JVM implementation
- AND the OS can "dynamically distribute threads to different cores as they use more or less system resources"

Some quick googling reveals that it may be possible to start your application with an option for the JVM indicating that you want new threads to be allocated a new CPU (if possible), however this option is only available for systems running Solaris as the OS.


Vault101 / Mace The Game
There are 10 kinds of people in the world. Those who understand binary and those who don't.
Offline appel

JGO Wizard


Medals: 50
Projects: 4


I always win!


« Reply #16 - Posted 2006-10-01 00:51:48 »

Yes, this is a interesting topic in Java, especially since multicores are becoming the STANDARD. If Java is left handicapped, with accessability to only 1 processor, then I see a BIG PROBLEM.

Have these new multicore CPU's taken us programmers by surprise? Are we wakening up and finding ourselves asking the question "Why didn't we see this coming?". Im studying BSc (computers science) at my university now, and there is little or no mention of parallel processing, I think there should be at least a whole course dedicated to this subject.

The reason why I want to control what threads get allocated to what CPU?

Well, if I have a game that has multiple threads; 1 for game logic, 1 for physics, 1 for rendering, 1 for audio, 1 for networking etc., then I want to bind each of those threads to their own core, and no other thread will be allowed to run on that core. Also, I don't want the OS to go process-switching the threads between all the cores...there is no reason to do it. Nor do I want all these threads to be run on just the first core, or the first 2 cores, I want to say that ThreadA runs on CoreA, and ThreadB runs on CoreB...and so forth.

As PeterB said, if you create 2 threads on a duo-core system, then both of those threads get run on the same core, with all that process-switching invovled. That's the reason why you want to control what thread get assigned to which core.

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Offline appel

JGO Wizard


Medals: 50
Projects: 4


I always win!


« Reply #17 - Posted 2006-10-01 05:20:53 »

Done some more googling;

http://www.artima.com/forums/flat.jsp?forum=276&thread=170444
http://www.techworld.com/opsys/features/index.cfm?featureID=2709
http://en.wikipedia.org/wiki/Dual-core

Man, this is like that law that states (if this is a law, should be); As computers get cheaper, programming gets more expensive.

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Offline endolf

JGO Coder


Medals: 7


Current project release date: sometime in 3003


« Reply #18 - Posted 2006-10-01 13:52:40 »

Hi

Why not let the OS do this?, you have to remember, that there are other processes happening on the box besides ours. The OS knows best (or should do) how to assign the threads around, and it knows when another thread, from a different app needs some time. You can't lock everything else out. I almost never shut everything else down but the game I'm playing. Quite often I have mail client, ssh client, maybe a few web pages open aswell. These threads also need to happen. If i have 2 threads, one using 50% of a dual core system, and 1 using 25% of it, then the os knows where best to place those threads. In my app, I have no idea of the rest of the system setup.

What we need to be able to do, is get a hold of the number of cpu cores, and kick off ourselves the right number of threads. The OS should handle the rest. We need to figure out if there are only 2 cores, that we fire off 2 threads, if there are 4, we fire off 4 threads. On the other hand, it may be easier to just let the OS context switch our 4 threads on a 2 core system, it maybe less of a performance over head than any code we write to throttle back the number of threads we launch.

Writing future proof apps means being able to handle possible many more cores, this time next year we may see 16 cores or something silly (I'm no cpu expert, so don't ask me if thats realistic).

Endolf

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #19 - Posted 2006-10-01 14:41:36 »

What we need to be able to do, is get a hold of the number of cpu cores, and kick off ourselves the right number of threads. The OS should handle the rest. We need to figure out if there are only 2 cores, that we fire off 2 threads, if there are 4, we fire off 4 threads. On the other hand, it may be easier to just let the OS context switch our 4 threads on a 2 core system, it maybe less of a performance over head than any code we write to throttle back the number of threads we launch.
Totally agree. As long as a Java-thread is actually an OS-native thread then there isn't a problem (although it would be nice to know the number of hardware threads too). OS writers aren't stupid you know. The whole point of thread priorities is so that you can do stuff like this without kicking all the other running apps in the teeth because you've just grabbed all the CPU time.

The whole "allocate a whole core to do X" only really applies when you're on a console, and there aren't any other apps running.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline llama

Junior Newbie





« Reply #20 - Posted 2006-10-01 15:00:07 »

Of course Java can, and will, use more than one core. Java has been running on SMP and (many, maaaany) more systems for many years. If you have two threads that do not max out CPU usage on a single core it is downright stupid to put them on different cores or processors. Threads share memory space which would have to be synchronized between different cores or even processors if they were to run seperatly. It would take up extra L1 and L2 cache space without even being able to use this succesfully.

It's true you may miss some form of control with a JVM compared to hand coded assembly, but if you read some of the comments here Wink you see why that might not be a bad idea. Luckily, with recent versions of Sun's VM there are all kinds of clever tricks in the VM to optimize for threading, including some tricks that would be very hard to do tranparantly in C or C++ (such as thread local memory space for the exact problem described at the top of this post). Effective threading in Java, IMHO, is a lot easier than in some other languages.

It would be nice if you could discover the actual number of cores (virtual and none virtual) through Java, but I'm sure there will be some JNI libs that will support this.
Offline appel

JGO Wizard


Medals: 50
Projects: 4


I always win!


« Reply #21 - Posted 2006-10-01 19:10:12 »

Regarding this synchronization problem., isn't it possible to use something like a DoubleBuffering when it comes to the logic-update being done?

So, if you have 2 threads, one doing render() as fast as possible, and 1 doing update() as fast as possible, then there is a chance that render might retrieve information from objects (to display them) that are being updated at that moment by the update() method.
Just as DoubleBuffering is used in graphics, can't you have two buffers that contain the objects state, and when each update() is complete, the pointer to the buffer gets exchanged?

Of course, there is a risk that 1 render() takes longer time to do than 2 updates(), meaning that the buffer the render() is using will be invalid to use. Unless... if render() can say that bufferA is locked, that means the update() can only use bufferB. And when the render() is complete, then it releases the lock, and update() can now change bufferA. render() locks bufferB (which contains the newest information), and renders accordingly.

But, hm, that only solves part of the problem. When render() is complete, and wants to read from the next buffer, update() is using it. So, does render() continue to use the old buffer, or start using the incomplete buffer the update() is using?

So, does this require TRIPLE-BUFFERING? Let's say you have BufferA, BufferB, BufferC

So that update() can lock-and-secure it's own buffer, and render() can lock-and-secure it's own buffer.
That means that, when update() is complete using BufferA, and sees that render() has BufferB locked, update() locks BufferC, and released the lock on BufferA. When render() is complete, it sees that BufferA is available and fresh, and locks it, and renders from it...until BufferC becomes open.

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #22 - Posted 2006-10-01 19:25:30 »

So, if you have 2 threads, one doing render() as fast as possible, and 1 doing update() as fast as possible, then there is a chance that render might retrieve information from objects (to display them) that are being updated at that moment by the update() method.
Just as DoubleBuffering is used in graphics, can't you have two buffers that contain the objects state, and when each update() is complete, the pointer to the buffer gets exchanged?

A pointer-swap flip is only possible with graphics because the buffers get completely redrawn every time. With object state you'd have to copy the whole lot each time, which is going to be a lot of data.

Also since you'll effectivly be rendering a frame behind you'll be adding latency to your game. That may or may not be acceptable.

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline appel

JGO Wizard


Medals: 50
Projects: 4


I always win!


« Reply #23 - Posted 2006-10-01 19:37:38 »

A pointer-swap flip is only possible with graphics because the buffers get completely redrawn every time. With object state you'd have to copy the whole lot each time, which is going to be a lot of data.

Also since you'll effectivly be rendering a frame behind you'll be adding latency to your game. That may or may not be acceptable.

True. I did think of this, but no solution in my mind.

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Offline PeterB

Junior Member





« Reply #24 - Posted 2006-10-02 00:16:35 »

Quote
It would be nice if you could discover the actual number of cores (virtual and none virtual) through Java, but I'm sure there will be some JNI libs that will support this.

In my testing on an Intel Centrino Duo:

1  
2  
3  
4  
Runtime run = Runtime.getRuntime ();
System.out.println ("Available Processors: "+run.availableProcessors ());
--
Available Processors: 2


On endolf's point:
Quote
Why not let the OS do this?
I saw quite a few posts on the Java Technology forums that said this was the way to go - change the priority of your game's threads to be higher than normal and if the OS sees fit, you'll get one core per thread (e.g. 4 threads, 4 cores)
I'd like to assume it'll work this way.

Vault101 / Mace The Game
There are 10 kinds of people in the world. Those who understand binary and those who don't.
Offline appel

JGO Wizard


Medals: 50
Projects: 4


I always win!


« Reply #25 - Posted 2006-10-02 01:08:01 »

In some far distant land called Utopia, then if you had 4 cores, it would be nice that you could dedicate 3 cores to 3 threads of your game, and let the 1 core that is left to do whatever else computing that needs to be done by other applications.

core 1 - update
core 2 - render
core 3 - networking/keyinput/physics
core 4 - anything else

Instead of creating 3 threads and hoping they get run on multiple cores, but not just 1 core that context-switches them, or 2 cores. This is, IMO, too big of a question to just ignore this. I admit, I don't know much about this, haven't done any testing, so I cannot claim or state anything. I'm just worried about the unknown-factor, I don't know!

Different OS's have different algorithms regarding prioritization on threads, in regard of context-switching them. I wonder how Java VM gets around this, if it does.

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Offline darkprophet

Senior Member




Go Go Gadget Arms


« Reply #26 - Posted 2006-10-02 01:23:34 »

My advice is to try and do everything inside some sort of Runnable class; then have N worker threads that work on those runnables until the queue is flushed; on which you would render.

Also compartmentalise! And then compartmentalise some more...and multithread those dam for loops...

if you have a classic:
1  
2  
3  
4  
for (int i = 0, n = someArray.length; i < n; i++) {
  MyObject obj = someArray[i];
  ...
}


Do it like so:
1  
2  
3  
4  
5  
6  
7  
8  
for (int i = 0, n = someArray.length/2; i < n; i++) {
  MyObject obj = someArray[i];
  ...
}
for (int i = someArray.length/2, n = someArray.length; i < n; i++) {
  MyObject obj = someArray[i];
  ...
}


And put those two for loops in different runnables and send it down that nice queue for yours...Some useful situations:

a) Silhouette detection in shadow volumes
b) broad phase collison detection
c) CPU based skeletal animation on async models

and the list can go on and on; the most important thing to remember is to minimise the interactions between those runnables. For example, pathfinding would probably be a bad choice to multithread since some paths might need to go around another object if you take time and velocity of movement into consideration when calculating your paths (i.e. future collisions down the path).

Thats what I do anyways Smiley

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline Mr_Light

Senior Member




shiny.


« Reply #27 - Posted 2006-10-02 01:55:49 »

No, its not possible to do this in Java AFAIK.  You just schedule a thread & then its all up to the OS.  Thread priorities can be used however.

For example, you can't even tame the garbage collector thread to run when you want  Sad.
garbage collector is more complex then your picturing it to be

http://java.sun.com/performance/reference/whitepapers/5.0_performance.html#4.1.2
http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html
couldn't find it in 1..2..3 but I thought the GC was pluggable alltogetter these days could be confusing it with other stuff.
http://www.nljug.org/pages/events/content/jspring_2006/sessions/00021/
was a session I attended earlier this year wasn't really related to why I was there but it was interesting to watch although Real time and games aren't really one on one, glitches though GC doing its job is something that ppl want to avoind in Realtime apps and in games.

that was kinda (really) offtopic.

anyways,
I don't know to what extra use the knowlage of the amount of logical processors will do. the meganism that would be able to optimise against those x cores could probebly be made gentric  adding some meta data to your thread if such a optimilisation would be effective at all. (that and some other if's)

It's harder to read code than to write it. - it's even harder to write readable code.

The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
Offline fletchergames

Senior Member





« Reply #28 - Posted 2006-10-02 04:23:17 »

What is the point of having more than 2 cores?

Having 2 cores enables you to have all your background stuff running on one core and whatever your main application is on the other.  That's useful.  Having more than that seems like a waste.  What if I'm running one really computation-intensive thread?  Then all the cores but 1 are wasted.

I would much rather have a 4 ghz processor than a processor with 4 1 ghz cores.  A processor with 2 2 ghz cores would be all right though.
Offline appel

JGO Wizard


Medals: 50
Projects: 4


I always win!


« Reply #29 - Posted 2006-10-02 04:49:44 »

What is the point of having more than 2 cores?

Having 2 cores enables you to have all your background stuff running on one core and whatever your main application is on the other.  That's useful.  Having more than that seems like a waste.  What if I'm running one really computation-intensive thread?  Then all the cores but 1 are wasted.

I would much rather have a 4 ghz processor than a processor with 4 1 ghz cores.  A processor with 2 2 ghz cores would be all right though.

Appearently, the Intel folks don't agree with you Smiley They're betting all their money on multicore systems. Unicore systems are, as of the year 2006, appearently a thing of the past. It's a lot easier to sell a machine to customers that is multicore than unicore; "You're getting 4x the product compared to that 1x old product."
Besides, 4ghz seems to be the top-speed they're able to get the CPUs to run at.

I guess we, programmers, need to change. We need to learn to analyze our problems in more ways now, being able to split it into more independent units that can be run parallel.



Does Java not provide any method to retrieve some information about the computers hardware? Like; video card, cpu load, etc. ?

Check out the 4K competition @ www.java4k.com
Check out GAMADU (my own site) @ http://gamadu.com/
Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

pw (37 views)
2014-07-24 01:59:36

Riven (38 views)
2014-07-23 21:16:32

Riven (26 views)
2014-07-23 21:07:15

Riven (28 views)
2014-07-23 20:56:16

ctomni231 (59 views)
2014-07-18 06:55:21

Zero Volt (50 views)
2014-07-17 23:47:54

danieldean (42 views)
2014-07-17 23:41:23

MustardPeter (44 views)
2014-07-16 23:30:00

Cero (60 views)
2014-07-16 00:42:17

Riven (57 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!