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

Spidermonkey has passed V8 on Octane performance

robert.ocallahan.org

Post reply on HN
Print view View original

331–338 of 338 posts

Re: Spidermonkey has passed V8 on Octane performance

#331

Post by kibwen »

shadowmint wrote: post #329
MichaelGG wrote: post #165

Earlier quoted context omitted.

This is misleading. Apart from bugs in the core code (compiler and stdlib) you shouldn't be memory unsafe in an exploitable way. Even segfault from deref null should be rare. It's like saying Java isn't safe because it might call some JNI. While pedantically true, it's qualitatively different. That's why effectively impossible is an OK statement. Unless you go out of your way, your program will not contain such bugs.

I don't accept that 'effectively impossible' means 'can happen, but probably doesn't happen very often'. Rust has many other unsafe code paths than ffi; low level optimisations, dynamic libraries, etc. Unless you go out of your way or are doing low level work, your code will not contain such bugs, and if you used no dependencies that do anything meaningful, what you said is plausibly true. ...but what are we trying t…

Inveterate Rustacean here, and I agree with this. We need to carefully clarify the sort of safety that Rust provides in order to avoid misleading people.

Improperly implemented `unsafe` blocks can cause crashes. APIs that don't properly isolate unsafe interfaces can cause crashes. Bugs in the compiler, bugs in LLVM, and unforeseen unsoundness in the type system can cause crashes. So instead of saying "Rust makes crashes impossible", I'm starting to prefer "If you write only safe code, any crashes that occur are not your fault". A bit less comforting, but still a best-in-class guarantee for a bare-metal language (not to mention that the former claim is impossible in any language).

Furthermore, I think it's important to express to people the true role of `unsafe` blocks, which are not so much "Rust without safety" as they are "reified inline C code with a bit more safety". Rust without `unsafe` blocks could exist, but it would require an enormous amount of FFI and/or much more machinery baked into the compiler itself.

Re: Spidermonkey has passed V8 on Octane performance

#332

Post by WorldWideWayne »

skj wrote: post #321
WorldWideWayne wrote: post #269

Earlier quoted context omitted.

Ever heard of Operation Mockingbird? http://en.wikipedia.org/wiki/Operation_Mockingbird

Project mockingbird, therefore the NSA established Google as a front company for spying on the population?

So, the alphabet agencies have done it before but there's zero probability that they'll do it again right?

Yeah, makes perfect sense.

Re: Spidermonkey has passed V8 on Octane performance

#333

Post by Jweb_Guru »

shadowmint wrote: post #328
Jweb_Guru wrote: post #315

Earlier quoted context omitted.

How often has one of your Rust programs segfaulted for you, when it wasn't a bug in your own unsafe code (as opposed to that in the standard library)? For me, the count still stands at zero. I've been writing Rust for well over a year. I like to abuse new features and I've found many compiler bugs, but my code doesn't crash at runtime. I'm not saying it doesn't happen, and the plural of anecdote is not data, but I th…

