Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Julia 1.9

julialang.org

Post reply on HN
Print view View original

81–90 of 216 posts

Re: Julia 1.9

#81

Post by freilanzer »

cookieperson wrote: post #78
stdbrouw wrote: post #44

Earlier quoted context omitted.

The flip side to this is that Julia is a great general purpose engineering calculator and simulator. For example, calculating friction in hvac ductwork, voltage drop in long electrical circuits, solar gains for windows or solar panels facing various directions, cost/benefit analyses of thicker or thinner roof insulation and so on... these are all 1 to 10 lines of code so there isn't a big porting cost in moving to Ju…

Yea but the language itself, and it's ecosystem is broken on a regular basis. Again fine if you're an academic, not so great for industry.

How?

Re: Julia 1.9

#82

Post by xmcqdpt2 »

sundarurfriend wrote: post #56

> We came to the conclusion that a global fastmath option is impossible to use correctly in Julia. I'd assumed that global fastmath was a bad idea in general , and assumed that was the reason for making this a no-op. Is there a reason it's particularly bad in Julia, some assumptions the standard library makes or something?

From the example in the article (exp) it sounds like they are implementing highly optimized versions of transcendental functions. This is great! One of the reason gfortran is so much slower than the intel fortran compiler is the slow special functions it uses. However those tricks appear to degrade badly under some LLVM optimizations that are enabled with fastmath.

It makes sense to optimize for the non-fast math case because that's the recommended setting, and I guess having two implementations of all the (very important, easy to mess up, core) special functions + all the testing infra to check that they work correctly on all platforms was probably deemed too much work for marginal benefits.

Re: Julia 1.9

#83

Post by cookieperson »

eigenspace wrote: post #13
huijzer wrote: post #7

I used to have a reasonably simple notebook for a paper which took about 35 minutes to compile on an old university-provided CPU; even when opening it for the second time. Therefore, I‘m really excited for the improvements in code caching! Thanks to Tim Holy, Jameson Nash, Valentin Churavy, and others for your work

> Reasonably simple > 35 minutes to compile What kind of CPU are we talking about here!?

Probably a decent one. Compilation of even small size projects easily took hours as of a year ago. All while people were screaming about how good it was. The equivalent code in other languages would be statically compiled in milliseconds. The size of the binaries was also thousands of times bigger...

Re: Julia 1.9

#84

Post by singularity2001 »

jakobnissen wrote: post #30
singularity2001 wrote: post #29

"Together with PrecompileTools.jl, Julia 1.9 delivers many of the benefits of PackageCompiler without the need for user-customization." does it mean I still have to invoke special workflows and commands to get compilation benefits or does it work out of the box for normal julia invocations?

PrecompileTools works out of the box - in the sense that the package developer needs to add a "@compile_workload" block in their package, but the users don't need to do anything. There is no special workflow or command to use it. The tradeoffs are somewhat larger load times (TTL), increased precompilation time (because some of the compilation moves to precompile time), and increased disk usage by the package.

Fantastic! so far over 100 packages seem to support it which is a good start:

https://github.com/search?q=%40compile_workload&type=code

Re: Julia 1.9

#85

Post by NeuroCoder »

sundarurfriend wrote: post #56

> We came to the conclusion that a global fastmath option is impossible to use correctly in Julia. I'd assumed that global fastmath was a bad idea in general , and assumed that was the reason for making this a no-op. Is there a reason it's particularly bad in Julia, some assumptions the standard library makes or something?

From a non-technical point of view (since the technical answer was already provided) I think this sort of magic optimizations is a double edge sword in any language. No matter what you do there will be corner cases that need manual tuning that become inaccessible behind some init option.

Re: Julia 1.9

#86

Post by cookieperson »

freilanzer wrote: post #81
cookieperson wrote: post #78

Earlier quoted context omitted.

Yea but the language itself, and it's ecosystem is broken on a regular basis. Again fine if you're an academic, not so great for industry.

How?

What do you mean how? Something in base changes, the author of a package didn't put strict enough compatibility on their package and now you can't use the package. It's especially great when this sort of thing happens after spending ten minutes waiting for precompilation an hour for your time to first gradient and three days for a run to complete and you trusted the tool to let you write the results to a CSV using the CSV package(one of the most widely used packages). Then you file a bug report and get gas lit, so you just patch your local Julia version and compile it yourself so you don't wait 4 months for an upstream fix. Good times.

