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

Speed of Rust vs. C

kornel.ski

Post reply on HN
Print view View original

171–180 of 546 posts

Re: Speed of Rust vs. C

#171

Post by ben0x539 »

ttt0 wrote: post #145
anfilt wrote: post #118

Earlier quoted context omitted.

Firefox's is compiled code is mostly written in C++ not C. You conflate C with C++, Java, and C#. C++ while has source compatibility with C tends to end up much different than C. C will not give you the OOP hell-scape you can dig yourself into with those three languages. C code tends be simpler and much more close to the assembly that will be generated than you would get in those language. Moreover, Java and C# are n…

> C++ while has source compatibility with C It doesn't really, some things from C won't compile in C++, but that's a minor nitpick

I guess people mostly take source compatibility to mean that you can write the headers for your C library so that it can be used from C++. That's not the same thing as C being a proper subset of C++ or whatever, but it's still a vast enough advantage of C++ over most competitors that it might as well be.

Re: Speed of Rust vs. C

#172

Post by ben0x539 »

pjmlp wrote: post #146
bluejekyll wrote: post #137

Earlier quoted context omitted.

Rust won’t prevent all manner of bugs, but if you need to prevent multiple parts of your application from accessing a resource concurrently, it’s fairly trivial to design types that would guarantee that at compile time. If you need to do it across processes, then you need a file system that supports exclusive file opens. The db question is a red-herring, because to properly solve for concurrency in the db, you need t…

Indeed, but the fearless concurrency sales pitch tends to overlook that.

The fearless concurrency sales pitch doesn't overpromise. You're trying to stretch it, but it's pretty clear on what kind of concurrency issues it covers (eg. data races).

Re: Speed of Rust vs. C

#173

Post by secondcoming »

vlmutolo wrote: post #4

> "Clever" memory use is frowned upon in Rust. In C, anything goes. For example, in C I'd be tempted to reuse a buffer allocated for one purpose for another purpose later (a technique known as HEARTBLEED). This made me laugh

It was quite funny but it's quite likely you'll be reusing memory anyway whether it's on the stack or the heap, no?

The issue with this is that 'clever' compilers can optimise out any memset calls you do.

Re: Speed of Rust vs. C

#174

Post by ben0x539 »

fulafel wrote: post #157
bluejekyll wrote: post #141

Earlier quoted context omitted.

You have made this claim multiple times. Why do you see this as a language issue and not an OS issue? It becomes an even bigger problem when we talk about distributed systems and distributed resources. Is there a language that handles this? These issues about multiple processes and distributed systems are framework and OS level concerns. Rust helps you build fast concurrent solutions to those problems, but you’re cor…

How could an OS adapt its processes functionality to help Rust here?

Capabilities would probably be helpful :V

Re: Speed of Rust vs. C

#175

Post by eru »

anfilt wrote: post #118
scorpion95 wrote: post #106

Earlier quoted context omitted.

Yes. But it’s not just taking care of those things that must be done; it seems to bloat the code. I think it’s a great alternative to C for large apps like Firefox, and perhaps it’s a good alternative to Go for services. For general purpose, I personally want something fast that’s easy, clear, and concise like Ruby. Do I just accept that Rust is the most evolved version of C, or is my gut correct that it’s bloated? I…

Firefox's is compiled code is mostly written in C++ not C. You conflate C with C++, Java, and C#. C++ while has source compatibility with C tends to end up much different than C. C will not give you the OOP hell-scape you can dig yourself into with those three languages. C code tends be simpler and much more close to the assembly that will be generated than you would get in those language. Moreover, Java and C# are n…

> Some people even feel C++ keeps adding too many new features too fast.

It's not so much that they keep adding features, but that they (almost?) never remove any.

Re: Speed of Rust vs. C

#176

Post by planetis »

Its just amusing, in this thread everyone with critical thinking and skeptical is down voted, even if one expresses himself moderately. It shows how much of zealots, Rust fanboys have become.

Re: Speed of Rust vs. C

#177

Post by eru »

PicassoCTs wrote: post #136
rbanffy wrote: post #117

