[HN Gopher] Castor: A C++ library to code "a la Matlab"
___________________________________________________________________
Castor: A C++ library to code "a la Matlab"
Author : SiempreViernes
Score : 40 points
Date : 2022-04-17 23:00 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| Bancakes wrote:
| Wonder if Matlab's C++ auto-generated code is competitive in
| performance.
| melissalobos wrote:
| One thing is that this library has built in support for
| H-matrices(last I checked Matlab did not), so it can be
| arbitrarily more efficient if your problem decomposes in a nice
| way(most matrices in practice have large low rank sections, so
| this may be a very large class of problems).
| loxias wrote:
| It's _really good_.
|
| I don't have any links or docs but I've used it quite a bit.
| With a recent of MATLAB, the codegen is good enough that my
| workflow has become "prototype in MATLAB" -> codegen -> profile
| then hand optimize. That is, for things which lend themselves
| well to MATLAB.
| zwieback wrote:
| That sound fun, what kind of problems do you use it for? I
| can imagine inner-loop type math stuff but would be leery of
| larger chunks of code.
| loxias wrote:
| Most of the things I'm interested in are signal processing
| oriented. Things where it's very easy to structure the
| solution to the problem as dataflow/boxes and arrows.
| Essentially, "things that lend themselves well to MATLAB"
| ;-)
|
| (to be more concrete, because I personally hate vague
| answers when I want specifics) I've done a _lot_ of array
| processing sound stuff, microphone array processing and
| calibration, as well as computational music stuff with this
| framework. Also built a mostly vision-based pipeline this
| way, calculating how "awake" a mouse is from a video feed
| for medical applications.
|
| > I can imagine inner-loop type math stuff but would be
| leery of larger chunks of code.
|
| 100%. I'd never structure an application this way, but it's
| pretty great if you structure your larger code to be
| modular enough and then have certain processing elements
| done via codegen from MATLAB. What I love is getting bit-
| for-bit accuracy with the math from MATLAB. Of course, you
| then do things to get more performance by sacrificing
| accuracy, but it's great to start off from a place of
| knowing with certainty that the math is right.
| _aavaa_ wrote:
| I don't see the justification for the end user to do their
| programming in C++ versus Python+Numpy or Julia.
|
| Python is already the de facto replacement for Matlab in academia
| and engineering.
|
| And Julia is up and coming, offering many of the benefits of
| Python+Numpy but designed with performance in mind.
|
| Why should I bother with compilers and make files and deal
| locating memory and all the rest of C++?
|
| Because that's what I'll have to deal with as soon as I take one
| step outside of Castor's (admittedly friendly syntax) and with to
| do other things in the same language.
| zwieback wrote:
| If you're already a C++ programmer this kind of thing is great
| since a lot of us already prototype in Python or Matlab so a
| glidepath to C++ is helpful. Otherwise I agree, prob go with
| Python.
| vsskanth wrote:
| The biggest advantage is the ability to deploy the code as
| static binaries to be used in other applications. Not needed if
| you're just scripting and plotting but a huge deal if a
| scientists fancy numerical code needs to be used in production
| once you're done prototyping.
| gumby wrote:
| Why? Speed and integration.
| _aavaa_ wrote:
| 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.
| gumby wrote:
| > 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_ wrote:
| > 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 wrote:
| 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 wrote:
| 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 wrote:
| > 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).
| adgjlsfhk1 wrote:
| 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)
| melissalobos wrote:
| 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 wrote:
| 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)
| pjmlp wrote:
| I also imagine that with C++17 or higher tooling,
| alongside something like CINT, it starts to feel quite
| productive.
| artemonster wrote:
| Usually say people that don't do anything serious besides
| plotting some basic graphs :)
| patrick451 wrote:
| > Python is already the de facto replacement for Matlab in
| academia and engineering.
|
| Maybe in some disciplines, but in control engineering,
| basically everybody still uses Matlab. The python control
| systems libraries are a cheap joke compared to what Matlab
| offers.
|
| The benefit of Julia vs c++ is questionable. Every time you run
| your program, you have to wait for it compile anyway with
| Julia. With c++, I pay this cost once, not every run. They keep
| claiming time-to-first-plot is better. When I tried it a couple
| weeks ago, it still took __minutes__ to produce a single,
| simple plot. JIT makes Julia not only frustrating to use, but
| worse, makes it unsuitable for integration into real time
| systems. So for a lot of applications, I have to rewrite the
| algorithm anyway whether I use Julia or python. So something
| like castor (especially with it's integrated plotting!) could
| save me time from re-writing.
|
| As for the compilers and makefiles? Well, Julia's
| module/include/import system is worse. At least with a
| makefile, all the state is in contained within the local build
| directory, not some global cache julia magically creates.
| zwieback wrote:
| Tangent - what kind of "control engineering" are you using
| Matlab for? I call myself a "controls engineer" sometimes
| because I PID tune the occasional servo motor or write some
| PLC-like code but for the most part we use traditional coding
| (C#, C++ or similar) techniques.
|
| Are you talking about much larger systems or more complex
| stuff that requires real controls theory?
| adgjlsfhk1 wrote:
| How were you making the plot? On my computer, I see time
| julia -e "using Plots; plot(exp)" taking 13 seconds (and I
| haven't done anything fancy). If it's taking significantly
| longer than that, something is very wrong.
| Rexxar wrote:
| 13s seems horribly slow to draw a plot.
| klyrs wrote:
| Generating a similar plot in Python takes less than half of
| a second, including startup time. While 13 seconds isn't
| "minutes" it's still egregiously slow.
| adgjlsfhk1 wrote:
| Yeah. It's the main pain point of Julia. For me, it's not
| really a problem since for interactive use, I mainly use
| a repl which stays open for hours, and for production use
| cases, you can make a system image (which essentially
| caches all the compilation ahead of time).
|
| Also, this is a major focus of current Julia development.
___________________________________________________________________
(page generated 2022-04-18 23:02 UTC)