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

The compiler will optimize that away

blog.royalsloth.eu

Post reply on HN
Print view View original

181–190 of 329 posts

Re: The compiler will optimize that away

#181

Post by astrange »

dnautics wrote: post #169
astrange wrote: post #157

Earlier quoted context omitted.

Haskell uses linked lists as a metaphor for generators (since it's a lazy language), which is a strange decision since linked lists are a bad data structure, so you have to write the program to avoid accidentally ever doing what it says it does.

> linked lists are a bad data structure Why is that? They're perfectly fine for most purposes, and have the advantage that when you pass one across a function boundary the callee can play with it or modify it or do whatever the hell they want and when the callee returns, the caller's linked list is untouched. That's an incredibly valuable feature for correctness and safety.

They have poor cache performance when you want to iterate over them, and more size overhead, because there's one pointer lookup per item. Also, the common definition of a linked list has the list responsible for allocating each item, meaning it can't be a member of more than one list at once. The actual useful version of this is called instrusive linked lists, which isn't the one taught.

> That's an incredibly valuable feature for correctness and safety.

Are you thinking of something else? That's an effect of call by value, but linked lists actually aren't good at that and you have to copy them to pass them around. You need something like these to make it efficient:

https://en.wikipedia.org/wiki/Finger_tree

https://en.wikipedia.org/wiki/Read-copy-update

Re: The compiler will optimize that away

#182

Post by jayd16 »

lordnacho wrote: post #13

Good article. My own thinking when coding performance is also towards data oriented approaches. For example Bevy in Rust. If stuff needs to be fast, it needs to be in cache. To do that, have everything nicely packed so you only ask for a chunk as often as you need. Then when you need it, it's already there. Thing about old fashioned OO is it's often fine enough for your run-of-the-mill CRUD app. If you look at the la…

I always laugh when people talk about ECS vs OO as if the entities, components and systems weren't objects. Its an OO pattern.

Even in the most abstract form when entities are just ids, and you combine components and systems, you're still going to implement the component-system like an object because OO is super useful. Using arrays doesn't mean you're not using OO.

Re: The compiler will optimize that away

#183

Post by jayd16 »

corysama wrote: post #133
29athrowaway wrote: post #130

Earlier quoted context omitted.

Shit is slower than it was in the 90s. Spotify is slower than Winamp, Slack is slower than IRC, Webmail is slower than my e-mail client, VS Code is slower than Visual C++ 6.0.

People forget that Winamp was instant on a 60Mhz machine with a spinning rust drive. It’s difficult to buy a computer that slow these days. Modern CPUs modulate their speeds by far more than that as part of their moment by moment power management!

Winamp didn't stream all music in existence over the internet. How is it really comparable?

Re: The compiler will optimize that away

#184

Post by jayd16 »

esailija wrote: post #87
jupp0r wrote: post #79

The implicit premise of the article seems to be that all software has to be heavily optimized. This is completely wrong. All the languages mentioned in the article are still around because it doesn’t matter how performant 99% of code is. For the 1%, we can think about cache misses, SIMD and data parallel approaches. In my experience this is totally possible and not too hard, but has the enormous downside of making th…

I disagree. Almost all software I use these days is absurdly slower than it should be and probably a massive drain on collective productivity. I have ssd, fast internet, 64gb ddr4 etc, almost everything I do should be impercetibly instant but instead takes seconds and even minutes. Yeah of course most of that slowness is not even because of ignorance of the low level stuff but complete disregard of performance aspect…

I think you missed the point. Parent is saying that without compiler optimization everything would be even slower.

Re: The compiler will optimize that away

#185

Post by CornCobs »

Tyr42 wrote: post #71
beagle3 wrote: post #42

> So far, the only programming language I know of that supports this type of crazy data transformations is JAI, As far as I know JAI is indeed the only language that explicitly lets you switch between AoS and SoA with one bit, but the APL family of languages - (APL, J, K, Shakti, and a couple more) has basically - for 60 years no - taken the "data oriented" SoA approach for storage, and provides the language support…

I also think that it's a shame he didn't bring up NumPy & Pandas, or R. He's just created a data frame and then complained that there's no functions to sort it, but we do have those. They are here. ants = pd.DataFrame({ "name": ["bob", "alice", "carol"], "color":["red", "blue", "red"], "age":[1.1, 0.5, 1.2], "warrior":[True, False, True]}) # Or read_csv to get the data in. # Count number of warriors. True => 1, False…

Yeap. I think Pandas could and should see a lot more use outside data science as performant in-memory data storage in Python.

The best thing is? Most data scientists don't even care about SoA vs AoS - tabular structure is easy to grok, easy to use AND performant by default!

Re: The compiler will optimize that away

#186

Post by Firehawke »

jayd16 wrote: post #183
corysama wrote: post #133

Earlier quoted context omitted.

People forget that Winamp was instant on a 60Mhz machine with a spinning rust drive. It’s difficult to buy a computer that slow these days. Modern CPUs modulate their speeds by far more than that as part of their moment by moment power management!

Winamp didn't stream all music in existence over the internet. How is it really comparable?

It had Shoutcast.

Re: The compiler will optimize that away

#187

Post by masklinn »

beagle3 wrote: post #42

> So far, the only programming language I know of that supports this type of crazy data transformations is JAI, As far as I know JAI is indeed the only language that explicitly lets you switch between AoS and SoA with one bit, but the APL family of languages - (APL, J, K, Shakti, and a couple more) has basically - for 60 years no - taken the "data oriented" SoA approach for storage, and provides the language support…

> Additionally, Nim macros (and I suspect Rust and D as well)

Aye somebody posted their SoA library on /r/rust just a few days back (https://crates.io/crates/soa_derive), and I don’t think it was the first such.

Re: The compiler will optimize that away

#188

Post by cma »

antpls wrote: post #114
theamk wrote: post #2

Summary: the computer has changed -- memory latency measured in CPU cycles has grown a lot. So we should not be using traditional struct/class-like programming model, where we put all properties of an object next to each other. Instead, we should be using game-style "data oriented programming" a.k.a. "column databases" for a much higher performance. However, most modern languages (C, C++, Python, Java, etc..) are not…

columnar layout is only faster if reads are sequential

If things work one or a few columns at a time this isn't necessarily true. Prosumer CPU L3 caches are already up to 128MB and will be up to 1GB before long. If one or a few full columns fits fully in cache but all the data doesn't, columnar layout may still be faster in the face of random access within the column.

Re: The compiler will optimize that away

#189

Post by jayd16 »

Firehawke wrote: post #186
jayd16 wrote: post #183

Earlier quoted context omitted.

Winamp didn't stream all music in existence over the internet. How is it really comparable?

It had Shoutcast.

Was Shoutcast all that fast? It didn't seem nearly as rock solid as the rest of winamp but I guess it could have been my internet at the time.
Post reply on HN