Accelerate the atmospheric spread

[Plotron]

Jey, I think that in order to move this forward you should contact the creator of LINDA.

[Shadeykins]

 

I'm just going to put this in here.

 

Parity for the sake of parity is stupid.

 

Parity is sometimes not even a good thing.

 

We're different servers, and as LINDA is open source one should be free to work on it, make tweaks and modifications and further enhance it without ever encountering the "you can't do this because we want to maintain parity" argument.

 

If parity means the halting of progress and any and all implementations of cost-savings or functionality, I'm against parity.

 

We're not TG, so why do we ever even remotely want parity with TG?

 

The idea behind open source is that you build up on the ideas of a collective group of existing datum, not halt progress entirely for the sake of homogeneity - which isn't even relevant since TG is a different server that operates in a VERY different way.

 

Unless we're somehow bound by an agreement with TG that we can't modify LINDA (which makes me wonder why it was ever implemented, as we're no longer opensource then and another server has control over our content), parity should never be brought up.

 

I have never understood why you constantly bring up the parity argument, Fox, and I would love an explanation because I see a thousand negatives and no realistic advantage - as we're opensource we can incorporate any advancements made by TG whilst providing our own (not parity), rather than just waiting on TG to do things whilst we twiddle our thumbs. (parity)

 

[alexpkeaton]

 

Fox has provided enough explanation here. Too bad you don't accept it.

 

Enough coder-bashing. This is shameful and unbecoming of members of the Paradise community. If you must have a server your way, run your own. Otherwise you won't get everything you want. Ultimately, we can't customize everything, we have to rely on other good code and the maintenance made to that code by those devs.

 

This thread was resolved 30 posts ago. It's been whining ever since.

 

Locking this thread does a favor for our hard-working coders and common sense.

 

[Plotron]

 

Parity for the sake of parity is stupid.

 

We maintain parity so that it's easier to port things from bigger codebases, including fixes, maintenance patches and features.

 

LINDA is a huge chunk of code not written by us. It's therefore wise to keep it as similar to the other codebase as possible, so we won't end up with an obsolete system at the end of a one-way road.

 

[Dinarzad]

 

Fox has provided enough explanation here. Too bad you don't accept it.

 

Enough coder-bashing. This is shameful and unbecoming of members of the Paradise community. If you must have a server your way, run your own. Otherwise you won't get everything you want. Ultimately, we can't customize everything, we have to rely on other good code and the maintenance made to that code by those devs.

 

This thread was resolved 30 posts ago. It's been whining ever since.

 

Locking this thread does a favor for our hard-working coders and common sense.

 

Okay. See. I recognize the intent of this post and message. Btu this is going to the opposite extreme and it is equal as unhelpful as the opposite extreme of just being like 'YALL CODERS JUST MEAN'.

Neither is true, both are somewhat antagonistic.

 

This is clearly a very tense topic to touch on because of the nature of what it is. Touching Atmos is touching basically the ENTIRETY of SS13 in some fashion and touching the entire server (Because if done improperly, the server will die to lag.)

That said.

We've established just about everyone would like it if we could push LINDA to do a little more. The problem for the Maintainers/Coders is, doing that without gutting performance or causing drastically increased CPU usage. (At least if I am grasping that correctly.)

The problem for people that WANT to touch Atmos is, those restrictions are felt to be somewhat draconian and nebulous. (Must have Parity AND not effect performance AND not increase CPU cycles.) ((PS: Not saying they ARE, just that this is what is clearly coming across.))

 

Now. Someone has an idea that only touches 2 lines of Code in LINDA, hooks to make some totally seperate shit work. And yet Mainters are saying otherwise. Whether there is a disconnect here, or what they mean by 'don't tamper much with LINDA' is just not matching up with that description, I don't know. The final say DOES belong with the Maintainers who know this code very well, they've been with it for a lot longer and can kinda get a feel for it.

 

On the OTHER side we have statements like:

"Again, if you're hellbent on making changes to LINDA, I highly recommend you get it past LINDA's original coder and creator, over at TG, first (and even then, there's no guarantee will backport it)."

 

That's BASICALLY saying ' Even if you get the -original system creator- to implement this as a better solution, we might not do it anyway cuz of reasons.'

 

Which is basically shooting a GIANT "Why even bother" Message all over -ANY- effort to even TRY and sort out a better Atmos system. Why TRY if even the original developer saying 'yeah this is better' is not enough to get it implemented? It's not entirely fair to say "Asking coders to do all this work is a big deal" when you have someone who WANTS to do that work but is being told "Even if you do all this work and even if the creator says it's better, we might ignore all that work it was originally intended for in the first place." Because clearly we're not here to upgrade TG station, we're here to upgrade Paradise Station, and we're sharing/offering to give it to TG in the process, if they want it. Doing al lthat work jsut for a 'maybe' is not a fair ask either.

That might contribute to -why- nobody wants to do it.

 

It feels like we've hit a point where both sides are exasperated, everyone is frustrated, it's been argued and now it's gotten tempers kinda risen. Going back and forth on what -has- happened isn't gonna benefit anyone here. Just locking the topic and sweeping under the rug to pretend it doesn't exist, ALSO doesn't help anyone, and both ways are not gonna fix the problem.

 

There's GOT to be a sit-down somewhere. Maybe all the Maintainers can get together to work out -exactly- what their criteria is for a change to the LINDA/Atmos system. Exactly WHAT bullet points need to be met for serious consideration, because right now it seems like nobody has that. They have what they DON'T want, but not what they WANT from a PR on this subject. And once people have THAT, then they know the tools they can work with, they know what their parameters even are.

 

[Shadeykins]

 

Fox has provided enough explanation here. Too bad you don't accept it.

 

Enough coder-bashing. This is shameful and unbecoming of members of the Paradise community. If you must have a server your way, run your own. Otherwise you won't get everything you want. Ultimately, we can't customize everything, we have to rely on other good code and the maintenance made to that code by those devs.

 

This thread was resolved 30 posts ago. It's been whining ever since.

 

Locking this thread does a favor for our hard-working coders and common sense.

 

Right, this is off-topic and will probably result in a thread lock but I'm going to address this here and now, because it's starting to get on my nerves.

 

Asking for a solid reason for "parity" when we're opensource is not coder bashing.

 

Taking an opposing stance is not bashing.

 

As I'm aware and have sunk time into TG, TG's version of LINDA is already different than ours so we don't have parity in the first place.

 

I get that you hate my guts as evidenced by your many, many posts that attempt to deride me, but you can stop.

 

I have no issues with you despite how often we carry opposing opinions, so you can stop making snide remarks as I have made absolutely none toward you.

 

The only thing I have remotely done to you is make a comment about "bringing my frownface brigade" to one of your suggestions as you specifically goaded to me (with the words frownface brigade no less) to do so. What's unbecoming is your false characterizations of me and spite towards me based on solely on the fact that we don't typically agree with one another when I have done absolutely nothing to you.

 

You seem to be under the mistaken impression that I somehow hate this server, hate the coders, and all the administration despite the fact that I'm a fairly regular donator - something I haven't even shared or mentioned to anyone up until this point, but am forced to do so in part to your implications that I somehow despise Paradise and am here to simply disagree with everything everyone has ever said, ever. I have also done no small amount of work on the server's wiki, for instance I wrote almost the entirety of the medical guide, the cloning guide, and have provided plenty of formatting, suggestions and proof-reads on the wiki, and am presently working on Vulp Lore with Flattest.

 

My point here is that you need to stop making assumptions about what I'm doing, and why I'm doing it - because you're dead wrong.

 

I like Fox. I make stupid jokes with Fox in OOC on the server and with ahelps, I play on the server with Fox.

 

Does he work hard? Yes.

 

This does not mean I have to agree with him, his methodology, or his implementation of things.

 

We maintain parity so that it's easier to port things from bigger codebases, including fixes, maintenance patches and features.

 

LINDA is a huge chunk of code not written by us. It's therefore wise to keep it as similar to the other codebase as possible, so we won't end up with an obsolete system at the end of a one-way road.

 

We have plenty of competent maintainers and coders, and people (as evidenced by Jey) who are more than willing to work on atmospherics. Opensource is not one-sided, and I fail to see why improvements can't be discussed/talked about/implemented simply because another server is doing something else.

 

This is on the same level as chemistry not being able to be modified whatsoever/names being unable to be changed because "we might offend Goon" (despite the fact that the names of chems, such as Salbutamol are ACTUAL names of real-word medication that relate to their in-game purpose). I believe in the case of Goon we were legitimately afraid that Goon might sue us or something of that nature should we dare modify goonchem.

 

We can't even change the name of Oculine (which was combined with Audioline) to something like Sensoline because "parity".

 

Parity allows for another server to have what more or less amounts to a stranglehold on our own server. We aren't TG or Goon, and therefore I really don't understand the need to never change anything about LINDA whatsoever simply to be on the same level as TG.

 

This is absolutely antithetical to what opensource is, and what it means.

 

If we're truly opensource, we should be able to implement changes to any aspect of our codebase without fear of repercussion to find the best solutions that offer the most in terms of efficiency and functionality, and then if another server (such as TG which also uses LINDA) sees that, they can co-opt that idea into their server. Open source is not "I will use this code but never modify it whatsoever because it comes from TG". That may as well be closed source at that point irrespective of whether or not you can readily see the code, as you're not capable of doing anything with it.

 

Code is not some mythical beast, it's a bunch of lines on a screen that work in tandem with other lines.

 

Parts of it can be changed and co-opted without bringing the roof down.

 

All anyone has wanted out of this thread is a set of standard and reasonable guidelines for working on the codebase, which the maintainers are largely refusing to provide or allow for because of "parity."

 

They didn't like Jey's initial code. Great, that's fine.

 

What is not fine is then refusing to elaborate further, or provide any guidelines or reasonable expectations on what is required for modifications to the codebase. What is not fine is calling yourself opensource, and then acting like you're closedsource because of "parity".

 

[tigercat2000]

 

Shadeykins, do you not understand how to take a hint of "stop making walls of text arguing with the maintainers"?

 

Jey's original code was bad. Any amount of arguing over the fucking technicalities or "well cpu load doesn't actually equate to network latency" doesn't change that. It was a more than 30% increase to CPU costs in the profiler, and from all the details Jey has provided, he didn't actually wait for LINDA's active_turfs list to fill, which is where the huge performance loss occurs. One of the maintainers tested the modifications locally, actually bothering to check that LINDA is actually under load, and found much higher performance loss results (over 50%).

 

We absolutely do have parity with LINDA on -tg-. They use a different central controller (-tg- subsystems as opposed to the Goon ProcessScheduler), but they work almost identically, and serve their purposes well (ticking things efficiently). They run LINDA at 4 times speed; A single variable change for either controller systems. They also run pipenets on the same controller as LINDA to make sure atmos processes in-time with the pipes. Any changes to LINDA, right now, would be very easy to apply to our code, which is the entire point of maintaining parity: They have over 20 coders working on just about everything, every day. We have 3 maintainers and 4-5~ coders, who are only sometimes even awake at the same time. We do not have enough dedicated coders to maintain a system as huge as LINDA, especially with modifications that only 1-2 of us can actually understand.

 

The thing about "guidelines or reasonable expectations" is, we for the most part don't want to change LINDA, at all- I don't care if Jey's code is just "adding a few hooks" to LINDA's controller, it massively increases the amount of work LINDA or LINDA's controller actually has to do, which 100% will affect user experience and server performance. Figures like "Most players want LINDA changed!" are pulled directly from absolutely fucking nowhere. The majority of users don't give a fuck until LINDA ends up killing them because of spacewind or fires or whathaveyou.

 

[Shadeykins]

 

Shadeykins, do you not understand how to take a hint of "stop making walls of text arguing with the maintainers"?

 

Jey's original code was bad. Any amount of arguing over the fucking technicalities or "well cpu load doesn't actually equate to network latency" doesn't change that. It was a more than 30% increase to CPU costs in the profiler, and from all the details Jey has provided, he didn't actually wait for LINDA's active_turfs list to fill, which is where the huge performance loss occurs. One of the maintainers tested the modifications locally, actually bothering to check that LINDA is actually under load, and found much higher performance loss results (over 50%).

 

We absolutely do have parity with LINDA on -tg-. They use a different central controller (-tg- subsystems as opposed to the Goon ProcessScheduler), but they work almost identically, and serve their purposes well (ticking things efficiently). They run LINDA at 4 times speed; A single variable change for either controller systems. They also run pipenets on the same controller as LINDA to make sure atmos processes in-time with the pipes. Any changes to LINDA, right now, would be very easy to apply to our code, which is the entire point of maintaining parity: They have over 20 coders working on just about everything, every day. We have 3 maintainers and 4-5~ coders, who are only sometimes even awake at the same time. We do not have enough dedicated coders to maintain a system as huge as LINDA, especially with modifications that only 1-2 of us can actually understand.

 

The thing about "guidelines or reasonable expectations" is, we for the most part don't want to change LINDA, at all- I don't care if Jey's code is just "adding a few hooks" to LINDA's controller, it massively increases the amount of work LINDA or LINDA's controller actually has to do, which 100% will affect user experience and server performance. Figures like "Most players want LINDA changed!" are pulled directly from absolutely fucking nowhere. The majority of users don't give a fuck until LINDA ends up killing them because of spacewind or fires or whathaveyou.

 

Now I'm curious, as TG runs LINDA at 4x with little impact on performance (their server performance seems reasonable in my experience) why is it such a ticking point for Paradise? I've been informed that Paradise has what more or less amounts to the best possible hardware available to run an SS13 server (By both Necaldun and Tully I believe), yet there's a drastic disparity between LINDA 4x on Para, and LINDA 4x on TG.

 

And thank you, that's a stronger reason than just saying the word "parity".

 

[tigercat2000]

 

-tg- actually has major performance impacts from their decision to run LINDA at 4x- If you were to run their codebase with LINDA turned back down to 20 deciseconds, it would run even more smoothly.

 

The reason that -tg- runs so smoothly compared to us is for a few reasons:

1) They do have a better computer running their servers. Mel's hardware is awesome- but there are a few bottlenecks that -tg- has gotten around, mainly in terms of the RAM installed (I believe they use DDR4 RAM sticks.)

