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

Case Study: Npm uses Rust for its CPU-bound bottlenecks [pdf]

rust-lang.org

Post reply on HN
Print view View original

271–280 of 307 posts

Re: Case Study: Npm uses Rust for its CPU-bound bottlenecks [pdf]

#271

Post by spricket »

truth_seeker wrote: post #217

I have my doubts and confusion about this problem statement > Most of the operations npm performs are network-bound and JavaScript is able to underpin an implementation that meets the performance goals. However, looking at the authorization service that determines whether a user is allowed to, say, publish a particular package, they saw a CPUbound task that was projected to become a performance bottleneck. Oh, Really…

My guess is that this uses public key cryptography. Generating a signature is rather expensive. We found this out the hard way a few years ago, when we tried to verify OAuth tokens using RSA rather than HMAC.

The server was hammered at maybe 500 signatures a second, greatly slowing down token generation.

I'm guessing they dropped to Rust so they could use native C libraries for signature generation.

Re: Case Study: Npm uses Rust for its CPU-bound bottlenecks [pdf]

#272

Post by est31 »

pcwalton wrote: post #146
paulddraper wrote: post #117

Earlier quoted context omitted.

> New java versions do break existing libraries or apps Have you used the Rust compiler? My experience tells me that any Github Rust project not updated in the last two years doesn't work with my Rust compiler. Whereas Java apps written a decade ago still compile and run on OpenJDK/Oracle often with zero or near zero changes. > Often an architect or software team will insist on using the Oracle JVM rather than the in…

> My experience tells me that any Github Rust project not updated in the last two years doesn't work with my Rust compiler. Please file bugs against the Rust compiler then, because that would be a serious violation of the compatibility rules!

This has less something to do with Rust itself but the ecosystem, but once I updated my system and obtained a newer version of openssl on my OS.

Sadly, some of my projects still used an older version of the openssl crate somewhere inside their crate tree.

The openssl-sys crate author chose to check that the native library version it was compiled against was below a certain version, so it broke. All requests by users to fix the legacy bug were deflected with the mantra "go update the openssl crate the fixed version is out since a year already"...

https://github.com/sfackler/rust-openssl/issues/994

https://github.com/sfackler/rust-openssl/pull/1001

Re: Case Study: Npm uses Rust for its CPU-bound bottlenecks [pdf]

#273

Post by throwaway66666 »

Outpox wrote: post #90
tyingq wrote: post #80

Earlier quoted context omitted.

From the paper it appears to be an authorization service that decides what rights a particular user has. Not a webserver or CDN. It mentions it being CPU bound, though it isn't clear to me why it would be, or why JS wouldn't work well enough for that.

Well I'd say that if it's an authorization service there will be cryptographic calculation which is "heavy" on the CPU.

Users who suggest cryptography are getting downvoted (myself included). I am curious as to why. Is it perceived as spam or an attack on nodejs? Encrypted cookies and JWT (json web tokens) rely on a similar strategy so this is pretty standard. It would be pretty secure as long as the encryption key is not unique, so definitely not criticism on the NPM team but mere theories as to why a (what one would assume is a) database or memory bottle-neck is being presented as a CPU bottleneck in this scenario.

Re: Case Study: Npm uses Rust for its CPU-bound bottlenecks [pdf]

#274

Post by amluto »

IsaacSchlueter wrote: post #173
mattashii wrote: post #119

Earlier quoted context omitted.

> Which is roughly the equivalent of every single human being downloading two npm packages per week The current human population of earth is about 7.7 billion, so that number should probably be closer to 1.17 npm packages per week per human being. That is still quite a lot, though

This highlights the problem of averages. Most (99.87% or so) humans download zero npm packages. But those that do, often download them in the thousands at a time. And yes, clean-room CI servers are a big part of that.

Perhaps npm could save themselves oodles of money by supplying a nice turnkey npm package cache and requiring major users to use it.

And perhaps the CI server folks would want this anyway because it would be vastly faster.

Re: Case Study: Npm uses Rust for its CPU-bound bottlenecks [pdf]

#275

Post by Impossible »

ndesaulniers wrote: post #268
atoav wrote: post #60

Earlier quoted context omitted.

