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

241–250 of 307 posts

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

#241

Post by throwaway66666 »

tyingq wrote: post #99
Quenty wrote: post #92

Earlier quoted context omitted.

The paper makes it clear they were evaluating languages based upon efficiency. The rust implementation was more efficient than the JS one. A CPU bound service of course is bottlenecked at the CPU, and this benefits from efficiency. At scale, it makes sense to replace this with Rust. Javascript did the job, but did not provide the same efficiency as Rust.

I'm not clear on why this is particularly CPU heavy, though: "the authorization service that determines whether a user is allowed to, say, publish a particular package"

My gut feeling is that the user keys are not random generated, but actually encrypted strings that contain the permission values. Decrypting them with modern encryption algorithms (like ChaCha) is pretty CPU intensive.

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

#242

Post by atoav »

tedunangst wrote: post #223
dbaupp wrote: post #205

Earlier quoted context omitted.

You're misreading your parent. The download only happens for the first build using a new dependency. As they mention, once the version is written into the Cargo.lock file, that is the exact version that is used until there is an explicit update step run.

What does "if there is a new version" mean then? If it's a new dependency, there's no old version.

Sorry, english is not my first language, I meant this: When you build initially the used dependencies get downloaded. Only if you [A] update, [B] add a new dependency or [C] clean your project and build it again there will be new things downloaded.

If you update the versions in your Cargo.lock are ignored and updated if the build is sucessful.

If you add a dependency only that depndency is downloaded, the rest is kept as you had it.

If you clean it is as if you cloned that project fresh with git and you will have to download all dependencies. If there is a lockfile the exact versions from it will be used.

To me this is extremely flexible and works very well AND you get precise control over versions if you want it. By the way it is also possible to clone all dependencies and keep a local copy of them, so you are really 100% sure that nothing could ever change with them. Although I am quite sure crates.io doesn't allow changes without version number change, which means you should be save as long as you rely on the version number.

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

#243

Post by Dylan16807 »

andy_ppp wrote: post #190
Dylan16807 wrote: post #159

Earlier quoted context omitted.

> Anything will be CPU-heavy if you give it enough work. Not in a relative sense. If authorization is 5% of the work, scaling it leaves it at 5% of the work, and it's never a bottleneck. Authorization was being a significant bottleneck, not a tiny percent, and that is somewhat surprising.

Obviously authorisation will be a huge overhead compared to sendfile + nginx right? Am I misunderstanding what npm does?

I mean, to use sendfile you need to open the file, and that does a permission check too...

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

#244

Post by rolleiflex »

fwip wrote: post #210
spdionis wrote: post #169

Earlier quoted context omitted.

Except that npm will gladly update your lock file when you run npm install which is insane.

Npm hasn't done this in over a year.

The current version of npm does this and this is "correct behaviour". I got bitten by this a few weeks ago.

For the passers-by, the only way to make npm behave expectedly in this specific case is to use "npm ci" instead of "npm install". If you do not do this, npm will assume you want to update the packages to the latest version at all times, at all costs, even if you have a lock file in place, and even if you have your package file and lock file locked to exact versions. (i.e. 2.0.0 exact, not ^2.0.0)

This is a new addition, and it has been added a couple months ago. Before that, you had to check your dependencies into your source control. That might still be the best practice, and likely the only trustable way to get reproducible builds consistently over a longer time horizon.

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

#245

Post by phamilton »

weberc2 wrote: post #91
pjmlp wrote: post #66

Earlier quoted context omitted.

Hardly any different that having to use VTune or perf to optimise C and C++, which require the added steps of recompiling with different flags and redemploying.

I wouldn’t recommend C or C++, but in their defense, you don’t need to worry about tuning as soon as you do on the JVM. Many apps won’t need to bother with it at all (which is good because C/C++ programmers have all manner of other things to worry about that aren’t a concern for modern languages).

There's also a notion of failure mode for improperly tuned apps. This is certainly a personal preference, but I prefer true failures over constraint failures. I'd rather OOM in golang than run out of threads in my Java execution context while having plenty of free memory. At least when starting out.

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

#246

Post by tyingq »

kbenson wrote: post #240
derefr wrote: post #67

Earlier quoted context omitted.

Does every language have to be suitable for every task? “Operating a business-logic-embedding CDN at scale” isn’t ever something Node claimed to be capable of. I wouldn’t expect any other dynamic runtime-garbage-collected language, e.g. Ruby or Python or PHP, to be suited to that use-case either. Use the right tool for the job. The PHP website is running PHP, but it isn’t running a web server written in PHP. Web serv…

> The PHP website is running PHP, but it isn’t running a web server written in PHP. Are you sure? I'm not familiar with the PHP.net architecture, and there may be less gains from how PHP has traditionally tied itself as a module to web servers in the past, but Rails (and any number of other dynamic language frameworks) are actually web servers implemented in that language, with an optional separate web server such as…

Their mirroring page suggests they most likely use Apache.

"NOTE: Some of our maintainers prefer to use web servers other than Apache, such as Nginx. While this is permitted (as long as everything ultimately works as directed), we do not officially support these setups at this time"

http://php.net/mirroring.php

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

#247

Post by spricket »

While I'm a big fan of Rust, excluding Java because "JVM" is kinda laughable. It's not hard to run at all. You package everything into a jar then run a single command. As easy to get working as a JS backend.

If their complaints are about GC tuning, is it not the same thing as tuning the GC in Js/Go? Java still had arguably the more mature GC of any language

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

#248

Post by simion314 »

acdha wrote: post #231
simion314 wrote: post #178

Earlier quoted context omitted.

But if you do not have options then what is a "good default" , you have a default option if you have more then an option, so you prefer software with no options? Can you give examples of languages(compilers or VMs with bad defaults in your opinion?

Java by default has a hard memory limit which when hit causes services to hang in a semi-responsive state rather than exiting cleanly, requiring every user to hand-tune limits and carefully setup health checks and monitoring. Two decades in, they added a non-standard option to instead exit. If they had instead made the default to act like almost everything else it would have worked with standard process monitors and…

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?

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

#249

Post by simion314 »

weberc2 wrote: post #225
simion314 wrote: post #178

Earlier quoted context omitted.

But if you do not have options then what is a "good default" , you have a default option if you have more then an option, so you prefer software with no options? Can you give examples of languages(compilers or VMs with bad defaults in your opinion?

You can have options and have good default values for those options. Good default values are those that are reasonable for most people most of the time such that they don't need to be (or hire) domain experts to properly configure their tool. My opinion of a bad default would include a language toolchain which defaults to dynamic linking and requires one to opt into static linking (Java, Python, JS, etc, etc, etc). W…

So the JVM run-time is installed and used by average people, so the defaults should be set for this people that install Java to run a desktop app IMO, the developers that want extra performance should read the manual and configure things.

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

#250

Post by rictic »

rolleiflex wrote: post #244
fwip wrote: post #210

Earlier quoted context omitted.

Npm hasn't done this in over a year.

The current version of npm does this and this is "correct behaviour". I got bitten by this a few weeks ago. For the passers-by, the only way to make npm behave expectedly in this specific case is to use "npm ci" instead of "npm install" . If you do not do this, npm will assume you want to update the packages to the latest version at all times, at all costs, even if you have a lock file in place, and even if you have…

> and even if you have your package file and lock file locked to exact versions. (i.e. 2.0.0 exact, not ^2.0.0)

Wait what? Are you sure about that part? That's a violation of npm's semver constraints https://semver.npmjs.com

(I agree with you that "npm ci" should be the default behavior, and "npm install" should be called something different, like update-and-install)

Post reply on HN