Progress 246/246Ģ46 dependencies successfully precompiled in 140 secondsģ.689727 seconds (6.58 M allocations: 472.965 MiB, 7.49% gc time, 0.13% compilation time) Updating `~/.julia/environments/v1.6/Manifest.toml` Updating `~/.julia/environments/v1.6/Project.toml` Updating registry at `~/.julia/registries/General` The other thing is that Julia is a language where generic functions are a low-level thing all over the standard library whereas Common Lisp has a mix of a few generic functions (er, documentation is one there are more in cltl2), a few “pre-clos” generic functions like mathematical functions, sequence functions and to some extent some array functions, and a whole lot of non-generic functions.Īdmittedly not a huge dataset but the TTFP is significantly shorter.
#Fabled lands java readme code
Julia’s system let’s you write generic numeric matrix code while still having float matrix multiplication done by LAPACK, which seems desirable. And this was not a trivial problem at all.
#Fabled lands java readme how to
I think you’d lose too much in Common Lisp’s hodge-podge type system.Ī big innovation of Julia was figuring out how to make generic functions and multiple dispatch work in a good way with the kind of generic data structures you need for good performance. Your template goes system could probably have (matrix float) as a subclass of matrix, but not of (matrix real) or (matrix number). I guess you could try to hack together some kind of templating feature to make new type-specific classes on the fly, but this won’t work well with subtyping. This breaks (1) a lot of the opportunity for optimisation by inlining (because you can’t assume that all the multiplications in your matrix multiplication are regular float multiplications) or generic code (because you can’t have a generic matrix type and need a special float-matrix) and (2) opportunities for saving memory with generic data structures because the types must be associated to the smallest units and not the container (eg every object in a float matrix must be tagged with the fact that it is a float because in theory you could put a complex number in there and then you’d need to know to do a different multiplication operation). In particular it doesn’t have parameter used types so you can’t make eg a matrix of complex numbers. I'm mostly just pushing back on the notion that Julia doesn't do anything new or interesting.Ĭommon lisp’s typesystem is just not really as useful for this sort of thing. The Common Lisp ecosystem is awesome and can do all sorts of really cool things that I wish we had in julia. To be clear though, I'm not hating on Common Lisp or CLOS. This is not a capability that CLOS or Dylan has as far as I'm aware, though the common refrain is that you can do it with macros, but that neglects that it's rather hard to get right, and will have limited use because such macro implementations of type parameters won't be ubiquitious.
You can specialize methods on matrices of complex integers separately from rank 5 arrays of rational Int8s for instance. I'm not familiar with Strandh's work, but has it made the overhead of generic functions low, or has it completely eliminated it?Īnother thing I'll mention is that Julia's type system is parametric, and we allow values (not just types) in our type parameters which is immensely useful for writing generic high performance code. Julia makes the runtime cost of (type stable) dispatch zero, and hence does not even give julia programmers an *option* to write non-generic functions (though it can be hacked in like with FunctionWrappers.jl). What I'm saying is that because historically people using CLOS had to pay a (often negligible) runtime cost for dispatch, it limited the number of places developers were willing to allow generic dispatch. Yes, I don't doubt at all that it's possible to make CLOS dispatch fast.
0 kommentar(er)