2) With the huge amount of coders mentioned earlier, a lot of tiny performance impacts (for var/whatever in world) are quietly and quickly fixed. They make basically no difference on an individual level, but when you have 60 of them running at the same time, it gets a lot more noticeable.

3) Bots. Beepsky/Medibots/etc, they all use a system called "A*" for pathfinding- -tg- has made major performance enhancements to both bot code and A* on their server. We've tried to port it in the past, but it's such a mess that it's very hard to actually modify, especially while trying to keep every feature. Try spawning 50 medibots on a local server, it tends to cause things to grind to a halt as they try to pathfind their way around.

4) Their "subsystem" controller does completely outpace the scheduler. It dynamically turns subsystems on and off and can delay them indefinately while things are going on- When an explosion occurs, half of the controllers may outright not process that tick. And, it's a very good approach- however, it has it's flaws, most of which I don't know the code well enough to mention. But, our scheduler, from what I understand, is more efficient long-term, and more robust overall, especially with the technical backing of GoonStation. The big difference is SCHECK- It's a thing on our scheduler that tries to stop controllers from pushing the server too hard, thus delaying the next internal tick of byond. It supposedly can get a more accurate reading of how well the server is performing via the 'btime.dll' library.

 

[Shadeykins]

 

-tg- actually has major performance impacts from their decision to run LINDA at 4x- If you were to run their codebase with LINDA turned back down to 20 deciseconds, it would run even more smoothly.

 

