You must be responding to the wrong person. My response was to the ridiculous "But Microsoft!!" post. The person who was pointing out all the issues was the GP of my post.
Re:Make better language, not better coders.
on
Rust 1.0 Released
·
· Score: 1
Plus, they have yet to even prove the fact that Rust is good at what they claim it's made for. C and C++ didn't win over programmers through hype. They won over programmers by being proven through real-world applications. It's easy to talk up a language, it's much harder to back that talk up with real-world results.
Some intrisics make additional assumptions that a compiler cannot know about generic operations, whereas the programmer knows more about what is actually being done. But these are for specific command and operations that are not inherent in C, and you can still end up with C code with occasional additional function calls. YMMV, as some compilers seem to suck at using intrinsics much more so than others.
Yes, I know all this. I posted it above. The point, though, is that compilers still suck at SIMD. Otherwise intrinsics wouldn't need to exist in the first place. Intrinsics are mostly there so people can coax the compiler into being less shitty.
Re:Make better language, not better coders.
on
Rust 1.0 Released
·
· Score: 1, Insightful
The improvement over C/C++ is that you won't trigger UB by accident while using the safe subset of the language, and the vast majority of the time you will be able to do what you want in that subset.
I can do the same thing in C++ using a safe subset of it as well without needing to learn a new language and waste man years porting software. No one doing modern C++ should be dealing with raw pointers outside of exceptional cases.
Re:Make better language, not better coders.
on
Rust 1.0 Released
·
· Score: 1
Waiting for adoption is just an excuse to not be an adopter yourself.
No, it's waiting for Mozilla to actually prove the language is viable.
To add, unlike Swift Rust has been publicly being developed on Github since 2010. So it doesn't matter what anyone "says" when there is a Public git record dating back to their 2010 public announcement about the language. Unless you think Github and the Rust developers faked their git history.
My post was flamebait? In what way exactly? Or did someone just get butthurt that I didn't go "Yeah, you're right. Hurr hurr micro$oft sucks!! Hurr hurr!"
Rust has been worked on internally at Mozilla since 2009, was publicly announced in 2010 and had it's earliest pre-release alphas in 2012. It's hardly only been out for 6 months.
Re:I'm worried by what I see.
on
Rust 1.0 Released
·
· Score: 3, Insightful
What's the relevance of this exactly? I'm not sure how Microsoft having bugs in their software somehow cancels out the ton of bugs in the Rust compiler, it's standard library and the software project that is its biggest consumer. Does the Rust bugs somehow cease to exist because bugs exist in Microsoft software? Do their severity somehow change because Microsoft has bugs in its software? Come back when you have an actual argument not "BUT MICRO$OFT!!!"
One can than argue that it being harder to shoot yourself in the foot makes it simpler:)
Not really. Take guns for example. It's quite simple to blast one's foot off with any gun. It's actually quite a bit more complex to be able to make a gun such that shooting one's foot off is hard.
And to add, if C compilers were good enough at autovectorization there would be no reason for assembly intrinsics to exist nor for compiler/hardware vendors to provide libraries that are highly optimized with assemby for performance. Plain C code should be plenty fine.
Then your software must be only using pretty trivial algorithms. Again, if you think autovectorization is so great, take x264 and disable it's hand-written SIMD and compile it with your compiler of choice. There's no way the compiler will even get within 2x of x264's SIMD.
Yeah, without SIMD there's no other way to get decent performance from DSP/multimedia applications on a general purpose CPU. Even moreso important when it comes to NEON on ARM chips.
The assembly barely wins if I update it every generation with the latest improvements in SIMD instructions.
Then you're doing something horribly wrong and causing all sorts of stalls in the pipeline.
Otherwise, the unchanged c code wins ever since autovectorization has been implemented decently.
Well since autovectorization is still mostly shit this time has yet to arrive. If you think autovectorization is so great, take x264 and compile it with this mythical compiler with all its fancy autovectorization but without any of the assembly optimization. There's no way in hell any compiler is going to beat the hand-written SIMD.
It's been a long time since I was able to "out-code" a C compiler.
Do anything requiring SIMD to have any decent performance. Then it's pretty easy to beat C compilers since they are all pretty shit at vectorization. And thats even when following the arcane requirements of each compiler that the vendor says improves the chances that auto-vectorization can work which mostly don't work for anything more than trivial algorithms.
Slashdot Mirror
You must be responding to the wrong person. My response was to the ridiculous "But Microsoft!!" post. The person who was pointing out all the issues was the GP of my post.
Plus, they have yet to even prove the fact that Rust is good at what they claim it's made for. C and C++ didn't win over programmers through hype. They won over programmers by being proven through real-world applications. It's easy to talk up a language, it's much harder to back that talk up with real-world results.
Touche!
Senior Software Engineer: Minimum 5 years of experience in Rust 2.0!
Some intrisics make additional assumptions that a compiler cannot know about generic operations, whereas the programmer knows more about what is actually being done. But these are for specific command and operations that are not inherent in C, and you can still end up with C code with occasional additional function calls. YMMV, as some compilers seem to suck at using intrinsics much more so than others.
Yes, I know all this. I posted it above. The point, though, is that compilers still suck at SIMD. Otherwise intrinsics wouldn't need to exist in the first place. Intrinsics are mostly there so people can coax the compiler into being less shitty.
The improvement over C/C++ is that you won't trigger UB by accident while using the safe subset of the language, and the vast majority of the time you will be able to do what you want in that subset.
I can do the same thing in C++ using a safe subset of it as well without needing to learn a new language and waste man years porting software. No one doing modern C++ should be dealing with raw pointers outside of exceptional cases.
Waiting for adoption is just an excuse to not be an adopter yourself.
No, it's waiting for Mozilla to actually prove the language is viable.
To add, unlike Swift Rust has been publicly being developed on Github since 2010. So it doesn't matter what anyone "says" when there is a Public git record dating back to their 2010 public announcement about the language. Unless you think Github and the Rust developers faked their git history.
Great, for "them". What exactly is the relevance?
My post was flamebait? In what way exactly? Or did someone just get butthurt that I didn't go "Yeah, you're right. Hurr hurr micro$oft sucks!! Hurr hurr!"
Rust has been worked on internally at Mozilla since 2009, was publicly announced in 2010 and had it's earliest pre-release alphas in 2012. It's hardly only been out for 6 months.
What's the relevance of this exactly? I'm not sure how Microsoft having bugs in their software somehow cancels out the ton of bugs in the Rust compiler, it's standard library and the software project that is its biggest consumer. Does the Rust bugs somehow cease to exist because bugs exist in Microsoft software? Do their severity somehow change because Microsoft has bugs in its software? Come back when you have an actual argument not "BUT MICRO$OFT!!!"
One can than argue that it being harder to shoot yourself in the foot makes it simpler :)
Not really. Take guns for example. It's quite simple to blast one's foot off with any gun. It's actually quite a bit more complex to be able to make a gun such that shooting one's foot off is hard.
I'm waiting for the job postings on Dice that have a requirement of at least 5 years of Rust programming experience in the next couple of months.
Not bad for the people who have been working on Rust internally at Mozilla since 2009. They're about to hit 6 years of experience!
You shouldn't unless you want to be a language hipster.
And to add, if C compilers were good enough at autovectorization there would be no reason for assembly intrinsics to exist nor for compiler/hardware vendors to provide libraries that are highly optimized with assemby for performance. Plain C code should be plenty fine.
Then your software must be only using pretty trivial algorithms. Again, if you think autovectorization is so great, take x264 and disable it's hand-written SIMD and compile it with your compiler of choice. There's no way the compiler will even get within 2x of x264's SIMD.
Yeah, without SIMD there's no other way to get decent performance from DSP/multimedia applications on a general purpose CPU. Even moreso important when it comes to NEON on ARM chips.
but without any of the assembly optimization
And by this I mean disabling x264's handwritten assembly optimizations.
The assembly barely wins if I update it every generation with the latest improvements in SIMD instructions.
Then you're doing something horribly wrong and causing all sorts of stalls in the pipeline.
Otherwise, the unchanged c code wins ever since autovectorization has been implemented decently.
Well since autovectorization is still mostly shit this time has yet to arrive. If you think autovectorization is so great, take x264 and compile it with this mythical compiler with all its fancy autovectorization but without any of the assembly optimization. There's no way in hell any compiler is going to beat the hand-written SIMD.
Apparently not by compilers.
Duh. Compilers are shit at things like vectorization. They can fail at generating decent code even with intrinsics.
It's been a long time since I was able to "out-code" a C compiler.
Do anything requiring SIMD to have any decent performance. Then it's pretty easy to beat C compilers since they are all pretty shit at vectorization. And thats even when following the arcane requirements of each compiler that the vendor says improves the chances that auto-vectorization can work which mostly don't work for anything more than trivial algorithms.
That's because many people have grown up and don't have time to play with toy OSes.
Damnit, yes it was supposed to be *your*. Typed faster than thinking.
And you're assembly is probably easy to beat with even pretty crappy SSE2 code.
Did you bother reading the whole post? Apparently not since the joke whooshed over your head.