Earlier quoted context omitted.
It's absolutely intentional, and it's got being technically correct on its side, it's just frustrating.
Not really. That Rust forced total order and partial order into a sub-typing relation is a completely unnecessary, self-inflicted wound.
Making Rust as Fast as Go
201–210 of 211 posts
Re: Making Rust as Fast as Go
#202I tried this on a spare time project[1]. Runtime in a quick test went down from 14.5 to 12.2 secs on macOS! So a solid ~15% by changing the allocator to jemalloc. However, I now have a segfault w/o a stack trace when the data gets written at the end of the process. Possibly something fishy in some `unsafe{}` code of a dependent crate of mine that the different allocator exposed. :] Still – no stack trace at all is ve…
I have found that jemallocator is currently broken on macOS Catalina, so that might be the problem. If you can reproduce this issue reliably, I'd love to hear about it because I can't myself unless I use a very specific toolchain that produces -O3 binaries that are a real pain to work with.
Eg.:
> rdla dump foo.nsi
should produce the segfault before exiting the process.Is there a jemallocator ticked where to attach a report for this?
Re: Making Rust as Fast as Go
#203Earlier quoted context omitted.
> and they do work. Maybe you are just using different no_std libraries that I am using, but pretty much all of the no_std libraries that I use have `libc` as a direct dependency. Not only for malloc, many of them just needs to write something to stdout or a file, generate random numbers, ..., and that's hard to do without libc. Why they advertise themselves as no_std escapes my comprehension.
Huh, the libc crate itself claims #![no_std] support. I agree that's confusing and counterintuitive... I see what it means in terms of semantics but I don't understand why that's useful.
Project I'm working on right now is `#[no_std]`, but my own sysroot covers 90% of real `std`. Which is why I even export it as `std`, so I can use pretty much all crates I would usually use. Because if your platform has an allocator, doesn't matter where it came from, then you can add `liballoc`. `libstd` = `libcore` + `liballoc` + locks + allocator + threads + a few other things that usually depend liballoc. Which means that you have nearly entire libstd available to you if your target platform has an allocator.
Most `#[no_std]` crates that depend on allocator clearly state that they depend on `liballoc` and that you gotta provide one. What I'm trying to say `#[no_std]` doesn't mean embed, it just means sysroot isnt' available for target.
Re: Making Rust as Fast as Go
#204Earlier quoted context omitted.
Is Go widely used compared to the others as a systems language at this point? Over the years I’ve gathered that it’s more of a competitor for C# & Java rather than Rust & C(++).
Depends what you mean by "systems language" (many common definitions turn out to be equivalent to "drop-in replacement for the platform language," which makes the argument circular), but the choice of Go as an implementation language for Docker and Kubernetes puts it pretty firmly in the "systems language" space IMO. Container management requires more systems-level functionality than C# and Java are really geared tow…
You can write it any language that runs on OS with linux's kernel. There are similar things written and damn bash. Does that make bash a system language?
Re: Making Rust as Fast as Go
#205Earlier quoted context omitted.
I have found that jemallocator is currently broken on macOS Catalina, so that might be the problem. If you can reproduce this issue reliably, I'd love to hear about it because I can't myself unless I use a very specific toolchain that produces -O3 binaries that are a real pain to work with.
It's 100% reproducible. Just check out the previous to last commit on master on the github repo I linked to and run the tool with any command that invokes the nsi crate. Eg.: > rdla dump foo.nsi should produce the segfault before exiting the process. Is there a jemallocator ticked where to attach a report for this?
Re: Making Rust as Fast as Go
#206Earlier quoted context omitted.
It's 100% reproducible. Just check out the previous to last commit on master on the github repo I linked to and run the tool with any command that invokes the nsi crate. Eg.: > rdla dump foo.nsi should produce the segfault before exiting the process. Is there a jemallocator ticked where to attach a report for this?
Thanks! I think you found the jemallocator bug, so I'll try your project and follow up there.
Also there is this: https://github.com/gnzlbg/jemallocator/issues/136
Re: Making Rust as Fast as Go
#207Earlier quoted context omitted.
Fake News was a term invented around 2015 during the run-up to the 2016 election. It specifically referred to the phenomenon of literally fake news stories, such as rallies and completely false stories about politicians, being published by legitimate-sounding but nonexistent news organizations, using platforms like Facebook to disseminate themselves. Usually these were done from China and Russia.
You're as silly as those people who claim that male and female refer exclusively to sex but not gender. Terms change in meaning and fake news is widely used to refer to false news stories, regardless of reason. You have to accept the way everybody else is using the word.
Re: Making Rust as Fast as Go
#208Earlier quoted context omitted.
AFAIK on Windows, the hierarchy is: C library => kernel32.dll => ntdll.dll => system calls You don’t have to go via the C library - calling kernel32 directly is fine (I believe this is what Go does). However, it’s very rare to call ntdll or to make system calls directly.
I'm guessing the performance benefits are negligible anyway?
Re: Making Rust as Fast as Go
#209Earlier quoted context omitted.
Oh fab, just when I thought I had a fairly solid understanding of how to handle Unicode strings I learn something else that increases the complexity. I have nothing but respect and gratitude for people that write good unicode handling libraries, but even then the end developer has to learn a lot just to be aware of what to look out for when handling strings. Somewhere on github I think, somebody has posted a file wit…
In general, unicode requires you think differently about strings depending on context. Here's my rule of thumb. 1. If you are transporting a unicode string, reading/writing over the network or to a file, think in terms of UTF-8 bytes. Do not attempt to splice the string, treat it as an atomic unit. 2. If you are parsing a string, think in terms of code points (runes in Go, chars in Rust). A good example would be the…
If all your syntactically meaningful characters are in ASCII you can also use UTF-8 bytes in your parser.
Even if they aren't, no UTF-8 encoding of a character is a substring of the encoding of any other character(s).
Re: Making Rust as Fast as Go
#210Earlier quoted context omitted.
"fake news" is an attempt at permanently damaging the American public's faith in the fifth estate. Nobody should ever use that term in the current political climate, ever.
"damaging the American public's faith" - Really, just the American? You ever realize there are other human species on this planet?
https://news.ycombinator.com/newsguidelines.html
We had to ask you the same thing once recently already: https://news.ycombinator.com/item?id=22775767. Doing this repeatedly will get you banned here, so please stop.