Indeed. The big killer is the single threaded architecture of the game.
Lower power processors usually achieve this by doing less complicated instructions, but more of them. An analogy, is treating multiplication like addition. 36 x 110, is 110, 36 times. (And vise versa.) So, to get the answer, you can either multiply them with a single big and complex floating point op, or you can do it with 36 additions of 110, in a sequence, against a register on the cpu as the accumulator. Both get the same answer. Addition is computationally easy. Floating point arithmetic is much more costly in terms of circuits needed, and thus of power required for operation. (The same is true for division, with stacked subtractions, and an accumulator. Eg, 64 ÷ 8 can be computed by counting how many times you can subtract 8 from a starting sum of 64, before reaching zero or a value less than 8. In this case, 8 times exactly. Dealing with fractional remainders is going to require a lot of added cycles if you want a decimal value, and not simple modulo division.
).
If your program is single threaded, then the whole rest of the program can be sitting around twiddling its little thumbs while the CPU adds 110 to the accumulator 36 times, to get the product of 110 x 36. So, while the chip may run at 2.5ghz, same as the beefier, more power hungry desktop cpu, the desktop cpu clears more total operations per clock cycle, and "runs significantly faster." In the case of this fictional scenario, up to 36 times faster.
A 2.5ghz atom is much weaker (time wise) than a 2.5ghz i5, even when the extra cores of the i5 are turned off.
Both are x86 chips, produced by intel. They accomplish the processing of each instruction radically differently inside, based on their intended home inside a device.
This would change significantly if the program was multithreaded, and could make effective use of multiple cores, since then the game could continue some of its processing on a different core, while waiting for the additive multiplication routine to finish on the first core, as long as one did not rely on the other's result. (Running temp calcs and fluid flow calcs on different cores, for instance.)
Making a well behaved multithread application is a pain in the @$s, especally when the logic you already have is single threaded, and large/complex. Toady started DF in an age before ubiquitous multiprocessing. The game's architectural design is not friendly to parallelism in execution, and as such, the game will simply run poorly on a gutless wonder of a CPU, unless that CPU does proportionally more clock cycles per second than does the desktop cpu. (In the case of the additive multiplication instruction fairy tale, the cpu would need to be going 72ghz to keep up with the 2ghz i5, doing the floating point on a single clock cycle.)
That's essentially why tablet processors are wusses compared to desktop big iron, even at the same clockspeed. The big iron can use more complicated circuitry, that draws more power, to do more complicated computations, in fewer cycles.
A *REAL* neat trick though, would be for Atom processors to leverage the GPU built in die to do vectorialized math ops, when the gpu silicon is otherwise sitting idle, and the cpu has complex mat to do. This would let the cpu do 2 things at once.
That's essentially what hyperthreading did, but HT doesn't help single thread applications. This would be more a part of branch prediction, and processor pre-emption, using instruction cache contents to predict when such utlization could be accomplished.
More complicated, but I could see it really speeding up Atom in certain conditions.
As for android... you DO know that android works on x86 devices, and it might be possible to have a dual booting tablet, right?
Author
Topic: DF on an Intel Atom? (Read 3131 times)