Re: Julia 1.9

#87

Post by NeuroCoder »

I didn't even know some of these things were being worked on until recently. I totally understand why devs don't treat development like a Twitter feed, posting every thought that pops into their head instead of working. However, it would be really interesting to follow some of these developments without having to deep lurk all the PRs.

Sorry, pretty shallow complaint. Great work!

Re: Julia 1.9

#88

Post by ChrisRackauckas »

sundarurfriend wrote: post #56

> We came to the conclusion that a global fastmath option is impossible to use correctly in Julia. I'd assumed that global fastmath was a bad idea in general , and assumed that was the reason for making this a no-op. Is there a reason it's particularly bad in Julia, some assumptions the standard library makes or something?

fastmath is bad in general. In Julia it's not as bad as many other languages because it's attempted to be kept local. The @fastmath macro is essentially a find-replace macro, where it finds things like ^ and replaces it with the fast_pow function which drops the 1ulp requirement. However, this global option was really the one piece left in Julia that where it could creep in, hence the reason to drop it.

There are still some other difficulties of course, since fastmath in the C ABI is quite wild (or I guess, it's really the GCC implementation up to GCC 13 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522#c45)). Simon wrote a nice piece about the difficulties in general: https://simonbyrne.github.io/notes/fastmath/. In a general sense there is still the potential vulnerability that effects the Python ecosystem which is that if any package has binaries built with fastmath it could cause other calculations to be fastmath as well in a non-local way (https://moyix.blogspot.com/2022/09/someones-been-messing-wit...):

> It turns out (somewhat insanely) that when -ffast-math is enabled, the compiler will link in a constructor that sets the FTZ/DAZ flags whenever the library is loaded — even on shared libraries, which means that any application that loads that library will have its floating point behavior changed for the whole process. And -Ofast, which sounds appealingly like a "make my program go fast" flag, automatically enables -ffast-math, so some projects may unwittingly turn it on without realizing the implications.

With Julia, there is the advantage here that (a) most libraries don't have binary artifacts being built in another language, (b) the Julia core math library is written in Julia and is thus not a shared library effected by this, and (c) those that do have their binaries built and hosted in https://github.com/JuliaPackaging/Yggdrasil. So in the binary building and delivery system you can see there are some patches that forcibly remove fastmath from the binaries being built to avoid this problem (https://github.com/search?q=repo%3AJuliaPackaging%2FYggdrasi...). The part (b) of course is the part that is then made globally safe by the removal of the flag in Julia itself, so generally Julia should be well-guarded against this kind of issue with these sets of safeguards in place.

Re: Julia 1.9

#89

Post by jakobnissen »

NeuroCoder wrote: post #87

I didn't even know some of these things were being worked on until recently. I totally understand why devs don't treat development like a Twitter feed, posting every thought that pops into their head instead of working. However, it would be really interesting to follow some of these developments without having to deep lurk all the PRs. Sorry, pretty shallow complaint. Great work!

For developments in latency specifically, check out my blog post: https://viralinstruction.com/posts/latency/

I know this doesn't inform you about dev work on Julia in general, but it goes into detail with the recent improvements to latency

Re: Julia 1.9

#90

Post by sundarurfriend »

NeuroCoder wrote: post #85
sundarurfriend wrote: post #56

> We came to the conclusion that a global fastmath option is impossible to use correctly in Julia. I'd assumed that global fastmath was a bad idea in general , and assumed that was the reason for making this a no-op. Is there a reason it's particularly bad in Julia, some assumptions the standard library makes or something?

From a non-technical point of view (since the technical answer was already provided) I think this sort of magic optimizations is a double edge sword in any language. No matter what you do there will be corner cases that need manual tuning that become inaccessible behind some init option.

That's especially true for `fastmath`, which shoves a bunch of optimization tradeoffs together, some of them "handle with care" territory, some of them in the "faulty live grenade that'll probably explode in your face" territory.

I was just wondering why the post said "impossible to use correctly in Julia" rather than just "impossible to use correctly", but writing it out now, I realize that "impossible" would be hyperbole for the latter, it would be more like "highly likely to go wrong".

Post reply on HN