Have you used any of the graphical bindings? maybe once a fortnight for me? I'm certainly not trying to bash rust, and I do apologise if it comes across that way. I just think a bit of realism makes everything look much more sincere and plausible. As you say 'Rust cannot crash' is false. 'Rust has never crashed for me' could well be a completely true thing to say. Also, 'Its so much easier to write rust code (than sa…

The safety thing isn't a massive distraction. It's a major part of the point of Rust, whether it's exciting to you or not.

The graphical bindings you're using are not part of the standard library, which is why I specifically asked about that. I know there are bugs in third-party dependencies in Rust, because there are many C bindings that aren't exposed safely by those libraries. I've segfaulted using a TrueType binding library, for example, because it was not actually exposed in a way that prevented double frees. But writing a bad binding is something you can do just as easily in Ruby, or Java. The standard library is what we were originally talking about. I wouldn't disbelieve you if you said you crashed every fortnight using only standard library code, but I would probably press for details.

I am not saying Rust is "completely provably safe", but nothing is. You always have some trusted software or hardware that, if it screws up, will compromise your program. Rust's advantage is that it allows you to be explicit about what parts are trusted and what parts aren't. It vastly reduces the potential attack surface.

Re: Spidermonkey has passed V8 on Octane performance

#334

Post by Dylan16807 »

shadowmint wrote: post #327
Dylan16807 wrote: post #317

Earlier quoted context omitted.

I guess I should have been more explicit that I was talking about the language itself (without the unsafe keyword). Not libraries written in other languages, not compilers. It's the job of theorem provers and whatnot to make those safe. In other words I'm talking about code the programmer makes themselves. >Its easy to say, 'well, thats a bug in the library, not a problem with rust', but thats the same as with C++ is…

There is no rust language without the unsafe keyword. It doesnt exist. The unwinding is unsafe. see the recent thread on /r/rust about mysterious segfaults. Thats the point. You cannot assert your rust program cannot crash. Even if your code is perfect, there may be bugs in either the std library or some dependency you use that does crash. Im not saying everyone uses unsafe code (or should) in their own code. Far fro…

You can write a library in rust that will never invoke unsafe code, even if you can't have an entire standalone program.

>I dont understand why this is difficult idea for people to accept. Just use the good bits of rust. rust doesnt need to be 100% safe; its not, and thats completely ok.

It's okay for now, but I'm eagerly waiting for a version where the important pieces of unsafe code can be formally verified. Give me safe unwinding, memory allocation, and sockets, and I can cover half the world.

As far as I know this isn't an especially difficult request. I could probably cobble together something right now by borrowing bits of verified C and gluing them to library-limited rust.

Re: Spidermonkey has passed V8 on Octane performance

#335

Post by gojomo »

liminal wrote: post #231
gojomo wrote: post #22

Earlier quoted context omitted.

I could survive without processes-per-tab, if Firefox gave some hint – any hint! – which tabs are being naughty. Maybe just a per-tab counter of allocations, or timeouts, or DOM edits, or some other operation? Anything that serves as a proxy for "more active than average while not in foreground".

Use the profiler in the developer tools. Run it for a short while (e.g. 10 seconds) and look at the results. The tab using the most CPU resources will be at the top of the result tree.

That's quite useful!

I just gave it a try in a current, Firefox-not-being-sluggish state, and it seems it may be a bit hard to correlate profiler lines to exact tabs. (For example, 7 of the top 13 rows that had domains associated were Google-API-related, but I don't think they're being used from Google pages...) Still, when I next enter a laggy state perhaps this will help finger the culprit(s) unambiguously. Thanks!

Re: Spidermonkey has passed V8 on Octane performance

#336

Post by __david__ »

bzbarsky wrote: post #138
__david__ wrote: post #69

Earlier quoted context omitted.

Yeah, Firefox really needs some sort of "top". Right now, idling, my Firefox is taking between 20% and 40% of my CPU. I'm sure it's some tab running some dumb javascript, but there's no way for me to figure out which one. Sad, because spidermonkey must know which window a javascript context is associated with, so it could feasibly keep track of run time.

SpiderMonkey itself actually has no concept of windows at all. So it doesn't know what window anything has to do with. The browser itself does, though. Some sort of "top"-like utility is in fact being worked on, for both websites and extensions.

Yeah, but it knows the global "window" object. That's enough for it to keep track of stuff. Let the browser correlate that global object with an actual UI window/tab.

Re: Spidermonkey has passed V8 on Octane performance

#337

Post by Tepix »

josteink wrote: post #189
miket wrote: post #58

Earlier quoted context omitted.

Don't forget that a large chunk of Mozilla's revenue comes from Google: http://thenextweb.com/insider/2013/11/21/mozillas-reliance-g...

> Don't forget that a large chunk of Mozilla's revenue comes from Google I'd love to support Mozilla as much as possible, but no way I'm keeping the default Google-search when you have stuff like DDG around. Hopefully me wanting privacy doesn't impact Mozilla's financials too hard. Firefox + DDG only seems like the most natural combination: both are powerful and privacy-centric.

IMHO, Mozilla only appears to be privacy centric, in reality the way they hide the 3rd-party-cookie on-by-default setting shows that the user's privacy is not their top priority. I'm pretty sure that they are paid for hiding it like that and not blocking third party cookies by default (like Safari).

Disappointing.

The slogan on their page ("Committed to you, your privacy and an open Web") sounds hollow when considering this and their recent support for DRM.

Re: Spidermonkey has passed V8 on Octane performance

#338

Post by ivanca »

roca wrote: post #293
magicalist wrote: post #259

Earlier quoted context omitted.

Can you explain more what you think is unfair about the test? I've only given it[1] a brief read and it certainly is a synthetic benchmark, but it doesn't seem absurdly artificial. I've certainly written JS that builds trees, modifies them, tears them down, and builds new ones, all within the same event loop turn, and so would certainly benefit from incremental GC in the cases when the data it's working over is very…

Your app won't benefit from incremental GC during an event loop turn, because nothing your script did before the incremental GC slice will be made visible to users until the entire event loop turn is finished.

But what about the all the other processes in the device? There may be another process at the same time who may benefit from such GC, perhaps a video being played inside a plugin, or just Photoshop being run side-to-side with the browser and things like that.

It may not benefit the app but it may benefit the user, which is clearly a relevant metric.

Post reply on HN