GearGOD

Game maker is built to only run on a single thread. This means that at most, a game or application will be using 100% of a single cpu - in your case one of eight. There's no simple way around this. In fact, the easiest way to deal with this is to write the server in a language that has good support for threading.

Actually there is a way to work around it, since you can use a multi-threaded dll (Theres already one for GM).

So you can execute a for loop in a different thread so the rest of the game isn't paused or freezed while the for loop is running.

I didn't say there's no way around the single thread limitation, I said there's no simple way. There is indeed a dll for threading which may or may not work with the latest version, and definitely won't work outside of windows. And you can indeed put a blocking loop outside the main thread with it. So what? If you ever try to use it for anything less trivial than doing IO, you will very quickly find that things explode. You want to separate step and draw events? Nope, can't do that without complex synchronisation. You want to step multiple objects at the same time on different threads? Nope, can't do that without even more complex synchronisation. You want to put some step code in a separate thread? Nope, have to wait for that call to finish before continuing with processing other objects or things will explode.

Gmthreads doesn't give you any tools to deal with these problems; which brings us back to my original point. The easiest way to do what OP wants is to write the server in a language that is actually designed with these problems in mind, rather than trying to use an unmaintained dll that uses undocumented behaviour to provide limited functionality useful in a small number of cases.

Game maker is built to only run on a single thread. This means that at most, a game or application will be using 100% of a single cpu - in your case one of eight. There's no simple way around this. In fact, the easiest way to deal with this is to write the server in a language that has good support for threading.

This is actually quite doable.

Launch said application
Find its window handle
SetParent that window to the game maker window
Change the application window's border style to none

I'm pretty sure I've seen DLLs around that can do both of these things. Having said that, its a pretty bad idea and I would rethink it.

I can tell you why its slow, but I don't think I can suggest any ways around it.

1: Pulling data from the video card memory is slow. Video cards are designed to get data from the rest of the computer very quickly, not so much to push it in the opposite direction.
2: Pulling data stalls the pipeline. Both game maker (I hope) and the graphics driver batch drawing operations together because its cheaper. As soon as you ask for data to be pulled back, all pending drawing operations must happen immediately, then the data sent. While this is happening your code just sits and waits. This is where most of the speed cost is incurred.
3: The biggest problem: GM only allows you to fetch a pixel at a time. For every single pixel you ask, the pipeline is completely stalled. Lower level game engines allow you to request the entire backbuffer or a portion of it to be pulled to system memory in a single operation - only one pipeline flush per surface per frame.

Why was it faster with whatever javascript thing you were doing before? Because in all likelyhood it wasn't rendering over d3d/opengl and was storing raw pixels in system memory. Reading that obviously costs almost nothing.
What can you do about it? I'm afraid the only answer is don't do it.

I've asked around, JS perf is still pretty shocking on ios 5 beta. I'd say they don't have much incentive to improve it: its sufficient for the vast majority of websites, and as far as apps go, Apple prefers they be native.