Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Baughn]

To answer the original question:  Dwarf Fortress uses all 4 of my cores.  I can run maps that would make other people cry, scream, and tear their hair out - without using the new OpenGL version of DF (it does nothing for me).  People seem to forget that CPU's are made to distribute single-thread application over multiple cores.  In fairness I should say that a program may not run any faster using multiple cores depending on the overhead of distributing it.

Uses all four cores? Oh, really?

What you're talking about is hyperthreading (er.. they may have changed the name, but same thing), where multiple cores can borrow execution units from each other. That does make them faster, but not nearly as much as explicit multithreading.

Anyhow, it's only really working in the i7; the Core 2 cores are still almost entirely separate. That's a good part of why the i7 is perceived as so much faster than the C2.. well, it's a pretty good idea.

Let me assure you all, there is no need to make DF multi-threaded.  It's a simple matter of implementing more efficient algorithms for the most used functions.

Agreed. Pathfinding, mostly.

[Shoku]

Can we get a battlechamps with the pathfinding instead of the graphics soon? *puppydog eyes*

[Michael]

No, multithreading is easy, just not with the typical, imperative style of programming.

Functional programming can be a great help.  However, to gain the safety benefits, you need to use a hardcore language where anything imperative is banned, rather than a more fun functional language like Scheme that lets you lapse into imperative style when you really want to.

And there are still optimization issues.  Consider the following pseudocode for the main loop of a DF-style game.  The pseudocode looks like C++, but it is authentically functional since each variable is only assigned once.

Code: [Select]

generate_next_frame(frame old_frame)
{
    tempdata temperature_data = calc_temperature(old_frame);
    pathdata pathing_data = calc_pathing(old_frame);

    frame f1 = freeze_and_burn_stuff(old_frame,temperature_data);
    frame f2 = move_monsters(f1,pathing_data);

    generate_next_frame(f2);
}

That code would work well on a single core system.  Now consider the following:

Code: [Select]

generate_next_frame(frame old_frame, tempdata old_temp, pathdata old_path)
{
    tempdata temperature_data = calc_temperature(old_frame);
    pathdata pathing_data = calc_pathing(old_frame);

    frame f1 = freeze_and_burn_stuff(old_frame,old_temp);
    frame f2 = move_monsters(f2,old_path);

    generate_next_frame(f2,temperature_data,pathing_data);
}

On a single core system, the second code represents a significant pessimization.  It wastes memory, since old temperature and pathing data is not discarded as soon as in the first code.  It's also less "correct" than the first, since pathing and temperature information will be "stale" by one frame when it is used.

But it will be much faster on a multicore, because by using slightly-stale temperature and pathing, it can run the movement and burnfreeze passes simultaneously with the generation of the current temperature and pathing information which will be used next frame.  Basically, it creates a pipeline system.