TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Mapping Out the HPC Dependency Chaos

49 点作者 setheron超过 2 年前

3 条评论

throw0101c超过 2 年前
This is why Spack was created:<p>&gt; <i>Spack is a package management tool designed to support multiple versions and configurations of software on a wide variety of platforms and environments. It was designed for large supercomputing centers, where many users and application teams share common installations of software on clusters with exotic architectures, using libraries that do not have a standard ABI. Spack is non-destructive: installing a new version does not break existing installations, so many configurations can coexist on the same system.</i><p>* <a href="https:&#x2F;&#x2F;spack.readthedocs.io&#x2F;en&#x2F;latest&#x2F;" rel="nofollow">https:&#x2F;&#x2F;spack.readthedocs.io&#x2F;en&#x2F;latest&#x2F;</a><p>&gt; <i>Spack is a package manager for supercomputers, Linux, and macOS. It makes installing scientific software easy. Spack isn’t tied to a particular language; you can build a software stack in Python or R, link to libraries written in C, C++, or Fortran, and easily swap compilers or target specific microarchitectures.</i><p>* <a href="https:&#x2F;&#x2F;spack.io" rel="nofollow">https:&#x2F;&#x2F;spack.io</a><p>Intro presentation from some HPC conferences:<p>* <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=edpgwyOD79E" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=edpgwyOD79E</a><p>* <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=DhUVbroMLJY" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=DhUVbroMLJY</a><p>Very similar to (home)brew, MacPorts, etc, with more of a focus on HPC so you can have multiple versions of a particular piece of software, made with different compiles and linked against different library version.
评论 #33563591 未加载
评论 #33565965 未加载
评论 #33564022 未加载
评论 #33566849 未加载
评论 #33564703 未加载
linksnapzz超过 2 年前
This is a nice paper, and I do appreciate the authors&#x27; efforts. I fight with this stuff daily.<p>But...this caught my eye:<p>&quot;While it’s a pleasant thought experiment to imagine a world where we do not require backwards compatibility with estab- lished loaders, the state of the practice is that we must work within the limitations of ELF and the System V ABI model.&quot;<p>In light of the current HPC orthopraxis, I wonder if there might not be real value in seeing how far towards reality one could drag the thought experiment of not having to depend on that backwards compatibility. E.G. what sort of work abandoning the ELF&#x2F;SysV ABI model might require.<p>Dijkstra said something once about the problems of the real world being the ones that you&#x27;re left with when you refuse to apply their effective solutions.
评论 #33564625 未加载
评论 #33577869 未加载
37ef_ced3超过 2 年前
There are completely stand-alone systems like:<p><a href="https:&#x2F;&#x2F;NN-512.com" rel="nofollow">https:&#x2F;&#x2F;NN-512.com</a><p>The stand-alone code generator (a statically linked executable written in Go with no dependencies outside the Go standard library) generates stand-alone POSIX C code for the neural net, requiring only gcc to compile.<p>Also see Fabrice Bellard&#x27;s LibNC:<p><a href="https:&#x2F;&#x2F;bellard.org&#x2F;libnc&#x2F;" rel="nofollow">https:&#x2F;&#x2F;bellard.org&#x2F;libnc&#x2F;</a><p>C API. Small library, no external dependencies, available for Linux and Windows.