The reason that -tg- runs so smoothly compared to us is for a few reasons:

1) They do have a better computer running their servers. Mel's hardware is awesome- but there are a few bottlenecks that -tg- has gotten around, mainly in terms of the RAM installed (I believe they use DDR4 RAM sticks.)

2) With the huge amount of coders mentioned earlier, a lot of tiny performance impacts (for var/whatever in world) are quietly and quickly fixed. They make basically no difference on an individual level, but when you have 60 of them running at the same time, it gets a lot more noticeable.

3) Bots. Beepsky/Medibots/etc, they all use a system called "A*" for pathfinding- -tg- has made major performance enhancements to both bot code and A* on their server. We've tried to port it in the past, but it's such a mess that it's very hard to actually modify, especially while trying to keep every feature. Try spawning 50 medibots on a local server, it tends to cause things to grind to a halt as they try to pathfind their way around.

4) Their "subsystem" controller does completely outpace the scheduler. It dynamically turns subsystems on and off and can delay them indefinately while things are going on- When an explosion occurs, half of the controllers may outright not process that tick. And, it's a very good approach- however, it has it's flaws, most of which I don't know the code well enough to mention. But, our scheduler, from what I understand, is more efficient long-term, and more robust overall, especially with the technical backing of GoonStation. The big difference is SCHECK- It's a thing on our scheduler that tries to stop controllers from pushing the server too hard, thus delaying the next internal tick of byond. It supposedly can get a more accurate reading of how well the server is performing via the 'btime.dll' library.

 