It depends, I am over a year in Rust and it doesn't take me that much longer to write something in it than say in Python. The confidence I have that the thing I wrote is way higher in Rust and it is usually much faster. And: it is incredible easy to build and deploy. I think whether Rust is useful or not depends entirely on the application. If you need high confidence in what the thing is doing, it should run paralle…

> I tried too much to use OOP, which doesn't make any sense and leads to convoluted code. Oh, well, you don't need Rust for that! :P

Yes the same is true with C++ or C# for example, which is were the move out away from OOP and towards DOD/ECS started.

Re: Case Study: Npm uses Rust for its CPU-bound bottlenecks [pdf]

#276

Post by saagarjha »

rkkautsar wrote: post #211
saagarjha wrote: post #199

Earlier quoted context omitted.

…so would Cargo? If you install a new package, why wouldn’t you expect it to show up in your lock file?

No, you guys don't understand.. npm updates the package lock even when not adding a new package, i.e. the initial `npm install`. It's insane I'm think to go back to yarn again..

Hmm, that's pretty stupid. What is the rationale behind this? That you check before you run an install?

Re: Case Study: Npm uses Rust for its CPU-bound bottlenecks [pdf]

#277

Post by [deleted] »

spdionis wrote: post #174
IsaacSchlueter wrote: post #162

Earlier quoted context omitted.

That is incorrect. Both `npm install` and `npm ci` respect the lock file, and if a lock file is present, will make the `node_modules` tree match the lock file exactly. `npm ci` is optimized for a cold start, like on a CI server, where it's expected that `node_modules` will not be present. So, it doesn't bother looking in `node_modules` to see what's already installed. So, _in that cold start case_, it's faster, but i…

> Both `npm install` and `npm ci` respect the lock file This is not correct. `npm install` will update your dependencies, not install them, disregarding the package versions defined in the lock file. It feels like you are not getting the point of having a lock file in the first place. It should be obvious that you can't do an install (which npm calls ci) if you don't have a lock file. The lock file represents your ac…

[deleted]

Re: Case Study: Npm uses Rust for its CPU-bound bottlenecks [pdf]

#278

Post by db48x »

paulddraper wrote: post #232
db48x wrote: post #227

Earlier quoted context omitted.

Of course it's not suitable for production, but it was still quite common to look at a rust project and find that it used the nightly compiler.

It's been awhile, but if memory serves tons of stuff was using the nightly compiler. So, yes buyer beware. But when the whole ecosystem does it...

Exactly. I think it's getting better now that some of the cool things people were waiting on have made it into the 2018 edition. Off-hand I know that Remacs switched from the nightlies to 2018.

Re: Case Study: Npm uses Rust for its CPU-bound bottlenecks [pdf]

#279

Post by mavelikara »

cryptica wrote: post #238

The idea that some programming languages can solve scalability issues is a myth. A language cannot solve scalability issues; all they can do is push the needle a tiny little bit further in terms of performance but this is completely meaningless. Scalability is an architectural concern which cannot be ignored by system developers. This is because scalability is not about speed or performance, it's all about figuring o…

> The idea that some programming languages can solve scalability issues is a myth.

True.

> A language cannot solve scalability issues; all they can do is push the needle a tiny little bit further in terms of performance but this is completely meaningless.

> Scalability is an architectural concern which cannot be ignored by system developers.

A language can prevent or delay such architectural concerns from being addressed by not offering sufficient capabilities.

Re: Case Study: Npm uses Rust for its CPU-bound bottlenecks [pdf]

#280

Post by simion314 »

acdha wrote: post #254
simion314 wrote: post #248

Earlier quoted context omitted.

Isn't this default better for average Joe that runs a Java desktop app, and developers that deploy apps should know how to change this defaults?

How is it better for something to stop working but not exit? It’s exceedingly uncommon for anyone to have correct handling for OOM exceptions so the most likely effect is that stuff partially works - servers accept requests but never respond, apps have menus/buttons which don’t work, etc. Similarly, if developers who deployed apps knew enough to avoid this, we’d know by now because it wouldn’t happen so frequently. I…

You are probably right for this case, my initial comment was related to performance tuning configuration, the comment I replied sounded like JVM should have had X set to my preferred value or "I prefer software that has no options to confuse me with aka GNOME mentality"
Post reply on HN