BladeRyo wrote...
...
THAT CANT REQUIRE A DUAL CORE, this is some minor/major screwup that should be easy to fix.
--=> ReadME.txt <=--Sit down grab a drink, and read the following carefuly. It will make your life easier, and give you some insight into how the computer works. As much as I want to hunt the Dev crew down and inflict some unspeakable torment on them for causing me so much stress, I should point a few things out in their defense!
First, there're nothing all
that easy about programming for a multi-core processer. The very basics you need to know first.
--=> The basic of multi tasking <=--I'm going to talk about two forms of processing. The first is multi tasking, and anyone that was around for DOS screamed '
Hallulla' when it came around! When processing started out a computer could run one and only one program at a time. For my explination that means your where running windows -OR- Mass Effect. Running one excluded running the other. Never both. If you wanted to switch, you had to shut one down, and continue with the other.
Multi tasking allows a CPU to run one program "for a few cycles", pause, then run the other program "for a few cycles". So it
appears to be running both at the same time, but no such thing is happening. Each and every program is run in turn, in it's turn, according to the OS's direction. In reality, no two programs are running at the same time!!
In the last few years multi-core processers have come along. One might think something logical and assume all processing cores are in use at the same time working in symphony to run a single program.
This is incorrect! The resouces required to run a program can not be shared.
A single program must be run on a single core, there is no way around this! There are two advanrages to having a multi-core processer. The first, is that a OS can delgate some tasks to seprate processing cores; However, each task is still confined to running on the core it's running on and only that core. Even then, that can only be done if the OS is properly designed.
Which is the second way to delegate, Multi-threading. Without multi-threading, a mutli-core CPU is essiantly a brick that costs more money! Without multi-threading
NO program on can use more then one CPU core, and multi-core CPUs become useless!
--=> Multi-Threading <=--Remeber how I said each program can run on one and only one CPU core, with no way around that? This is still true. However, some programs
, very few in fact, can however work around this. A program can
request(not demand, require, or be guaranteed to recieve) what's called a "thread". A thread is a smaller linked program that is delegated tasks from a main program. Each being a descrete program in it's own right, each can be assigned it's own processer. It would be as if a general that was order to defend his country ordered his lieutenants to carry out the logistics and smaller parts. The general manages the war, and his lieutenants handle the side tasks.
This is multi-threading.
However, just because a program is multi-threaded, does not mean that it is threaded among more then one CPU. A program merely requests a additional register entry. Which means the CPU, the chip inside your case, merely has one more thing on it's "to-do list". How it accomplish it is
well well well beyond the perview of a mere program or programmer. The hard-ware is not obligated to grant access to additional resources. It can, at it's discresion, simply "multi-task" the program. Much in the same way running your internet browser and a text program would at the same time on a single core processer would.
(Which incedently is why I think the "requirement" for a dual core is total BS). At most, the speed requirement for a single core is increased.
--=> A Few Problems With Multi-Thread For The Unlearned <=--Ok, so you have a program that's multi-thread. Exelent! Good work! You may number your self among the few programmers that can handle some of the more complicated idoems among programming. (Which sadly, isn't that many people, as some of the more common programming languages stopped growing and are being dumbed down for the masses. I'm looking at you, C#)
So, with the (self) praise out of the way, Multi-Thread is not yet the promised land. There are a few issues. Good work, small issue though. Remeber how no one program can run across more then one CPU, and each program is it's own indiviual program? There are a more then a few problems that can crop up if you get too carried away to pay extra attention to the code!
Problem 1:Say you have a program, and you assign the audio and video seprate threads. So, you now have three programs running, spread among the CPUs: The core game, the video, and audio. What happens if the core game wants to finish the level and start the AI up for the next level shooting the player, but the thread for video is still "stuck in a loading screen"?
Problem 2:What happens when you need to count up the EXP you just got for killing the big boss (+1,000,000)and looking good while doing (+100,000) is split between two threads? Lets say the current EXP is 300,000. Each one requests the current EXP and sets it to the new value. What if ,each one being it's own program, can request then add the relavent EXP at the same time. The problem is in the "request"
and then "add". What happens if both threads read the current EXP as 300,000
before the other finishes? You end up with 400,000 or 1,300,000. Not 1,400,000.
Problem 3:What happens if one thread runs into a catastrophic error? The OS is going to shut that thread down; However, being it's own program in it's own unique space, the program that spawned the thread, if it's not the one that crashed, has not direct means of knowing this. It's either going to keep running and the "game" as it were is effectively only half present. If it delegated a task to that thread so another CPU core could be working on that, while it work on something else? Without a means to correct or even detect the problem, the programs is also at best is only half present anymore. At worst both cases can be damaging.
(Incendently, I think this is what Mass Effect is doing, and got sloppy doing it. One thread has crashed when running into a unexpected codec error, and the others are asleep having finshed their work and waiting for the crashed thread to finish (unlock what's called a semaphore).I do not think this a hard-ware issue. I think Bio-Ware got sloppy, the program hasn't errored out as it should because this maybe this is their first run with multi-threading. I'm thinking the game stalls at the loading screen without crashing because the OS still detects a viable thread, doesn't know the other threads shouldn't have done what they did, and the main loop doesn't know any better.)--=> Summary <=--There are few more problems with multi-threads that you have to be extra careful for above and beyond the care that must be showed to normal programing, but I hope that helps give some empathy and understanding.
Heres hoping for a patch soon.
Modifié par LuminousLupine, 01 février 2010 - 05:36 .
Ce sujet est fermé
Retour en haut
)
