3 ms·

How much of a speed up versus Python/Julia are we talking about? I didn’t see any direct comparison. I’m not sure I understand what you mean by integration.

adgjlsfhk1 5y ago
It's linear algebra will be the same speed as python/Julia (they both call to BLAS/LaPack). It's diffeq solvers will almost certainly be worse than Julia (Julia is SOTA there). Not sure about the rest of the functionality.
- melissalobos 5y ago
  > It's diffeq solvers will almost certainly be worse than Julia (Julia is SOTA there) Worse in what sense? Speed? Almost certainly not, since you would be implementing the solution directly in C++, so it will be as fast as you need(since you can use inline ASM). In Julia the really good diffeq libraries are not built in and this is not a diffeq solving library, so you would have to implement them yourself if you were just using this(so you can use almost exactly the same algorithms, and with more control over memory management in C++ you can maybe have it be a bit faster).
  - pjmlp 5y ago
    I also imagine that with C++17 or higher tooling, alongside something like CINT, it starts to feel quite productive.
  - adgjlsfhk1 5y ago
    Have you seen DifferentialEquations.jl? It's an incredibly fast suite of solvers that pretty consistently is faster than Sundials/CVODE/lsoda or any of the other C++ solver. (for a bunch of benchmarks vs pretty much everything else, see https://github.com/SciML/SciMLBenchmarks.jl https://github.com/SciML/SciMLBenchmarks.jl)
    - melissalobos 5y ago
      Indeed, that particular implementation is very fast. One of the goals of the C++ language is to leave no space for a lower level language than C++. A motivated person could just re-implement those algorithms in C++, in the absolute worst case using inline Assembly and at the very worst exactly match their performance. One of the nice things about Julia is you get good performance without going through a huge amount of effort. However you could always do as good or better in C++(with maybe more effort).
      - adgjlsfhk1 5y ago
        Julia is pretty much the same but a few levels higher. Julia gives you some really powerful tools like @code_native (basically godbolt), inline assembly (or @code_llvm) something that , powerful macros, and better code reuse. If you look at the size of Julia libraries compared to similar C++ alternatives, the Julia ones are often about as fast (or faster), but typically around 10x less code. (my favorite example is that Julia's reader for Arrow files is more complete than the C++ one while being smaller than the makefiles for the C++ one (https://twitter.com/MoseGiordano/status/1489255661728796679 https://twitter.com/MoseGiordano/status/1489255661728796679)
gumby 5y ago
> How much of a speed up versus Python/Julia are we talking about? I didn’t see any direct comparison. These things may not matter to your application, but performance for me is more than just linear algebra. With C++ it’s straightforward to manage the working set so I can keep data with computational locality together, manage prefetching at the like. I can run the algos on multiple cores (no GIL, for example). Etc etc. There is plenty of performance comparison between C++ and Python on the web, but alone the statistics mean nothing. Is your speed of development more important than runtime? For many people that would make Python faster. In my case I don’t use C++ as if it is C with other stuff bolted on so my development is just as fast in either language, so I choose the one which gives me more expressive power. It’s not like I’m dissing Julia or Python, though my go to for little explorations is Common Lisp. They are just designed for different points in the solution space. > I’m not sure I understand what you mean by integration. Sorry, I didn’t mean mathematical integration, I meant integration with OpenCV, various robot hardware etc, as well as deeper integration with the hardware.
- _aavaa_ 5y ago
  > They are just designed for different points in the solution space. I guess my problem is that I don't understand which point of the solution space Castor is trying to go for. > There is plenty of performance comparison between C++ and Python on the web Sorry if I wasn't clear myself. I didn't mean for general python vs c++ comparison. I meant Castor vs the things it is trying to position itself as an alternative to (e.g. numpy or julia).
throwawayninja 5y ago
From my personal experience: system languages are really, really good at interacting with operating systems. When you have things deployed on a server that machine generally has one task, and it makes sense to optimize as many layers as possible. For example on a windows system I used MS's `FILE_FLAG_SEQUENTIAL_SCAN` flag to triple read performance; you could of course do the same in python by dipping into ctypes but it doesn't make for a pleasant development experience. The big trade-off is you're specifying the task more precisely and as a result of that extra labor you get better performance for the life of the tool. SQLITE has a good story of putting together dozens of small optimizations, each <1% performance change, and at the end the library's throughput doubled in pretty much all tests. It's not worth it for research, but it is everywhere else.

adgjlsfhk1 5y ago

It's linear algebra will be the same speed as python/Julia (they both call to BLAS/LaPack). It's diffeq solvers will almost certainly be worse than Julia (Julia is SOTA there). Not sure about the rest of the functionality.

melissalobos 5y ago
> It's diffeq solvers will almost certainly be worse than Julia (Julia is SOTA there) Worse in what sense? Speed? Almost certainly not, since you would be implementing the solution directly in C++, so it will be as fast as you need(since you can use inline ASM). In Julia the really good diffeq libraries are not built in and this is not a diffeq solving library, so you would have to implement them yourself if you were just using this(so you can use almost exactly the same algorithms, and with more control over memory management in C++ you can maybe have it be a bit faster).
- pjmlp 5y ago
  I also imagine that with C++17 or higher tooling, alongside something like CINT, it starts to feel quite productive.
- adgjlsfhk1 5y ago
  Have you seen DifferentialEquations.jl? It's an incredibly fast suite of solvers that pretty consistently is faster than Sundials/CVODE/lsoda or any of the other C++ solver. (for a bunch of benchmarks vs pretty much everything else, see https://github.com/SciML/SciMLBenchmarks.jl https://github.com/SciML/SciMLBenchmarks.jl)
  - melissalobos 5y ago
    Indeed, that particular implementation is very fast. One of the goals of the C++ language is to leave no space for a lower level language than C++. A motivated person could just re-implement those algorithms in C++, in the absolute worst case using inline Assembly and at the very worst exactly match their performance. One of the nice things about Julia is you get good performance without going through a huge amount of effort. However you could always do as good or better in C++(with maybe more effort).
    - adgjlsfhk1 5y ago
      Julia is pretty much the same but a few levels higher. Julia gives you some really powerful tools like @code_native (basically godbolt), inline assembly (or @code_llvm) something that , powerful macros, and better code reuse. If you look at the size of Julia libraries compared to similar C++ alternatives, the Julia ones are often about as fast (or faster), but typically around 10x less code. (my favorite example is that Julia's reader for Arrow files is more complete than the C++ one while being smaller than the makefiles for the C++ one (https://twitter.com/MoseGiordano/status/1489255661728796679 https://twitter.com/MoseGiordano/status/1489255661728796679)

gumby 5y ago

> How much of a speed up versus Python/Julia are we talking about? I didn’t see any direct comparison. These things may not matter to your application, but performance for me is more than just linear algebra. With C++ it’s straightforward to manage the working set so I can keep data with computational locality together, manage prefetching at the like. I can run the algos on multiple cores (no GIL, for example). Etc etc. There is plenty of performance comparison between C++ and Python on the web, but alone the statistics mean nothing. Is your speed of development more important than runtime? For many people that would make Python faster. In my case I don’t use C++ as if it is C with other stuff bolted on so my development is just as fast in either language, so I choose the one which gives me more expressive power. It’s not like I’m dissing Julia or Python, though my go to for little explorations is Common Lisp. They are just designed for different points in the solution space. > I’m not sure I understand what you mean by integration. Sorry, I didn’t mean mathematical integration, I meant integration with OpenCV, various robot hardware etc, as well as deeper integration with the hardware.

_aavaa_ 5y ago
> They are just designed for different points in the solution space. I guess my problem is that I don't understand which point of the solution space Castor is trying to go for. > There is plenty of performance comparison between C++ and Python on the web Sorry if I wasn't clear myself. I didn't mean for general python vs c++ comparison. I meant Castor vs the things it is trying to position itself as an alternative to (e.g. numpy or julia).

throwawayninja 5y ago

From my personal experience: system languages are really, really good at interacting with operating systems. When you have things deployed on a server that machine generally has one task, and it makes sense to optimize as many layers as possible. For example on a windows system I used MS's `FILE_FLAG_SEQUENTIAL_SCAN` flag to triple read performance; you could of course do the same in python by dipping into ctypes but it doesn't make for a pleasant development experience. The big trade-off is you're specifying the task more precisely and as a result of that extra labor you get better performance for the life of the tool. SQLITE has a good story of putting together dozens of small optimizations, each <1% performance change, and at the end the library's throughput doubled in pretty much all tests. It's not worth it for research, but it is everywhere else.