Multicore capable ModManagers do they exist

[luinil]

I use OBMM and FOMM

 

I find OBMM is a bit of a pain to use update texture and BSA archive with BSA alternation , its a bit slow.But this is probably just oblivion.

 

FOMM archive invalidation is well almost instantaneous

 

CPU cycle wastage

----------------

 

However even when uncompressing /compressing huge files to create /install FOOMODs or OOMODs (1-2G compressed) both mod managers only use 1 of my 4 cores so typically 73 percent of CPU capability is unused.Surely more CPU cycle would speed things up.

 

Memory Under utilization

-----------------------

 

Typically my machines uses about 780M with no apps running and since I have the large address flag set for win32 bit , window theoretically could give and application up to 3G.Well infact I know with some apps in tries cause after a long playing section my Oblivon will sometimes CTD and if I look in Task Manager the total RAM free is sometimes like 30 Meg.

 

Often OBMM/FOMM seem to only give 400 MB to the OBMM/FOMM leaving -2.6 G of memory underutilized

 

 

Now I do not know the technical details about 7z , FMOD,OMOD compression BUT I bet they would run better and faster if they had more memory and cpu cycles they could use.

 

Infact once I simultaneously had both FOMM AND OBMM each installing big mods and it did not cause a problem.Now I only did this once so I dont suggest you take this as evidence of anything definitive as its too small a sample space to make a judgement.

 

 

So are they any ModManagers that use 2 or more cores? and you can give em a decent amount of memory ?

[Bialge]

Disk speed is a much more probable bottleneck when file compression is the issue. I'd say invest in a solid state drive (if you don't have one already).

 

As far as your query I'm not aware of any, no.

[Thorham]

Disk speed is a much more probable bottleneck when file compression is the issue. I'd say invest in a solid state drive (if you don't have one already).

Cpu speed is the main bottleneck in file compression and a faster drive won't speed this up much at all, if any.

[Bialge]

Disk speed is a much more probable bottleneck when file compression is the issue. I'd say invest in a solid state drive (if you don't have one already).

Cpu speed is the main bottleneck in file compression and a faster drive won't speed this up much at all' date=' if any.

[/quote']

 

Really? I've got my facts wrong, then, sorry.

[Thorham]

Really? I've got my facts wrong' date=' then, sorry.[/quote']

Compression is much slower than disk access. The faster the drive, the bigger the difference becomes, especially when the compression software only uses one core, which apparently is the case here.

[luinil]

Disk speed is a much more probable bottleneck when file compression is the issue. I'd say invest in a solid state drive (if you don't have one already).

Cpu speed is the main bottleneck in file compression and a faster drive won't speed this up much at all' date=' if any.

[/quote']

 

Hmm that make sense after all it take a hell of a lot less time to copy a OMOD to the obliv../data dir that to create it suggesting that the cpu is the bottleneck

[deathparade]

Well my HDD is quite old and only holds 320 GB but my CPU is 3,3GHz...

Still slow... same goes for 7-zip

[Tefnacht]

It is a very common misconception that software not using all the available cores is “inefficient” or “wasteful”. That's simply not true. Many (I dare say even most) solutions to a computing problem cannot be split into multiple threads running parallel. Data compression is actually a good example of this dilemma.

 

There are countless methods of data compression and many different approaches to the problem. All those solutions differ mostly in two categories: Speed and efficiency. Those two are almost mutually exclusive. If you want great speed, the compression won't be very good. If you want efficient compression, it will not be very fast. That sounds very plausible even to the laymen, doesn't it?

 

One of the most efficient methods I know about: LZMA compression (the one employed by 7Zip) is a streaming, bottom-up method. This means that every byte of data processed by the algorithm changes the compression model for the next byte.

In other words: Byte five cannot be compressed until the bytes one, two, three and four have been done. This method cannot benefit from multiple cores at all. If I have 600 Mb to compress, get the first core started on it and send the second one ahead to work on the second half, the second core could not do anything until the first core catches up and finished the first 300 Mb ... making the whole multi-core idea completely pointless.

 

On the other hand, there is (for example) PBZip2 which “simply” chops the data into chunks and then BZip2 compresses those chunks independently on all the available cores at once. This method becomes faster almost linearly the more cores you throw at it. On a eight core machine it can compress the same amount of data in a fraction of the time it takes LZMA ... however, LZMA will do a much better job because it created a much better dictionary and has considerably less overhead.

 

There is also LZMA2 which can actually use two cores ... however, the work done on the second core is disregarded and thrown away most of the time. Utilizing a third core would just waste energy and occupy resources. LZMA2 compresses the data in interdependent chunks but might actually keep the occasional uncompressed chunk if it turns out to be smaller than the compressed one (this happens a lot with files that are already efficiently compressed like MP4 video or OGG audio). LZMA2 simply has no use for more than two cores.

 

Bah, listen to me: Prattle, prattle, prattle. I am sorry.

 

I don't know about any multi-core using mod manager. Worse, I don't see how multiple cores could actually be a benefit for such a program. However, if “speed” is your dominant criteria you might want to check FOMM's settings and change the compression level in the “FOMod Options” tab from “Ultra” to “Low”, “Fast” or even “None”.

 

You'll waste a lot of disk space but the overall process should be a lot faster.

[luinil]

 

 

 

I don't know about any multi-core using mod manager. Worse' date=' I don't see how multiple cores could actually be a benefit for such a program. However, if “speed” is your dominant criteria you might want to check FOMM's settings and change the compression level in the “FOMod Options” tab from “Ultra” to “Low”, “Fast” or even “None”.

 

You'll waste a lot of disk space but the overall process should be a lot faster.

[/quote']

 

Would using lower compression setting effect the performance of you game?As i think my o-mods and fmods use ultra settings.

[Tefnacht]

No. The compression used by the mod manager to archive mods does not influence the games actual performance at all. The one has nothing to do with the other.

 

If you activate a F/OMOD through the mod manager, it decompresses and moves the files contained in that archive to their respective location within the games folder structure. The game itself is not aware of; and does not interact with; the managers F/OMOD archives at all. However, it will work with the “loose” files you tell the manager to deposit in its data folder ...

 

Choosing a lower compression for your F/OMOD files just wastes disk space in favor of speed of the manager program doing its job. A texture mod of 400 Mb could be stored in a 100 Mb OMOD using “ultra” compression but it'll take five minutes to de/compress. Set compression to “fast” and the process only takes one minute but you'll end up with a 270 Mb OMOD instead.

 

The F/OMOD compression level just dictates how fast/efficient your mod managers data storage works. The game itself only reads from its own BSA archives, overriding their content with loose files.