If you can figure out what type of RAM they use (DDR4 sounds like a likely candidate) versus the one presently installed in the server, I'm more than willing to spring for the price of the components.

 

I'm honestly surprised at the disparity of dedicated coders as well, considering that Paradise is typically the more popular server when listed.

 

[alexpkeaton]

 

Asking for a solid reason for "parity" when we're opensource is not coder bashing.

 

Taking an opposing stance is not bashing.

 

...

 

What is not fine is then refusing to elaborate further, or provide any guidelines or reasonable expectations on what is required for modifications to the codebase. What is not fine is calling yourself opensource, and then acting like you're closedsource because of "parity".

 

"Disagreement isn't wrong!"

 

Masterstroke of passive-aggression, that one is.

 

Let me explain this by way of a metaphor.

 

Person A: Can I have a cookie?

Person B: No.

A: Why?

B: (Explanation.)

A: Ok, can I have a cookie now?

B: No.

A: Why?

B: (Explanation.)

A: Ok. How about if I eat it in slow bites?

B: No.

A: Why?

B: (Explanation.)

A: What if I give half to you? Can I get a cookie then?

B: No.

A: Why?

B: (Explanation.)

A: I'm so frustrated! I just don't understand why you won't give me a cookie!

 

Disagreement isn't wrong.

 

