OK, I replaced the download with a new version.

This version contains a new argument:

-threads [n]

This lets you override the number of threads that will be used. This will let you do things like only tie up 3 of your 4 cores. Or try twice as many threads and see if it makes any difference. 

 

Har!

And for those interested, the source code:

http://www.quaketastic.com/upload/files/tools/windows/misc/WVis_Src.zip

This is pretty messy and includes a bunch of files not related to WVis but this was just a quick and dirty project anyway. "vis.sln" is the Microsoft solution file that I was using to build from. Most of the grunt work is in "vis.c". 

aguirRe's VIS does save after each portal I think. So you could simply make a backup of the files and play around.

I want an i7 so badly. :] 

only has 2 cores!

What kind of processor do you have, Negke?

You see if yesterday the estimated elapsed time was only 28%, I would guess (at the speed he was going) that it would still only read like 30 or something, so if you think that it will only get slower, if he started again now going at twice the speed, there is enough remaining time for it to still end sooner with two cores then to keep going from this point with 1......

(gasp!) 

OK, so I messed around a little on this 8 core machine.

"Evil Exhumed"

1 thread - 14 minutes
2 threads - 7 minutes
3 threads - 5 minutes
4 threads - 4 minutes
5 threads - 3 minutes
6 threads - 2 minutes
7 threads - 2 minutes
8 threads - 2 minutes

Nice! There are obviously some rounding issues here in the time calculations provided by the VIS tool, but there is definitely a point of diminishing returns... 

nicec work Willem

petty that i just have a AMD 3200 :\

I might try this in a near future :) 2015 maby. 

dunno if this is indicative of anything, as it wasn't an explicit test, but WVis was able to recognize a bsp file had already had it's Base Vis calculated from a prior run through with Vis's original .vis file.

you could just try copying the .bsp file and .vis file to a new location and try to run with WVis without interrupting the original's process. just set priority to low while you test.

also, you can set thread priority in aguire's (and WVis) with -priority. 0 = below average, 1 = average, 2 = above average. if you are concerned about bogging down your system. 

Thanks for the source.

I'll enable this in Linux bjptools, too, unless someone else does it first. Although I reckon it's done a little differently in *nix.

The base is already there. 

It probably is. You might want to grab the source code for the Mac version of the tools instead and use that as a reference. It's much closer to *nix than this Windows version will be.

I've lost the link for that source code and I don't have access to my FTP from work ... I'll try to remember to post the link though. I'll just post a new archive to Quaketastic when I get a chance.

The Windows stuff is fairly far removed. 

Anyone tried it with wine ? 

Is Wine taking profit from CPUs as windows does? I mean: as Windows uses all the available CPU cores (4 for a Quad, 2 for a Dual), is Wine having the same ability to take profit of the multiple CPU core from a Unix/Linux system (e.g Sparc processor, etc...)? 

 

wine 1.1.26
threads 2

Full: 72.03%, Elapsed: 1h 9m, Left: 1h 58m, Total: 3h 8m, 37%

CPU usage 90% 

top shows every cpu you have as 100% I think. So if you have a quad, that would be 400% overall. I have 2 cpus and top goes over 100% sometimes for me. 

Anyone want to make vis use MPI (Message Passing Interface)? I can run it on a 100+ node cluster if y'all want. This would also pave the way for people to cooperatively use vis over the internets -- are we communists yet?

What's the the speedup per additional processor? 

I mean, more than just one data point (thanks Willem!). A run that with one processor takes an hour, is better than one that is already short & reasonable (e.g. Evil Exhumed). 

How complicated is it to make a distributed app like that? Seems like an undertaking... 

 

Just put in the MPI hooks in the source, and compile against the MPI libs. 

I'm not familiar with how any of that works at the moment ... so if I add the hooks to VIS this will all work magically? Doesn't there need to be something running on a server somewhere? 

If you know how to split up the map into independent parts, you could apply the map reduce paradigm to the vis problem.

Re: MPI inclusion: magic doesn't exist. 

So you're one of the ones (like me) who just thought that the little girl in Pan's Labyrinth was schizophrenic? 

I disagree about magic. 

Yesterday I defined "faith" for a buddy:

Faith: Belief in irrational hypotheses.