Solid post. It also shows how powerful Julia is: allowing to operate at different levels of abstractions (down to seeing the assembly) using the same set of tools.
What scientists must know about hardware to write fast code (2020)
31–40 of 76 posts
Re: What scientists must know about hardware to write fast code (2020)
#32This subject is taught in undergrad computer architecture courses along with machine coding. As an EE, I learned it in grad school.
Well, apparently I offended a lot of people by merely providing a piece of information about computer architecture curriculum. I apologize for commenting.
If you had prepended the comment with something like "I love this topic!" to show enthusiasm or approval, you probably would have gotten a much different response.
Re: What scientists must know about hardware to write fast code (2020)
#33Earlier quoted context omitted.
This was the premise of Lisp Machines, unfortunely the industry took another path.
Was it? I thought even in the lisp machine days, lisp was kind of garbage collected, so that was always the bottleneck. I remember a quote that was like “Lisp programmers know the value of everything and the cost of nothing” in reference to that.
GC was a kernel service, and there were low level primitives, including Assembly level Lisp forms.
Parenthesis all the way down to microcode.
Re: What scientists must know about hardware to write fast code (2020)
#34Solid post. It also shows how powerful Julia is: allowing to operate at different levels of abstractions (down to seeing the assembly) using the same set of tools.
The site simply told me I was using the wrong browser. How great of an environment can it be if it can render webpages for everyone.
The site is a staticly published version of a Pluto notebook, which uses modern web features to enable interactivity, reactivity, code syntax highlighting, etc. etc. Tradeoffs to enable those features but requires enabling your browser features. The underlying file that the notebook is based on is just a basic `.jl` file, so you could happily run the notebook from a Julia instance instead of the browser-based notebook environment.
Julia itself will be happy to run however you'd like it to of course.
Re: What scientists must know about hardware to write fast code (2020)
#35Earlier quoted context omitted.
The site simply told me I was using the wrong browser. How great of an environment can it be if it can render webpages for everyone.
Your comment must be more about the environment of the web browser you are using? The site is a staticly published version of a Pluto notebook, which uses modern web features to enable interactivity, reactivity, code syntax highlighting, etc. etc. Tradeoffs to enable those features but requires enabling your browser features. The underlying file that the notebook is based on is just a basic `.jl` file, so you could h…
I thought I was visiting a website.
Re: What scientists must know about hardware to write fast code (2020)
#36Solid post. It also shows how powerful Julia is: allowing to operate at different levels of abstractions (down to seeing the assembly) using the same set of tools.
I feel the biggest misleading statements around Julia is that for true speed you can somehow ignore the lower abstractions, or that there is some kind of free lunch, but always what you gain in performance you'll spend in development time. Julia has some neat tricks, but they are not generally and universally applicable at least not like other languages. I dunno. These arguments against Julia are many, but I'm still…
A good example: there was recently a thread on the Julia discourse comparing Julia and Mojo. Julia used no external libraries (compared to 7 with Mojo) implemented a simpler, faster, and cleaner version of the Mojo code that was used to showcase how fast Mojo was: https://discourse.julialang.org/t/julia-mojo-mandelbrot-benc.... Then further still, folks were able to optimize for even more speed with various abstractions that let Julia take more advantage of the hardware.
That's the promise I think Julia makes and delivers on - you can write incredibly "fast" code simply and cleanly. Yes, you can have a higher standard of "fast" which requires a bit more advanced knowledge but I'd argue that Julia still offers the cleanest/simplest way to take advantage of those micro-optimizaitons.
Re: What scientists must know about hardware to write fast code (2020)
#37In college (for a time) I was a double major in CS and Physics. I found a job as a programmer at a Physics lab, which fit my interests very well. The previous person roughly showed me the ropes for just a few days before she left to go to grad school. The PI started asking me to run some analyses on a raw dataset. Since I was so new at it, I often messed up and had to rerun the whole thing after looking at the output…
To his credit once I (as nicely as possible) showed him how to do it with two nested for-loops he clearly felt stupid and conceded the point. He was otherwise a very smart guy and good to work with, but goes to show how we can take our training for granted. Even freshman-level stuff goes over the heads of PhDs, and I'm sure the same would be true if I were to drop into a biochem lab.
Re: What scientists must know about hardware to write fast code (2020)
#38This subject is taught in undergrad computer architecture courses along with machine coding. As an EE, I learned it in grad school.
Re: What scientists must know about hardware to write fast code (2020)
#39Earlier quoted context omitted.
I agree with this sentiment, like the majority of CS people are telling statisticians that a lot of Julia remains a kind of snake oil or otherwise mystical thinking, it is very unfortunate. Even in the first page of the documentation "No need to vectorize code for performance; devectorized code is fast" is some kind of category error redefinition of how programming languages work in my opinion.
> Even in the first page of the documentation "No need to vectorize code for performance; devectorized code is fast" is some kind of category error redefinition of how programming languages work in my opinion. Can you elaborate a bit? I don't really get what you are trying to say.
Re: What scientists must know about hardware to write fast code (2020)
#40Earlier quoted context omitted.
I feel the biggest misleading statements around Julia is that for true speed you can somehow ignore the lower abstractions, or that there is some kind of free lunch, but always what you gain in performance you'll spend in development time. Julia has some neat tricks, but they are not generally and universally applicable at least not like other languages. I dunno. These arguments against Julia are many, but I'm still…
I don't think that's right. Well, you're right that some enthusiasts of Julia are too quick to say "fast as C, easy as Python" without appending an asterisk to that statement. You can't get really fast performance without paying any attention to the hardware. Performance is on a spectrum, and usually a tradeoff against readability and conciseness. I think it IS true that Julia excels in that it gives, by far, the bes…