What scientists must know about hardware to write fast code (2020) • Hacker News Board

Re: What scientists must know about hardware to write fast code (2020)

#71

Post by detourdog » Fri, Oct 06, 2023, 10:54 AM UTC

sundarurfriend wrote: post #67

detourdog wrote: post #31

Earlier 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.

Do you mind mentioning what browser it is? It works fine on Firefox, and I presume Chromium-based browsers too (since this article has gone through a few rounds and I haven't heard anyone else complain, though some of that was before it became this "notebook" version and was a static page instead). Is it one of those instances where you have Javascript disabled and the page assumes your browser is just not capable of…

I was on ancient version of safari. I use for browsing. I completely understand why it wouldn’t work. I just feel that information published on the web should degrade to a useful state for consumption.

The HN description actually referred to nicely layered technical abstractions. Which is why I had clicked the link. The description of Julia as being Lisp like. Thank you for taking an interest. I sill go see if a newer safaru works.

Re: What scientists must know about hardware to write fast code (2020)

#72

Post by th0ma5 » Mon, Oct 09, 2023, 4:27 AM UTC

eesmith wrote: post #63

th0ma5 wrote: post #59

Earlier quoted context omitted.

I can't imagine anything worse than something that is not appropriate for the abstraction... eg https://en.m.wikipedia.org/wiki/Leaky_abstraction Again redefining these things here... if the language has tools for all of inline raw chip specific instructions, compiler optimized versions of those instructions, virtualized and then optimized instructions, a jit compiler, and then also high level interpreter operations,…

> Leaky_abstraction Ummm, CPython is also leaky abstraction. Parts of the C implementation, like garbage collection, id(), 'a is b' checks, the ast and dis modules, and more. It even has the beginnings of JIT support. The leaky abstraction thesis is that all layers leak. Julia's argument is that if you have all of these levels anyway, do it in one language instead of two. If you don't like leaky abstractions, you sho…

> Just because you don't see how something can be true, that doesn't mean it isn't true.

This is also a non-answer and I don't mean to be flippant but if you have any further justification I'd love to read it. It is the core of the argument you're handwaving away.

Re: What scientists must know about hardware to write fast code (2020)

#73

Post by Nevermark » Mon, Oct 09, 2023, 11:50 PM UTC

th0ma5 wrote: post #61

suavesito wrote: post #56

Earlier quoted context omitted.

And exactly that is one of the things Julia was designed for, you don't need two languages to get the performance. This allows to have even more flexibility, you can write allocation free, copy free, SIMD code from top to bottom, because it is a single language. That is not possible on other languages, because you have the high-low level language/library distinction. And if you do (JAX?), then you have made what Juli…

How do you define "abstraction" then, I don't see how that is beneficial to obfuscate at which level things are happening.

For abstractions think: automated memory management, rich class/object libraries, idiomatic libraries, compilers that recognize and vectorize common usage patterns, runtime error handling, dynamic typing, etc.

That's not obfuscation, its faster code development, easier to read code, simpler maintainability.

Everything at a higher level than stack, manual heap, processor instruction, registers, explicit addressing and modes, direct I/O, and networking primitives level.

To have all that help, but still be able to drop down to the lowest level, in one consistent toolset is really nice for development and reliable sharing.

(Only a Julia fan at a distance! Not had the pleasure.)

Re: What scientists must know about hardware to write fast code (2020)

#74

Post by th0ma5 » Tue, Oct 10, 2023, 4:22 AM UTC

Nevermark wrote: post #73

th0ma5 wrote: post #61

Earlier quoted context omitted.

How do you define "abstraction" then, I don't see how that is beneficial to obfuscate at which level things are happening.

For abstractions think: automated memory management, rich class/object libraries, idiomatic libraries, compilers that recognize and vectorize common usage patterns, runtime error handling, dynamic typing, etc. That's not obfuscation, its faster code development, easier to read code, simpler maintainability. Everything at a higher level than stack, manual heap, processor instruction, registers, explicit addressing and…

I guess this sounds nice but I wouldn't want to be told that I should just learn assembler, or that if I know assembler that I'd have to put up with whatever high level memory management scheme that I'd have to work around, etc...

Re: What scientists must know about hardware to write fast code (2020)

#75

Post by th0ma5 » Tue, Oct 10, 2023, 4:23 AM UTC

sundarurfriend wrote: post #68

th0ma5 wrote: post #40

Earlier quoted context omitted.

To me, that's the big hand wavy thing is that that thing where if you just do the straightforward obvious thing it's fast, most real world problems aren't straightforward and obvious and therefore turn into something more complex. And now you've got a big can of worms because it was quick in the unspecial case. But now you have no real easy way to get to your special case working correctly without learning more and s…

> But now you have no real easy way to get to your special case working correctly without learning more and spending more time just like any other language That's a big hand wavy thing right there: "spending more time" is not a binary, and "just like any other language" ignores the massive differences there are in how much time you have to spend, what resources are available to you from the language, and how easy the…

At every level of abstraction there is a lot of learning in that context, but now you demand it across all levels simultaneously.

Re: What scientists must know about hardware to write fast code (2020)

#76

Post by eesmith » Tue, Oct 10, 2023, 9:44 AM UTC

th0ma5 wrote: post #72

eesmith wrote: post #63

Earlier quoted context omitted.

> Leaky_abstraction Ummm, CPython is also leaky abstraction. Parts of the C implementation, like garbage collection, id(), 'a is b' checks, the ast and dis modules, and more. It even has the beginnings of JIT support. The leaky abstraction thesis is that all layers leak. Julia's argument is that if you have all of these levels anyway, do it in one language instead of two. If you don't like leaky abstractions, you sho…

> Just because you don't see how something can be true, that doesn't mean it isn't true. This is also a non-answer and I don't mean to be flippant but if you have any further justification I'd love to read it. It is the core of the argument you're handwaving away.

I know little about Julia. I do know that advocates for Lisp also make similar claims, so I don't see it as that exceptional.

Not surprisingly, Julia draws on Lisp's macro abilities to achieve similar goals. Julia is also influenced by Dylan, another ALGOL-like Lisp variant.

If Julia does do what you say you don't believe it can, how would you learn that you were wrong?