Implications of Rewriting a Browser Component in Rust

Re:Implications of Rewriting a Browser Component in Rust by ianlevesque on Thursday February 28, 2019 @11:52AM (#19272732)

I use Java constantly in my job and recently tried rewriting a math & memory heavy component in rust to see what performance gains there might be. Surprisingly (to me) the naive rust version was ~15% slower than Java. There’s probably room for more rust optimization but it was interesting that “efficient standalone binaries” doesn’t automatically mean faster too when competing with HotSpot.

[ Parent | on HN ]

Re:Implications of Rewriting a Browser Component in Rust by carlmr on Thursday February 28, 2019 @11:58AM (#19272781)

I find where rust usually shines the most is if you do text processing. String allocations take time. In rust you can often avoid them and use things like cow to only allocate when you change something. That way often my text processing heavy scripts go twice the speed of a C++ version, and they're easier to write with Cargo, too.

Compared to highly optimized Java and C# I could often get a quite naive rust implementation to be 10x faster.

Naive rust means I didn't spend much time optimizing but I do use appropriate algorithms and to avoid unnecessary allocations.

[ Parent | on HN ]

Re:Implications of Rewriting a Browser Component in Rust by pjmlp on Thursday February 28, 2019 @11:58AM (#19272779)

Google had a fast math library for Android, which got outperformed by ART JIT compiler and was eventually deprecated.

https://developer.android.com/reference/android/util/FloatMa...

[ Parent | on HN ]

Re:Implications of Rewriting a Browser Component in Rust by QuercusMax on Thursday February 28, 2019 @12:03PM (#19272837)

My experience working on writing image processing code in Java is that rewriting the slowest bits in C++ only gave about a 10% performance boost, and this was over a decade ago. Moving stuff to the GPU was vastly more effective than doing faster CPU work.

[ Parent | on HN ]

Re:Implications of Rewriting a Browser Component in Rust by alex_duf on Thursday February 28, 2019 @12:34PM (#19273142)

When comparing speed on the JVM with speed with native languages, the only positive side you get from native binaries is cold start nowadays.

For a webapp this doesn't matter, but as we're moving towards more cloud functions it start to make a lot of sense.

That needs to be ponderated by the fact any real life application will have to access the network at bootstrap to load configuration and therefore your bottleneck will most likely be I/O.

[ Parent | on HN ]

Re:Implications of Rewriting a Browser Component in Rust by chrisweekly on Thursday February 28, 2019 @12:48PM (#19273299)

> "ponderated"

Huh! I have a fairly strong vocabulary and thought this might have been a made-up word -- but apparently it means "to weigh down or give substance to", which aligns with your intended point here. TIL

[ Parent | on HN ]

Re:Implications of Rewriting a Browser Component in Rust by alex_duf on Friday March 01, 2019 @05:26AM (#19279317)

Sorry that's directly brought from French.

English is my second language. I did a quick google search just to make sure it was correct but it's hard to gauge if a word that happen to be in the dictionary is also widely understood.

[ Parent | on HN ]

Re:Implications of Rewriting a Browser Component in Rust by vbezhenar on Thursday February 28, 2019 @12:47PM (#19273277)

The main performance gain would be memory consumption.

[ Parent | on HN ]

Re:Implications of Rewriting a Browser Component in Rust by ahartmetz on Friday March 01, 2019 @01:02AM (#19278304)

I remember reading an article about Java performance many years ago. It had an example for Java being faster than C++ and it was maths on arrays / matrices. I guess that kind of code least trips up HotSpot optimizations, so it wins due to availability of runtime information and a really good implementation of certain parts.

Though I doubt that Java usually wins against the Eigen C++ library. Eigen uses some template tricks to fold operations together (which can avoid intermediate storage and unlocks more types of restructuring optimizations) and uses SIMD extensively.

[ Parent | on HN ]

Re:Implications of Rewriting a Browser Component in Rust by pjmlp on Friday March 01, 2019 @02:34AM (#19278619)

Probably not, however Hotspot got some Intel help regarding auto-vectorization, including AVX support.

[ Parent | on HN ]

Re:Implications of Rewriting a Browser Component in Rust by mrath on Thursday February 28, 2019 @04:41PM (#19275492)

I would except best performing Java code to be slower than best performing Rust code. But comparing general cases is not going to be simple.

[ Parent | on HN ]