SaaSHub helps you find the best software and product alternatives Learn more →
Top 23 Scientific Computing Open-Source Projects
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
gonum
Gonum is a set of numeric libraries for the Go programming language. It contains libraries for matrices, statistics, optimization, and more
-
burn
Burn is a new comprehensive dynamic Deep Learning Framework built using Rust with extreme flexibility, compute efficiency and portability as its primary goals.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
spack
A flexible package manager that supports multiple versions, configurations, platforms, and compilers.
-
rust-ndarray
ndarray: an N-dimensional array with array views, multidimensional slicing, and efficient operations
-
FluidX3D
The fastest and most memory efficient lattice Boltzmann CFD software, running on all GPUs via OpenCL.
-
gosl
Linear algebra, eigenvalues, FFT, Bessel, elliptic, orthogonal polys, geometry, NURBS, numerical quadrature, 3D transfinite interpolation, random numbers, Mersenne twister, probability distributions, optimisation, differential equations.
-
casadi
CasADi is a symbolic framework for numeric optimization implementing automatic differentiation in forward and reverse modes on sparse matrix-valued computational graphs. It supports self-contained C-code generation and interfaces state-of-the-art codes such as SUNDIALS, IPOPT etc. It can be used from C++, Python or Matlab/Octave.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
I guess it is a rite of passage to rewrite it. I'm doing it for SciPy too together with Propack in [1]. Somebody already mentioned your repo. Thank you for your efforts.
https://github.com/goplus/gop, but they go slightly too overboard imo.
But if you want to see what can be done for numeric stuff, check out gonum. Personally, I still wouldn't use Go, and I rather suspect it's still pretty easy to reach for something like what you're trying to do and not find it because Go just can't write that type sensibly, but you can at least see what is available, written by people who disagree with me about Go not being a great language for this.
[package] name = "resnet_burn" version = "0.1.0" edition = "2021" [dependencies] burn = { git = "https://github.com/tracel-ai/burn.git", rev = "75cb5b6d5633c1c6092cf5046419da75e7f74b11", features = ["ndarray"] } burn-import = { git = "https://github.com/tracel-ai/burn.git", rev = "75cb5b6d5633c1c6092cf5046419da75e7f74b11" } image = { version = "0.24.7", features = ["png", "jpeg"] }
Project mention: How much C++ is used when it comes to performing quant research? | /r/quant | 2023-07-03Does C++ have the equivalent of Pandas or Apache Spark? Are there extensive libraries that exist/are being developed that allow you to perform operations with data? Or do people just use a combination of Python & its various libraries (NumPy etc)? If we leave aside the data bit, are there libraries that allow you to develop ML models in C++ (mlpack for instance ) faster & more efficiently compared to their Python counterparts (scikit-learn)? On a more general note, how does C++ fit into the routine of a Quant Researcher? And at what scale does an organization decide they need to start switching to other languages and spend more time developing the code ?
Loads of people have stated why easy GPU interfaces are difficult to create, but we solve many difficult things all the time.
Ultimately I think CPUs are just satisfactory for the vast vast majority of workloads. Servers rarely come with any GPUs to speak of. The ecosystem around GPUs is unattractive. CPUs have SIMD instructions that can help. There are so many reasons not to use GPUs. By the time anyone seriously considers using GPUs they're, in my imagination, typically seriously starved for performance, and looking to control as much of the execution details as possible. GPU programmers don't want an automagic solution.
So I think the demand for easy GPU interfaces is just very weak, and therefore no effort has taken off. The amount of work needed to make it as easy to use as CPUs is massive, and the only reason anyone would even attempt to take this on is to lock you in to expensive hardware (see CUDA).
For a practical suggestion, have you taken a look at https://arrayfire.com/ ? It can run on both CUDA and OpenCL, and it has C++, Rust and Python bindings.
Project mention: Node still seems better than python after all this time for web server speed but.. | /r/node | 2023-06-20Numpy is a library - node.js has plenty of them, what is missing? There is stdlib package that offers optimized math functions, for example.
Project mention: Autodafe: "freeing your freeing your project from the clammy grip of autotools." | news.ycombinator.com | 2024-04-06> Are we talking about the same autotools?
Yes. Instead of figuring out how to do something particular with every single software package, I can do a --with-foo or --without-bar or --prefix=/opt/baz-1.2.3, and be fairly confident that it will work the way I want.
Certainly with package managers or (FreeBSD) Ports a lot is taken care of behind the scenes, but the above would also help the package/port maintainers as well. Lately I've been using Spack for special-needs compiles, but maintainer ease also helps there, but there are still cases one a 'fully manual' compile is still done.
> Suffice it to say, I prefer to work with handwritten makefiles.
Having everyone 'roll their own' system would probably be worse, because any "mysteriously failure" then has to be debugged specially for each project.
Have you tried Spack?
cmake_minimum_required(VERSION 3.5) project(knn_cpp CXX) # Set up C++ version and properties include(CheckIncludeFileCXX) check_include_file_cxx(any HAS_ANY) check_include_file_cxx(string_view HAS_STRING_VIEW) check_include_file_cxx(coroutine HAS_COROUTINE) set(CMAKE_CXX_STANDARD 20) set(CMAKE_BUILD_TYPE Debug) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(CMAKE_CXX_EXTENSIONS OFF) # Copy data file to build directory file(COPY ${CMAKE_CURRENT_SOURCE_DIR}/iris.data DESTINATION ${CMAKE_CURRENT_BINARY_DIR}) # Download library usinng FetchContent include(FetchContent) FetchContent_Declare(matplotplusplus GIT_REPOSITORY https://github.com/alandefreitas/matplotplusplus GIT_TAG origin/master) FetchContent_GetProperties(matplotplusplus) if(NOT matplotplusplus_POPULATED) FetchContent_Populate(matplotplusplus) add_subdirectory(${matplotplusplus_SOURCE_DIR} ${matplotplusplus_BINARY_DIR} EXCLUDE_FROM_ALL) endif() FetchContent_Declare( fmt GIT_REPOSITORY https://github.com/fmtlib/fmt.git GIT_TAG 7.1.3 # Adjust the version as needed ) FetchContent_MakeAvailable(fmt) # Add executable and link project libraries and folders add_executable(${PROJECT_NAME} main.cc) target_link_libraries(${PROJECT_NAME} PUBLIC matplot fmt::fmt) aux_source_directory(lib LIB_SRC) target_include_directories(${PROJECT_NAME} PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}) target_sources(${PROJECT_NAME} PRIVATE ${LIB_SRC}) add_subdirectory(tests)
I would love some examples of how to do non-trivial data interop between Rust and Python. My experience is that PyO3/Maturin is excellent when converting between simple datatypes but conversions get difficult when there are non-standard types, e.g. Python Numpy arrays or Rust ndarrays or whatever other custom thing.
Polars seems to have a good model where it uses the Arrow in memory format, which has implementations in Python and Rust, and makes a lot of the ndarray stuff easier. However, if the Rust libraries are not written with Arrow first, they become quite hard to work with. For example, there are many libraries written with https://github.com/rust-ndarray/ndarray, which is challenging to interop with Numpy.
(I am not an expert at all, please correct me if my characterizations are wrong!)
Project mention: Distributed Inference and Fine-Tuning of Large Language Models over the Internet | news.ycombinator.com | 2024-01-02Made me think of Gridcoin and BOINC https://boinc.berkeley.edu/
- single cell genomics: in collaboration with the Chan-Zuckerberg Initiative, we recently released TileDB-SOMA for single cell data, with APIs for both Python and R built around a common storage specification: https://tiledb.com/blog/tiledb-101-single-cell
With TileDB, all data — tables, genomics, images, videos, location, time-series — across multiple domains is captured as multi-dimensional arrays. TileDB Cloud implements a totally serverless infrastructure and delivers access control, easier data and code sharing and distributed computing at global scale, eliminating cluster management, minimizing TCO and promoting scientific collaboration and reproducibility.
Website: https://tiledb.com
Interface for several solvers and integrators.
Scientific Computing related posts
- Go Enums Suck
- Burn Deep Learning Framework Release 0.12.0 Improved API and PyTorch Integration
- Fix: Hong Kong is not in China
- Supercharge Web AI Model Testing: WebGPU, WebGL, and Headless Chrome
- Burn Deep Learning Framework 0.11.0 Released: Just-in-Time Automatic Kernel Fusion & Founding Announcement
- Burn Deep Learning Framework v0.11.0 Released: Just-in-Time Kernel Fusion
- Burn – comprehensive dynamic Deep Learning Framework built using Rust
-
A note from our sponsor - SaaSHub
www.saashub.com | 19 Apr 2024
Index
What are some of the best open-source Scientific Computing projects? This list will help you:
Project | Stars | |
---|---|---|
1 | SciPy | 12,407 |
2 | Torch | 8,891 |
3 | gop | 8,772 |
4 | gonum | 7,249 |
5 | burn | 6,948 |
6 | mlpack | 4,787 |
7 | ArrayFire | 4,395 |
8 | stdlib | 3,988 |
9 | spack | 3,938 |
10 | matplotplusplus | 3,909 |
11 | linfa | 3,381 |
12 | NumCpp | 3,370 |
13 | rust-ndarray | 3,307 |
14 | FluidX3D | 3,162 |
15 | FFTW | 2,578 |
16 | boinc | 1,915 |
17 | thread-pool | 1,911 |
18 | gosl | 1,804 |
19 | TileDB | 1,762 |
20 | PyCUDA | 1,740 |
21 | casadi | 1,549 |
22 | mfem | 1,530 |
23 | ruptures | 1,467 |