Earlier quoted context omitted.

The average cellphone today has more than 4 cores. A decent desktop can deal with 16 threads on 8 cores. There is a lot of untapped parallelism readily available waiting for the right code.

Parallelization is the nuclear energy of comp science. Loads of potential, high risk reward and they would have gotten away with it, if it were not for those meddling humans. Its non-trivial and can only be handled by accomplished engineers. Thus it is not used - or is encapsulated, out of sight, out of reach of meddling hands. (CPU Microcode shovelling non-connected work to pipelines comes to mind / NN-Net training…

> [...] or is encapsulated, out of sight, out of reach of meddling hands.

That's the real issue here! Most language have poor abstractions for parallelism and concurrency. (Many languages don't even differentiate between the two.)

Encapsulating and abstracting is how we make things usable.

Eg letting people roll hash tables by themselves every time they want to use one, would lead to people shooting themselves in the foot more often than not. Compared to that, Python's dicts are dead simple to use. Exactly because they move all the fiddly bits out of the reach of meddling hands.

Re: Speed of Rust vs. C

#178

Post by ywei3410 »

ben0x539 wrote: post #167
phkahler wrote: post #153

Earlier quoted context omitted.

>> One refreshes the screen and lets you move the viewpoint around. The other loads new objects into the scene. How did you do that in Rust? Doesnt one of those have to own the scene at a time? Or is there a way to make that exclusive ownership more granular?

Eh, with Arc you can share ownership easily, and there are probably a lot of cleverer concurrent data structures or entity component kinda things that'd just work too. But maybe you can arrange things so that one thread owns the scene but the other thread can still do useful work?

This typically isn't possible because the rendering context is global and is needed for both loading and rendering. You need an Arc to guarantee the correct Drop mechanism.

Re: Speed of Rust vs. C

#179

Post by dan-robertson »

moonchild wrote: post #13

> C libraries typically return opaque pointers to their data structures, to hide implementation details and ensure there's only one copy of each instance of the struct. This costs heap allocations and pointer indirections. Rust's built-in privacy, unique ownership rules, and coding conventions let libraries expose their objects by value The primary reason c libraries do this is not for safety, but to maintain ABI com…

The reason Common Lisp uses pointers is because it is dynamically typed. It’s not some principled position about ABI compatibility. If I define an RGB struct for colours, it isn’t going to change but it would still need to be passed by reference because the language can’t enforce that the variable which holds the RGBs will only ever hold 3 word values. Similarly, the reason floats are often passed by reference isn’t some principled stance about the float representation maybe changing, it’s that you can’t fit a float and the information that you have a float into a single word[1].

If instead you’re referring to the fact that all the fields of a struct aren’t explicitly obvious when you have such a value, well I don’t really agree that it’s always what you want. A great thing about pattern matching with exhaustiveness checks is that it forces you to acknowledge that you don’t care about new record fields (though the Common Lisp way of dealing with this probably involves CLOS instead).

[1] some implementations may use NaN-boxing to get around this

Re: Speed of Rust vs. C

#180

Post by eru »

alerighi wrote: post #144
Animats wrote: post #26

"But the biggest potential is in ability to fearlessly parallelize majority of Rust code, even when the equivalent C code would be too risky to parallelize. In this aspect Rust is a much more mature language than C." Yes. Today, I integrated two parts of a 3D graphics program. One refreshes the screen and lets you move the viewpoint around. The other loads new objects into the scene. Until today, all the objects were…

Also Rust is risky to parallelize: you can get deadlocks. I don't get the obsession of parallel code in low level languages by the way. If you have an architecture where you can afford real parallelism you can afford higher level languages anyway. In embedded applications you don't usually have the possibility to have parallel code, and even in low level software (for example the classical UNIX utilities), for simpli…

> In embedded applications you don't usually have the possibility to have parallel code, and even in low level software (for example the classical UNIX utilities), for simplicity and solidity using a single thread is really fine.

Depends on which of the classic utilities you are talking about.

Many of them are typically IO bound. You might not get much out of throwing more CPU at them.

Post reply on HN