Java-Gaming.org Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (524)
Games in Android Showcase (127)
games submitted by our members
Games in WIP (592)
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 6790 times)
0 Members and 1 Guest are viewing this topic.
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #30 - Posted 2006-10-02 05:39:29 »

dedicating a core to do a single type of work is basically bad design - and I am pretty sure that alan wake doesn't do that either, despite the presentation. They're more likely dedicating a thread and let the OS decide the core its running on.

The only reason to let a thread only run on one core (setting affinity) is that you want to avoid core switches, which might incur a high cost (relatively). However scheduling a thread on 1 core, might mean that some of the integer or floating point operations stall becase the single core isn't fast enough.

Online princec

« JGO Spiffy Duke »


Medals: 422
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #31 - Posted 2006-10-02 09:50:08 »

If I ever get near maxing out a CPU with game logic I'll be sure to investigate the horrible complexities of multicore game programming Smiley Until then it's all just pipe dreams!

Cas Smiley

Offline Mr_Light

Senior Devvie


Medals: 1


shiny.


« Reply #32 - Posted 2006-10-02 10:17:53 »

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.
ghz or better: frequency goes up the power consumption goes up exponantially, multicore allows for more performace while keeping the power consumption descrete. now you might be like I don't care too much about my power bill but the heat that comes with it also has to be moved hence the huge fans you see today. offcourse performance wise there is also the whole how-much-gets-done-in-a-clockcycle bit.

multicore scales better then ghz's

I don't really deal with hardware this is all 2nd hand but I think it's pritty accurate.

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.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 833
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #33 - Posted 2006-10-02 12:20:16 »

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.

Say you're doing collision-detection, (not collision-response), in really complex and high-tri-count scenes. Why limit yourself to 1 thread handling the game-logic, when you have 4 available. There is so much to gain, with so little effort, it would be a waste not to take advantage of it.

We all rather have 64GHz cores, just like we'd rather have flying cars and holographics harddisks, but hey, it's not going to happen anytime soon, so lets enjoy the 32x 2GHz, AI controlled cars and hybrid harddisks for a while Wink

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline uj

Junior Devvie





« Reply #34 - Posted 2006-10-04 19:59:45 »

I'm wondering what the difference is for the normal programmer?
tions?
Basically any Java program will be able to run faster on a multi-core processor. (If they actually will is a question of how well implemented the JVM is to take advantage of the CPU cores). This is because in Java concurrency is inherent. Some of Java's appearant slowlyness is because it has made use of concurrency which hasn't been well executed on a single-core processor. But once multi-core is in place the obstacle is removed and many programs will run much faster.

So in summary multicore is good for Java. It's good even if you don't do anything, but it's even better if you adapt for concurrency. Any programmer interested in this should buy a copy of Java Concurrency in Practice by Brian Goetz and others. It's already a classic.
Offline appel

JGO Wizard


Medals: 51
Projects: 4


I always win!


« Reply #35 - Posted 2006-10-04 23:58:28 »

Ok, I agree, maybe it's time to read a book on this subject before babbling more.

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

Senior Newbie




Life > Games > All


« Reply #36 - Posted 2006-10-06 06:16:32 »

Just because you can run something broken up across multiple threads doesn't always mean its a good idea, or even faster. In fact, a lot of basic things are a lot slower when broken out to be parallel, and a lot of parallel things can run slower then just a linear approach at times, sorts are famous for this.

Yes, in general multiple cores are great for Java, and yes java supports it pretty well. But just becareful on your design and learn how to deal with multithreading & concurrency before going nuts trying to use it all over the place. Bad things can happen. Smiley

Jeff Olson
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 833
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #37 - Posted 2006-10-06 12:20:26 »

Why would sorting the same data on 2 threads be bad? First you do a rough sort, dividing your dataset in low/high, and then process the 2 segments on 2 threads.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #38 - Posted 2006-10-06 12:45:51 »

Or you could use merge sort, which is basically the same idea and can be massively parallel.

Unfortunately for most uses the overhead of thread creation and context switching is likely to eat up any gain you'd get (and possibly more).

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

Senior Devvie





« Reply #39 - Posted 2006-10-06 13:54:30 »

Tim Sweeney of Unreal fame did a pretty interesting presentation about the whole multithreaded game engine issue, separating the engine into sections of increasing inherent parallelism (Simulation, Numeric computation (e.g. physics), and Shading (rendering)) and suggesting how to do each in parallel with reasonable speedup. I was especially intrigued by the atomic threading primitive, which would replace regular and hard-to-get-right locking primitives in game logic code.

 - elias

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Riven
« League of Dukes »