What's wrong is saying you don't understand why the coders won't give you the cookie.

 

They've explained it four different ways.

 

[Fox McCloud]

 

Now I'm curious, as TG runs LINDA at 4x with little impact on performance (their server performance seems reasonable in my experience) why is it such a ticking point for Paradise? I've been informed that Paradise has what more or less amounts to the best possible hardware available to run an SS13 server (By both Necaldun and Tully I believe), yet there's a drastic disparity between LINDA 4x on Para, and LINDA 4x on TG.

 

And thank you, that's a stronger reason than just saying the word "parity".

 

I'd be happy to touch on this.

 

here's TG's processor:

 

https://www.cpubenchmark.net/cpu.php?cp ... Hz&id=2565

 

Here's Mel's/Para's:

 

https://www.cpubenchmark.net/cpu.php?cp ... 50GHz&id=2

 

Mel's is overclocked a bit, so it's not a direct comparison, but as you can see, the 6700k outperforms it by a significant margin.

 

Also with how BYOND reads and writes variables, it's VERY memory dependent in terms of performance; TG's previous processor was about as good as Mel's is, but yet when they updated to the 6700k, they got an 80% increase in performance for LINDA---reason why is because of DDR4 and its dramatically increased speed.

 

Another reason is what Tigercat touched on; TG's subsystems are, from what I've gathered, superior to the process scehduler.

 

How the process scheduler works: it kinda breaks apart individual controllers so that if one is hung up, it doesn't impact the others; you know the times you get spammed with "obj processing hung, and was killed at XX:XX"--note how youd could still move, walk talk, and do things---with our previous controller, if this happened, the entire game would lock up.

 

