<div dir="ltr">Hi-Angel:<div><br></div><div>Actually, I tried running it with SLES12 SP2 (which would have a newer kernel than SLES12 SP1) and the analysis software actually failed to run in SLES12 SP2.</div><div><br></div><div>Tried it (not for this issue, just in general).</div><div><br></div><div>Didn't work.</div><div><br></div><div>The analysis software is not certified to run in SLES12 SP2, just as it is not certified to run on the latest kernel. (The platform support documention is listed by distro version, so whatever kernel comes with the distro version is what the analysis software has been certfied to run on.)</div><div><br></div><div>I don't disagree with you that newer kernels comes with many benefits. But when I can't guarantee its operation and the developer of the analysis software doesn't support it beyond what they've published as supported linux distros/versions in their platform support documentation - so if I want to make sure that everything works per the developer of the analysis software (as an end user), I would be advised to stay within what platforms they have certified (and support, including kernels) because that is what the analysis software developer can guarantee proper operation of their software.</div><div><br></div><div>Believe me, if this was something that I was developing and/or have more freedom and control over how it is developed, using the latest and greatest technologies that would yield the greatest benefit would of course be the best thing to do. But I don't have any say in it as an end user. And given the number of versions/iterations of Linux kernels out there, it would be physically impossible to persistently maintain and ensure that a software that's 26 GB (when installed) will work persistently throughout the entire software system for all of the kernel versions, as they are developed and published.</div><div><br></div><div>That would be insane. There would be no end to the testing. </div><div><br></div><div>(Remember, my analysis script alone takes 4.5 days to run. Think about how many kernels are available that's floating out there and now imagine that I would have to test it against each of the kernels. And that's just in the realm of mechanical engineering analysis domain. Doesn't include any other engineering and/or physics domains.)</div><div><br></div><div>It's just not feasible nor practical for the analysis software developer to do that.</div><div><br></div><div>Thanks.</div><div><br></div><div>Sincerely,</div><div>Ewen</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 8, 2017 at 4:17 AM, Hi-Angel <span dir="ltr"><<a href="mailto:hiangel999@gmail.com" target="_blank">hiangel999@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 7 December 2017 at 19:22, Ewen Chan <<a href="mailto:chan.ewen@gmail.com">chan.ewen@gmail.com</a>> wrote:<br>
</span><span class="">> Pros (for Linux): It's faster when it is running at runlevel 3.<br>
<br>
</span>Oh, by the way, I forgot to mention — just a tiny detail you might be<br>
curious of. I'm pretty sure you're running some old kernel, however in<br>
every kernel release there's a bunch of improvements and refactoring<br>
across all subsystems — power/cpu schedulers, kernel drivers, memory<br>
management, etc. So by using a later kernel you could make your<br>
calculations even faster. For more details see this<br>
<a href="https://kernelnewbies.org/LinuxVersions" rel="noreferrer" target="_blank">https://kernelnewbies.org/<wbr>LinuxVersions</a><br>
<br>
There's also per-thread malloc cache in glibc-2.26 which improves<br>
results of some benchmarks too. In general, if you want more<br>
performance, running latest software is recommended.<br>
</blockquote></div><br></div>