7 ms·
Not that relevant, but >Because the Julia language is particularly good at adding new data types without sacrificing speed, several people jumped on making a p
by robinhoodexe 10y ago
Not that relevant, but
>Because the Julia language is particularly good at adding new data types without sacrificing speed, several people jumped on making a port to Julia, including the MIT founders of that language.
I'm really impressed with the Julia language so far and considering implementing some quantum chemistry models for many-body systems (Hartree-Fock and probably Coupled Cluster if I ever get that far). Mostly because a) Julia looks fun, b) FORTRAN is still king of speed (which I'll need all I can get of) but is a pain to write and c) the alternative to FORTRAN is C(++), where being OO isn't that much of a bonus. And Julie looks fun to write.
- dnautics 10y agoJulia is really impressive. So, I uh, was working on a julia implementation of unums till I stopped being funded for it... I'm currently writing unit and continuous tests for a computer chip that is being simulated - basically julia does the computation in x86, which suggests what the IEEE result should be, and then generates the assembler and passes it on to the assembler. It probably could have been easily written in something like python, ruby, or perl, but the modularness of Julia, functional programming, and (optional) explicit typing result in easy-to-read code and a sense of security that there are no shenanigans going on under the hood with the type system. Another cool thing is for more complicated code (working on a demonstration fast fourier transform) is that I can write the core FFT algorithm as a function with macros, and by swapping a different include that defines the macros differently, it can either run it as a virtual processor using internal Julia arrays that represent the memory and register files, or build up a file that contains the assembler code. Again, this is obviously possible in other languages [0], but Julia makes it look nice and easy to comprehend. [0] I'm thinking that ruby (especially with it's DSL-eyness) would be really good for this, but I abandoned ruby when it became too difficult (I'm lazy and dense) to install the correct version on my own computer much less figure out how to install it on a server for other people to use.
- trsohmers 10y agoHere's a link to the WIP Julia unum implementation... https://github.com/REX-Computing/unumjl https://github.com/REX-Computing/unumjl
- azag0 10y agoI started a DFT code in Julia two years ago but didn't get too far. I always felt that I have to think how to make the code fast in Julia (types/vectorization), whereas I just know it will be fast in Fortran. So I always end up writing modern Fortran C-binded to Python. Was it just me not paying enough time to get used to Julia or was/is it a real problem?
- dnautics 10y agoprobably the best way to do it would have been to bind the fortran functions to julia.
- acidflask 10y agoHave you actually profiled the Julia code you wrote and ensured that you have followed the performance tips in the manual? If you did it correctly all the time should be spent in linear algebra operations, and so it shouldn't matter what language you implemented the code in since the performance is primarily determined by your underlying BLAS library.
- azag0 10y agoIt's not that I couldn't make it fast. I followed just the steps you mentioned and got to a really fast code. But the process didn't feel intuitive.
- santaclaus 10y ago> FORTRAN is still king of speed (which I'll need all I can get of) but is a pain to write I'm surprised that, with the restrict keyword, one would see better code gen from Fortran than C. Isn't the lack of aliasing Fortran's primary advantage?
- neutronicus 10y agoLeveraging "restrict" is not a trivial thing to do. If you're a researcher first and a software developer second (which I suspect is true of gp), the last thing you want to do is get into the weeds of inspecting gcc assembly to figure out where you didn't put a "restrict" that you should've.
- deleted 10y ago[deleted]
- eli_gottlieb 10y agoI dunno. I just started doing probabilistic programming in Haskell yesterday, and it's turned out to be faster at it than every other PPL I've tried. It didn't help that WebChurch, Anglican, and Venture are all interpreted languages. Treating a sampler as a lazy stream of samples is a nice abstraction, too.
- neutronicus 10y agoAs a counterpoint, my attempts to write fast Haskell PDE solvers have been underwhelming.
- jfoutz 10y agoOnce you wrap your head around the Haskell way, it seems easy to get something working. IMHO that something will be minimal and pretty as well. Once i try to make things fast, it gets weird. There are people who can write very fast Haskell code, but it seems like all of those people worked on ghc. I don't have a good mental model of when, say, a thunk will get created, so i liberally sprinkle strictness annotations, and fool around with list fusion operations. I really like Haskell. Even with all the effort i've put into it, it seems like i've barely scratched the surface if i want performance. sigh
- marmaduke 10y agoDid you try Stan? It compiles your model to SSE2 enabled c++
- eli_gottlieb 10y agoFor my current problem, I don't want the available inference methods to impose any restrictions on what sort of model I can write, so I'm using general PPL only.
- marmaduke 10y agoYou can write you model in Stan and sample without inference too.
- acidflask 10y agoIt would be really interesting if you'd like to implement some quantum chemistry! Rick Muller (of PyQuante fame) has implemented a port to Julia, but I think there's a lot of room to use more language features. https://github.com/rpmuller/pyquante2/tree/master/julia https://github.com/rpmuller/pyquante2/tree/master/julia Let me know if you do want to do some quantum chemistry coding. It would be good for my soul to revisit some of my PhD roots...