Another feature of it is a thing called "SCHECK". Scheck is a command that references and external .dll called 'btime'. BYOND has no way of determining how far into a tick the server is nor does it have an accurate way of measuring CPU (the CPU displayed in game is an average over the past few ticks...). What scheck does is after every so many things in a loop (ie: every 50 mobs) it'll check this external .dll and see if it *thinks* the current tick *may* be driven into overtime. If it looks like it may, it'll sleep for 1 tick and defer the rest of the calculations for that loop to the next server tick (this is also why it's kinda pointless to break a loop up into quarters). Oh, that reminds me, referencing and checking btime.dll is hyper expensive.

 

That said, we don't live in a perfect world; it's still not 100% possible to determine if a tick really is going to go into overtime andddd sometimes scheck is a bit too aggressive and will defer when it doesn't really need to (thus wasting CPU). If everything in SS13 were perfectly coded, the scheduler would actually be a net drain on performance and incur a loss from scheck.

 

TG's subsystems don't have btime and they handle adjusting their systems in a (I think--though I could be wrong) more optimized way in calculating costs and adjusting things (on the fly) internally; LINDA, for example, will actually end up running slower than our implementation if their CPU load is very high (it just runs at every 5 decisecodns by default).

 

When we were initially going with the scheduler, I had a discussion with some of the TG station devs and why they weren't going with it--ultimately, in a perfect world, the scheduler is dead weight--and thus why they viewed their subsystems as superior (and this was before they made major strides into internal system adjustments for controllers). I do believe there's aspects of the scheduler that are superior, but on the whole, the subsystems appear to handle lag better.

 

Performance is a constant battle on Paradise as we don't have huge margins to work with, unfortunately; for example, when I was porting the Tesla engine, I was constantly keeping an eye on how costly the orbiting energy balls were---I even ran the server for 2 hour durations (multiple times) to see what performance impact was likew ith tons of balls orbiting it---this all went in mind before I decided if it was actually an "ok" thing or not.

 

[Plotron]

 

Okay, I'm out of this discussion. I've read all the posts.

It is my belief that Jey should try his luck on TG, considering that they're running LINDA at 4x speed.

Paradise is not the best place for such "innovative" coding ideas.

 

I also feel like both sides have presented their arguments and addressed most of the counterarguments.

 

If you can figure out what type of RAM they use (DDR4 sounds like a likely candidate) versus the one presently installed in the server, I'm more than willing to spring for the price of the components.

 

If you want a better server that uses modern components, you'd need a new motherboard, a new Intel Core I7-class CPU and - if we were to opt for newer architectures - new DDR4 RAM sticks. That's a shitton of fucking money. The thing is - new CPUs are nowadays marginally faster (5-10%) than their direct predecessors (comparing two generations), so you're not getting much bang for the buck when you upgrade. What is more - each generation (at least in the consumer line) brings a new chipset and/or socket, so your old motherboard becomes obsolete. The prices still hold, though.

The best deals people find are probably Intel Xeon server CPUs - when companies and private users get rid of them, it's a bargain.

 

[Professor Cupcake]

 

Looks to me like, in amongst all the messy human bits, all the major points have now been addressed. Cool.

Looking forward to the result of your contacting TG, Jey.

 

[Fox McCloud]

 

Just wanted to say a quick thing, Plotron.

 

Yeah, the newer CPU's aren't that much faster than the current, butttt, they are DDR4---the way BYOND reads and writes variables means that memory can actually have a larger impacts on certain performance than others; when TG upgraded to DDR4 they also upgraded to a CPU that was like 10-20% faster...but the performance for LINDA, specifically, increased by 80% because of the memory.

 

[Plotron]

 

but the performance for LINDA, specifically, increased by 80% because of the memory.

Amazing. It's hard to believe, though, considering that most benchmarks between DDR2 and DDR3, and now DDR3 and DDR4 show little if any speed increase.

The gain is real when you compress folders (WinRAR, ZIP), however.

http://www.anandtech.com/show/8959/ddr4 ... -crucial/8

It's interesting that LINDA falls into this category. But then again - it's definitely a special application.

 

The difficulty of testing this stuff is further compounded by lack of backwards-compatible hardware.

There were times when you could pick between DDR2 and DDR3 on the same motherboard...

 

[Fox McCloud]

 

t's interesting that LINDA falls into this category. But then again - it's definitely a special application..

 

Yes...we'll go with..."special" to describe BYOND....

 

[melandor0]

 

Mel's is overclocked a bit, so it's not a direct comparison, but as you can see, the 6700k outperforms it by a significant margin.

 

Fun fact: Our CPU runs at 4.4GHz only because my Mobo doesn't support OCing higher than that without messing with the BIOS - and I'm not that hardcore.

 

[Jey123456]

I have no intentions of contacting TG since its not a change to LINDA but an addon. Its not TG i wanted to improve the atmo off its Paradise. Parity was maintained and the cpu could have been reduced (as per my proposition on page 4) sadly its obviously not wanted so meh. Enjoy your slow atmo .

[GelatinousGlob]

 

Isn't SS13 pretty much single core? There is no need for an I7 when an I5 will do the same thing. I have a 4690k i5 and can overclock ti with stock voltages up to 4.4 ghz, I can still add an extra .2 volts and get higher, although I might want to switch to water cooling at that point. Even with the 4.2 I keep it at for Dwarf Fortress my air cooling keeps it below 80C at all times and the chip is rated for up to 100C with 120C as the factory tested temp limit.

 

Unless you can utilize more than 4 cores the I7 is a waste of money.

 

[Jey123456]

i7 generally have a few more of the advanced instruction sets / cache optimisations available than their i5 variants. Which count for a lot when your bottleneck is not cpu but memory bandwidth / latency related

[Jey123456]

 

I couldnt get it out of my head so i wrote a quick proof of concept from my theory on page 4. This is nothing but a proof of concept but feel free to comment on it / test it out.

 

https://github.com/Jey123456/Paradise/c ... fc4ecdb6f1