« JGO Overlord »


Medals: 833
Projects: 4
Exp: 16 years


Hand over your head.


« Reply #40 - Posted 2006-10-06 15:12:08 »

ofcourse you're not going to create threads for the sorting, you already have a bunch of worker-threads laying around Smiley

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings
Offline Jamison

Junior Devvie




We're all idiots in one way or another.


« Reply #41 - Posted 2006-10-06 15:27:09 »

My thoughts are as follows: if you have the ability to allow two or more threads to control your game (update/render), go for it. But let the OS decide which thread runs on which core. However, if you can't control which thread goes on which core, then a problem arises. If the OS asigns both threads to the same core, they won't run simultaneously. Say this is the OS's thread queue, in which case the OS assigns each thread to a differant core:
CORE 1:
   Process 1
   Process 2
   Process 3
   Process 4
   Process 5 (Your game's UPDATE thread)
   Process 6
   Process 7
   Process 8

CORE 2:
   Process 1
   Process 2
   Process 3
   Process 4
   Process 5
   Process 6
   Process 7 (Your game's RENDER thread)
   Process 8

This would be great, however, if the OS assigns your threads to the same core, it would be like your game is running on a single core system, each thread would have to wait for the process ahead of it to finish, and would have to wait for your other thread to finish. Here's how the OS's thread queue might look in that situation:
   Process 1
   Process 2 (Your game's RENDER thread)
   Process 3
   Process 4
   Process 5
   Process 6
   Process 7 (Your game's UPDATE thread)
   Process 8

My point here is, if you can't control which thread goes on which core, just use a single-thread game, or it may run slower if your threads are running on the same core (or even 3 are on one core, and 1 on the other, etc).

Take the Xbox 360, they have "3 symmetrical cores running at 3.2 GHz each" and "2 hardware threads per core; 6 hardware threads total" (source: http://hardware.teamxbox.com/articles/xbox/1144/The-Xbox-360-System-Specifications/p1). This means they can run 6 threads sumultaneously, however, it's using custom hardware, and the hardware is dedicated specifically to the game. So the 360 obviously makes use of these 6 threads running at the same time. I bet the 360 has the ability to choose which thread goes on which core, or the 360 automaticly assigns each new thread to a core which does not already have a thread running, meaning it cannot allocate more than 6 threads. Note that this is only my guess, I have NOT confirmed this.

I don't like you. Check out my site Smiley www.gamedevforums.com
Offline darkprophet

Senior Devvie




Go Go Gadget Arms


« Reply #42 - Posted 2006-10-06 16:29:45 »

elias, i seem to remember reading that, but I can't find it. Would you mind linking me please ?

DP

Friends don't let friends make MMORPGs.

Blog | Volatile-Engine
Offline Mr_Light

Senior Devvie


Medals: 1


shiny.


« Reply #43 - Posted 2006-10-07 15:02:35 »

sorry to burst your bubble but with any semi intelligent thread assigner would prefend the situation that you describe from arrising. obviously that render and update thread will take a significant amount of a bite out of the core/cpu resources and figure out on it's own that it would be better to assign it to separate cpu if it can't figure it out its probebly not nessasery. If theres an other program bound to the other cpu already and stresses it it will be more efficient to have it all run on one core. Perhaps some hint's that one thread should be or not on the same core/cpu would allow for quicker discovery or could render optimalisation towards memory share or what not but that all is still a whole differend approuch from tieing it to one cpu.

the same issues that arise from your approach are quite similair to the problem arised with hardcoded memory spaces and multi programs and the resulting conflicts.


//edit
xbox..  console games/programms can pull this off because they are actually aware of everything going on, on the machine pc/computerprograms are not and should gracefully share/claim resouces. This also includes cores.

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.
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.

toopeicgaming1999 (54 views)
2014-11-26 15:22:04

toopeicgaming1999 (47 views)
2014-11-26 15:20:36

toopeicgaming1999 (8 views)
2014-11-26 15:20:08

SHC (24 views)
2014-11-25 12:00:59

SHC (24 views)
2014-11-25 11:53:45

Norakomi (26 views)
2014-11-25 11:26:43

Gibbo3771 (23 views)
2014-11-24 19:59:16

trollwarrior1 (36 views)
2014-11-22 12:13:56

xFryIx (75 views)
2014-11-13 12:34:49

digdugdiggy (52 views)
2014-11-12 21:11:50
Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06
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!