Weekly Edition
Return to the Development page
| |||||||||||||
Mozilla and Samsung building a new browser engine
The Mozilla project has announced
a collaboration with Samsung to build "Servo", a next-generation browser
rendering engine. "Servo is an attempt to rebuild the Web browser
from the ground up on modern hardware, rethinking old assumptions along the
way. This means addressing the causes of security vulnerabilities while
designing a platform that can fully utilize the performance of tomorrow’s
massively parallel hardware to enable new and richer experiences on the
Web. To those ends, Servo is written in Rust, a new, safe systems language
developed by Mozilla along with a growing community of enthusiasts."
(Log in to post comments)
Mozilla and Samsung building a new browser engine Posted Apr 3, 2013 18:25 UTC (Wed) by markhb (guest, #1003) [Link] ...an attempt to rebuild the Web browser from the ground up on modern hardware, rethinking old assumptions along the way. This means addressing the causes of security vulnerabilities while designing a platform that can fully utilize the performance of tomorrow’s... hardware to enable new and richer experiences on the Web.Isn't that what they said about NGLayout (aka Gecko)?
Mozilla and Samsung building a new browser engine Posted Apr 3, 2013 18:48 UTC (Wed) by apoelstra (subscriber, #75205) [Link]
> Isn't that what they said about NGLayout (aka Gecko)?
If they did (I don't remember), they would have been correct -- Gecko was a huge step up for graphical web browsers. But even in the last five years the use of browsers has changed drastically, so that websites now are often elaborate and complex Javascript frontends to server-side applications, shunting loads of data around and using several domains. The security and performance requirements are therefore very different than they were when Gecko was conceived.
As for this project, I hope it succeeds because Rust looks like an excellent language, and it would be great to see it completed and have traction.
Mozilla and Samsung building a new browser engine Posted Apr 3, 2013 19:41 UTC (Wed) by bronson (subscriber, #4806) [Link]
> Rust looks like an excellent language, and it would be great to see it completed and have traction.
Isn't that what they said about XUL? :)
Mozilla and Samsung building a new browser engine Posted Apr 3, 2013 20:26 UTC (Wed) by rahulsundaram (subscriber, #21946) [Link]
Well XUL is just markup and it did gain a lot of traction for a while (flickr uploader, Songbird, Activestate Comodo etc) but it didn't stick
Rust-lang Posted Apr 3, 2013 21:12 UTC (Wed) by man_ls (subscriber, #15091) [Link] [...] Rust looks like an excellent language [...]After browsing the home page for two minutes I see two major flaws:
Rust-lang Posted Apr 4, 2013 0:23 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Well, you have to choose modifiers at the end of the day. Rust is actually pretty sane in this regard - just look at Scala for a comparison.
I've recently tried to use Rust instead of Go for simple "scripts" and I really loved it. Rust has a good type system (real reified generics!), unique memory management system (with explicit inter-thread sharing), normal exceptions support, etc.
In comparison, Go really looks like a kludged second-system effect language.
Rust-lang Posted Apr 4, 2013 3:11 UTC (Thu) by imgx64 (guest, #78590) [Link]
I think the competition between Rust and Go is going to be really interesting. Go is a really simple language that tries to be practical instead of feature-complete (i.e. a better C). Rust on the other hand tries to include a lot of features and wants to be the end to all your programming needs (i.e. a better C++).
Rust-lang Posted Apr 4, 2013 3:31 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Go doesn't really tries to be 'better C'. It's more like "Java but from Google" - they are even repeating the same "mistakes" like having mutable variables by default and the common heap.
And then the philosophy of Go is completely nuts. They are trying to be 'simpler' but it instead results in lots and lots of cruft.
Rust-lang Posted Apr 4, 2013 4:08 UTC (Thu) by imgx64 (guest, #78590) [Link]
> Go doesn't really tries to be 'better C'. It's more like "Java but from Google"
Java? What does Go have in common with Java?
Go didn't even start its life as "something from Google" (unlike Dart for example). It started as a 20% project by Rob Pike, Ken Thompson, et al. then other developers at Google started using it because they found it a good fit for their problems.
> having mutable variables by default and the common heap.
Like I said, "practical"--that's how computers work.
> And then the philosophy of Go is completely nuts. They are trying to be 'simpler' but it instead results in lots and lots of cruft.
What kind of cruft are you objecting to? make()? append() and friends?
I agree they're not orthogonal, and to an outsider, they feel like a kludge for the lack of generics. But after using them for a while, they don't bother me much. And the simplicity of the rest of Go more than makes up for any conceived "cruft".
Rust-lang Posted Apr 4, 2013 4:13 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
>Java? What does Go have in common with Java?
"Style" of it.
>Like I said, "practical"--that's how computers work.
> What kind of cruft are you objecting to? make()? append() and friends?
From what I'm seeing, a lot of Go code out there simply has no error handling - it either works or fails mysteriously.
Rust-lang Posted Apr 4, 2013 6:57 UTC (Thu) by heijo (guest, #88363) [Link]
It seems to me that Rust is going to be completely superior to Go, and is likely to kill it.
More interesting is whether it will manage to be a complete replacement for C++, with the same performance but adding safety, which would be a VERY much needed development, since using unsafe languages needs to stop.
And also what's going to happen to the high-level space (currently led by Java/Scala and C#), and specifically whether Rust's lack of a global garbage collected heap and multiple pointer types will prove good or bad.
It's definitely one of the most promising languages in existence, along with Scala.
Rust-lang Posted Apr 4, 2013 8:43 UTC (Thu) by imgx64 (guest, #78590) [Link]
> It seems to me that Rust is going to be completely superior to Go, and is likely to kill it.
This is why I think the competition will be interesting; a classic C vs. C++ / Simplicity vs. Features sort of competition.
As far as Rust killing Go, Go has already released v1.0 (with v1.1 coming in the next few weeks), and is actually used in mission-critical applications. Rust? Still not much.
Rust-lang Posted Apr 4, 2013 8:02 UTC (Thu) by renox (subscriber, #23785) [Link]
> Well, you have to choose modifiers at the end of the day. Rust is actually pretty sane in this regard - just look at Scala for a comparison.
Uh? Could you give an example of what you're talking about?
Rust-lang Posted Apr 4, 2013 16:39 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
"qsort(rest).::(pivot).:::(qsort(smaller))"
Rust-lang Posted Apr 4, 2013 22:55 UTC (Thu) by HelloWorld (guest, #56129) [Link] Nobody writes it that way, there's a reason why one is allowed to omit the . and the (). Also, you've confused ::: and ::.qsort(rest) ::: pivot :: qsort(smaller)
I don't think this looks too bad.
Rust-lang Posted Apr 6, 2013 13:24 UTC (Sat) by gevaerts (subscriber, #21521) [Link]
> you've confused ::: and ::
Are you sure you're making the point you're trying to make?
Rust-lang Posted Apr 6, 2013 16:38 UTC (Sat) by HelloWorld (guest, #56129) [Link]
Yeah, I know, people confuse + and ++ in C all the time. Oh wait: they don't!
Rust-lang Posted Apr 4, 2013 15:43 UTC (Thu) by tjc (subscriber, #137) [Link]
> I've recently tried to use Rust instead of Go for simple "scripts" and I really loved it.
What OS/distro are you using? I tried to build Rust on both OS X and Linux Mint 12.04, but both failed, for different reasons.
Rust-lang Posted Apr 4, 2013 17:59 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Mac OS X with recent enough MacPorts. No problems at all during the build.
Rust-lang Posted Apr 4, 2013 3:34 UTC (Thu) by dirtyepic (subscriber, #30178) [Link] You think that's bad? I've heard of languages with single letter names!
Rust-lang Posted Apr 4, 2013 6:18 UTC (Thu) by donbarry (guest, #10485) [Link]
And not just the obvious one. J is an incredible language which deserves to be known widely. K is even less well known (probably deservedly) and distantly related, by an unrelated development team but inspired by the same roots in APL.
Rust-lang Posted Apr 5, 2013 8:21 UTC (Fri) by dgm (subscriber, #49227) [Link] I don't find those much problematic, but go read the tutorial, and in section 3.1 you will find that:
let var =
if (condition1) {
value1
} else {
value2
};
is completely different from:
let var =
if (condition1) {
value1;
} else {
value2;
}
The second one would be almost surely a mistake, but the compiler would not complain. In my opinion this defeats the purpose of doing Yet Another Curly Brace Language. The mere fact that they feel they need to point it out in the tutorial is a clear sign that something is wrong here. I hope they get this sorted out before 1.0
Rust-lang Posted Apr 5, 2013 12:39 UTC (Fri) by renox (subscriber, #23785) [Link]
Yes, in Rust you have to be very cautious about the usage of ';'!
Thankfully as the return type of functions is not inferred but given explicitly in many cases the compiler will be able to complain, not in the example you've given though.
Apparently they don't like 'return', I'm not sure why.. Maybe it's because it's 'big' (they seem to like short keyword)?
Another weird part is the for: 'for v.each |e| { bar(*e);}', uh?
Also code with named lifetime seems really hard, but I don't think that's a syntax issue, it's just a difficult concept to master.
Rust-lang Posted Apr 5, 2013 12:54 UTC (Fri) by HelloWorld (guest, #56129) [Link]
It is trivial to add a warning for that. Just check if a local variable is bound to a value of type ().
Rust-lang Posted Apr 5, 2013 17:01 UTC (Fri) by jimparis (subscriber, #38647) [Link]
A runtime warning? It's hardly trivial at compile time when the compiler might not even know if a branch can be taken.
Rust-lang Posted Apr 5, 2013 22:18 UTC (Fri) by HelloWorld (guest, #56129) [Link]
> A runtime warning? It's hardly trivial at compile time when the compiler might not even know if a branch can be taken.
It doesn't matter whether the branch can be taken, the values of both branches are of type (), and it doesn't make sense to store a value of that type in a variable.
Rust-lang Posted Apr 5, 2013 22:47 UTC (Fri) by jimparis (subscriber, #38647) [Link]
> It doesn't matter whether the branch can be taken, the values of both branches are of type ()
So imagine a case where both branches are different. Or where the conditional is deep inside a function before the return value finally gets to the assignment. If having a conditional return type () makes sense in some cases and not others, then you can't trivially warn about it.
Rust-lang Posted Apr 6, 2013 0:26 UTC (Sat) by HelloWorld (guest, #56129) [Link]
> So imagine a case where both branches are different.
That's a type error in itself in most cases. In order for such code to typecheck, the branches' types must have a common supertype. As far as I can see, Rust allows only interfaces to form hierarchies, and I don't know if it's even possible for () to implement interfaces. But even if it is, this situation is going to be so rare that it's not worth losing any sleep over it.
Samsung joins Posted Apr 3, 2013 20:16 UTC (Wed) by juliank (subscriber, #45896) [Link]
Samsung joins them, Servo was already in development.
Rust Posted Apr 4, 2013 10:04 UTC (Thu) by ncm (subscriber, #165) [Link]
Could this be the long-awaited "Glorious Successor to C++", the prophesied ++C++? Will Haskell, Common Lisp and Go alike be mercifully forgotten? Will it engage in a climactic battle to the death against Clay, or mate with it and produce eldritch preternatural offspring?
Building...
Rust Posted Apr 4, 2013 17:39 UTC (Thu) by khim (subscriber, #9252) [Link] Why people think D, Go, Rust or some other "modern" language can replace C++? They all lack the ability to convert your program in new language piece-by-piece which means they'll have as much success trying to replace C++ and Plan9 had trying to replace UNIX. I can imagine new language which will start from C and will go from there (think Objective-C), but even this is not all that likely. New, incompatible one? No chances, sorry. Sure, we'll see some projects written in these languages, but what exactly will distinguish these from projects written in Java or, ugh, PHP?
Rust Posted Apr 4, 2013 18:00 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Java has succeeded and so has C#. And while C# has a decent FFI (Foreign Function Interface), Java only has JNI.
So C compatibility is not essential. But having a good FFI certainly helps.
Rust Posted Apr 4, 2013 20:00 UTC (Thu) by khim (subscriber, #9252) [Link] Java has succeeded and so has C# Rilly? Reality check: Java Applets - failure, Java ME - failure, Android - failure (it's huge success only came after NDK release), Silverlight - failure, Windows Phone - failure (Windows Phone 7.x, that is, Windows Phone 8 returned back to C - we'll see where it'll lead), where is this success? I'm talking about "next C" which means that either it replaces C as program-development language or it replaces it as OS kernel-level language. AFAIKS Java and C# both failed there. Spectacularly. Sure, they carved niche for itself, but so did many other languages - from VBA to PHP and Perl, but "next C"? Not even close.
Rust Posted Apr 4, 2013 20:04 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
Java succeeded on mobile (Android) and on the server-side. C# is very successful on Windows both on client and server side.
>I'm talking about "next C" which means that either it replaces C as program-development language or it replaces it as OS kernel-level language. AFAIKS Java and C# both failed there. Spectacularly.
Rust Posted Apr 4, 2013 20:42 UTC (Thu) by khim (subscriber, #9252) [Link] Java succeeded on mobile (Android) and on the server-side. Java is used to write huge amount of new code, that's true, but the same can be said about PHP or JavaScript and number of projects which switched from C to Java is so minuscule it's not even worth talking about. Android only caught up when it allowed execution of C/C++ code and can only be counted as yet-another-failed-attempt-to-replace-C++-with-Java (or may be it was never planned as such an attempt: some people claim that NDK for Android was planned from the start and was just released later because it was not ready for Android 1.0). C# is very successful on Windows both on client and server side. Again, in the same fashion: some pieces are written in C# but amount of new C++ code does not go down at all and people rarely make conscious decision to switch from C++ to C# (few projects did that - notably Visual Studio itself - but these are rare exceptions, not rule). If anything C# replaced Visual Basic not C++ - and that only happened because Visual Basic was brutally killed (Visual Fred is not Visual Basic). P.S. Note that I don't argue that Java and/or C# are not popular - of course they are (I don't necessarily think it's good thing, but that's irrelevant), but are they popular as "Glorious Successor to C" or "Glorious Successor to C++"? Of course not! Not even close!
Rust Posted Apr 4, 2013 21:39 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]
>Java is used to write huge amount of new code, that's true, but the same can be said about PHP or JavaScript and number of projects which switched from C to Java is so minuscule it's not even worth talking about.
Heh. You clearly haven't seen the number of large enterprise projects switching from C++ to Java in 90s and early 2000-s. Ditto for C# - quite a lot of software was rewritten in it.
A good C++-like language does not NEED to be directly compatible with all braindeadness of C, it just needs to have a good FFI.
>Again, in the same fashion: some pieces are written in C# but amount of new C++ code does not go down at all and people rarely make conscious decision to switch from C++ to C#
Rust Posted Apr 5, 2013 7:38 UTC (Fri) by khim (subscriber, #9252) [Link] You clearly haven't seen the number of large enterprise projects switching from C++ to Java in 90s and early 2000-s. Yes, I have seen these failures. What about them? Sure, with well-oiled PR machine you can convince pointy-haired bosses to adopt basically anything and because they can not admit that they goofed up failures are often presented as successes (Elop is undisputed leader here, but he's not the only one). In any case they are mostly about hype: systems written in Cobol, Pascal, dBase and other similar languages are often still used even when bosses think they operate pure Java (or C#) shops. IOW: if anything "the big switch of enterprise to Java and C#" is nothing but smoke and mirrors. PR achievement at best.
Rust Posted Apr 4, 2013 23:11 UTC (Thu) by HelloWorld (guest, #56129) [Link] (Visual Fred is not Visual Basic)I see esr still doesn't understand The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets. sigh.
Rust Posted Apr 4, 2013 19:06 UTC (Thu) by ncm (subscriber, #165) [Link]
A language as powerful and expressive as C++ has a big advantage. Java is not, Go is not, Ruby is not. Haskell is powerful but slow, and needs an intrusive runtime environment. If (as it appears) Rust is as expressive as C++, equally fast, and link-compatible with C, it has a unique opportunity because it's much, much simpler than C++. That makes it easier to learn, and cheaper to implement and maintain, both the compiler and your own code. Given C link-compatibility, Rust modules can be added to your existing programs, and new Rust programs can call your existing libraries, offering a smooth transition path.
No language is forever. Rust might not be the true Glorious Successor to C++. If not, whatever is will look a lot like Rust.
Rust Posted Apr 4, 2013 20:29 UTC (Thu) by khim (subscriber, #9252) [Link] If (as it appears) Rust is as expressive as C++, equally fast, and link-compatible with C, it has a unique opportunity because it's much, much simpler than C++. Nope. There are fundamental difference between these. To go from C to Java you need to jump over 100 feet high wall and to go from C to Haskell you need to jump over 1000 feet high wall. With Rust this wall may be 50 feet high or may be even 10 feet high, but it's still a wall and it'll keep users from defecting from C camp. C++? For C++ it's kinda 500 feet-high staircase: sure, the end position it pretty far removed from where you've started but you can go there at the pace you want. You can use as many or as few C++ features as you want - which means that any C programmer can become C++ programmer by learning about couple of things s/he wants/needs. Sure, s/he may not be very efficient C++ programmer, but s/he'll be a C++ programmer even the only thing s/he uses are mutex classes or something like this. Eventually C++ can replace C more-or-less everywhere (the last holdouts like binutils and gcc are slowly switching to C++ camp). Well, may be not kernel (because it uses C++-incompatible dialect of C), but even that may happen in 10 years or so. If you introduce incompatible syntax, incompatible paradigms (and insist that said paradigms must be used from the start) then substantial percentage of developers will just be kept behind the wall such changes reproduce. Rust may succeed as a language or it may fail but it can not be next C++. It's not in the cards. No language is forever. Rust might not be the true Glorious Successor to C++. If not, whatever is will look a lot like Rust. I seriously doubt it. Go, Rust and other "modern" languages is not designed to be C replacement and this means that at best they'll coexist with C/C++ (at worst they'll go to the dustbin of history). Think another, parallel world of Pascal: it was quite popular till a few years ago but it's nominal successor never actually caught up (as successor!) because it was incompatible. Rust is in similar position and it's not even named as "C successor" by people who designed C... Or another data point: Fortran. The last version which was actually incompatible with it's predecessor to significant degree was FORTRAN 77 - and it was almost enough to ruin the transition. Planned transition governed by most compiler vendors! And now you think that another NCP style transitions will happen? Dream on.
Rust Posted Apr 5, 2013 7:00 UTC (Fri) by ncm (subscriber, #165) [Link]
Fortran is an excellent example. Subsequent Fortran releases are more or less backward-compatible, and recent ones even support pointers and recursion, but how many places are they used? When starting a project where Fortran would have been required, people use C++ now because it's faster and more expressive. C++ has turned out to be the Glorious Successor to Fortran, despite being just barely link compatible, in the same way that FORTRAN succeeded assembly language.
The GStC++ will not be anything that is obliged to carry forward C++'s avoidable complexities (largely, forced C compatibility, name lookup horrors). People using C++ now will continue using it, but in maybe ten years new organizations and projects that need C++'s power will begin to pick up Rust (or something) instead. Second-tier languages will come and go, and be used for the easy problems, as always.
My point is that Rust is the first language above the horizon that seems physically capable of supplanting C++ on problems where, before, nothing else could even be seriously considered. If it sputters out, the world will continue with C++ as before until the next contender matures.
Rust Posted Apr 5, 2013 7:32 UTC (Fri) by khim (subscriber, #9252) [Link] Subsequent Fortran releases are more or less backward-compatible, and recent ones even support pointers and recursion, but how many places are they used? In more places then you expect. I know few people who thought like you do till they actually participated in bioresearch, weather prediction research and so on. They found out to their sudden surprise that new projects are still written in Fortran. Usually it's a mix: IT guys write the supplemental logic in C/C++ and non-IT scientists write their algorithms in Fortran. In that sense Fortran is still alive. Number one request for Exacycle is Fortran support (perhaps they already implemented Fortran support at this stage? I don't know). People using C++ now will continue using it, but in maybe ten years new organizations and projects that need C++'s power will begin to pick up Rust (or something) instead. Second-tier languages will come and go, and be used for the easy problems, as always. And Rust in one of these second-tier languages. The same happens with other industries, too. Think track gauges or QWERTY keyboard: once upon time it was easy to change track gauges or layout of keyboard but by now it's basically impossible. You can change some auxiliary pieces (railroad ties are made today from stone, wood, plastic or even fiberglass) and specialized cases use specialized gauges or keyboards, but mainstream is stuck. My point is that Rust is the first language above the horizon that seems physically capable of supplanting C++ on problems where, before, nothing else could even be seriously considered. Nope. Rust is yet-another-pretender with overblown hype. If it sputters out, the world will continue with C++ as before until the next contender matures. Well, the next contender will probably be called C++17, so it's not like we'll need to wait too long.
Rust Posted Apr 5, 2013 8:38 UTC (Fri) by ncm (subscriber, #165) [Link]
Yes, Fortran is still used heavily in certain domains, but no longer because it is, as it once was, the only reasonable choice. Nowadays its continued use is more a matter of inertia than of technical merit.
You seem to be asserting that C++ will always be the only reasonable choice for those difficult problems where there is, at this moment, no other. People used to say that about Fortran. They were wrong too.
That's not to say that Rust (or its descendant, TiN?) really will be the new heavy. What is certain is that there will someday be a new heavy that is not C++XX. Furthermore, it will differ from C++ in many of the ways that Rust does.
Rust Posted Apr 5, 2013 15:00 UTC (Fri) by tjc (subscriber, #137) [Link]
I work in bioresearch, and we use Java for almost everything. That's not the decision I would have made, but that's the trend. Nearly all the organizations we work with use Java, so it's hard to resist.
We used to use C and Perl, which was a common combination in bioinformatics, but that's been fading away -- especially C, I am sorry to say.
Rust Posted Apr 6, 2013 13:34 UTC (Sat) by mathstuf (subscriber, #69389) [Link]
> Haskell is powerful but slow
Huh? Maybe in specific cases where laziness can bite you or you write your calls poorly, but Haskell *can* beat C. In this[1] paper (reddit[2] discussion), on how to get GHC to use SSE for fused inner loops, Haskell is beat by Eigen's optimized calls and Boost's uBLAS library (but Boost only when you work with > L3-sized data). The C code would need careful tuning to take care of the same optimizations. And GHC hasn't really even been "optimized" for the call in particular; it's just an instance of the optimizer at work on a single, fairly naïve writing of the code.
[1]http://research.microsoft.com/en-us/um/people/simonpj/pap...
Rust Posted Apr 7, 2013 5:03 UTC (Sun) by ncm (subscriber, #165) [Link]
C is slow, too, slower than Fortran, so it's not a good standard for comparison.
Rust Posted Apr 7, 2013 5:25 UTC (Sun) by mathstuf (subscriber, #69389) [Link]
> Once the working set no longer fits in L3 cache, the Haskell implementation is even neck-and-neck with the implementation of ddotp from GotoBLAS, a collection of highly-tuned BLAS routines hand-written in assembly language that is generally consid- ered to be one of the fastest BLAS implementation available.
The authors didn't only compare with C.
Rust Posted Apr 7, 2013 11:27 UTC (Sun) by HelloWorld (guest, #56129) [Link]
> C is slow, too, slower than Fortran
Programming languages aren't fast or slow, programs are.
Case in point: the benchmarks game.
In some cases, the C program is faster, in others the Fortran one is faster. "faster than" is simply not a total order on the set of programming languages, so stop making it sound as if it were. It's meaningless and undifferentiated.
Rust Posted Apr 7, 2013 12:19 UTC (Sun) by hummassa (subscriber, #307) [Link]
You are being a purist.
When people say things "C is slower than C++" or "C is slower than Fortran" or "C is slower than Haskell" they actually mean "C offers less opportunities for the compiler and the standard library implementations to optimize many types of constructions in code, mainly because of loose typing rules and loose aliasing rules. When you set out to execute a task computationally complex enough, you have a great probability that a well-written program in C will be slower than a well-written program in FORTRAN, or Haskell, or C++".
Rust Posted Apr 7, 2013 14:13 UTC (Sun) by HelloWorld (guest, #56129) [Link]
What specific optimisation opportunities are you talking about? The ones everybody knows about are related to pointer aliasing, but the restrict keyword has been around for ages now.
Rust Posted Apr 7, 2013 17:59 UTC (Sun) by mathstuf (subscriber, #69389) [Link]
So, in Haskell, because pure functions are guaranteed to not modify data, the compiler is allowed to "fuse" operations[1] instead of doing exactly what a naïve reading of the code implies (strict order of expressions to be evaluated). This allows the simple map function to act like C++'s std::transform and optimize the specific calls being made (usually via inlining then optimization), but GHC can optimize the calls on a single data structure being operated on across function boundaries and fuse the map calls together ((map (f . g)) list rather than (map f . map g) list where map f and map g are in different functions). I don't think C++'s std::transform gets optimized like this (and even if it did, f and g can't necessarily be called gfgfgf rather than gggfff).
[1]This is how Eigen gets a lot of performance: by storing expressions instead of evaluating additions immediately, Eigen can merge loops together to get one loop with 3 operations in it rather than 3 loops with one operation each which wins on cache access and in hot loops, matters a lot.
Rust Posted Apr 7, 2013 18:08 UTC (Sun) by hummassa (subscriber, #307) [Link]
The restrict keyword, by itself, does not add some opportunities for loop unrollings where aliased things are used inside the loops.
The lack of defining pure functions, without side-effects, also elide some opportunities for repeated code removal.
Rust Posted Apr 7, 2013 18:11 UTC (Sun) by mathstuf (subscriber, #69389) [Link]
GCC does have a pure attribute, but it's not verified that you're using it properly and no one uses it anyways…
Rust Posted Apr 7, 2013 21:50 UTC (Sun) by HelloWorld (guest, #56129) [Link] The restrict keyword, by itself, does not add some opportunities for loop unrollings where aliased things are used inside the loops.I don't understand that, can you give an example? The lack of defining pure functions, without side-effects, also elide some opportunities for repeated code removal.Modern optimising compilers try to figure out whether a function is pure and optimise accordingly. Example:
#include <stdio.h>
int sq(int i) {
return i*i;
}
int main(int argc, char **argv) {
int i = strtol(argv[1], 0, 0);
printf("%d\n", sq(i) * sq(i));
return 0;
}
Compiled with gcc -O3 -fno-inline-small-functions -S -masm=intel (gcc 4.7.2) this yields
...
call strtol
mov edi, eax
call sq
imul eax, eax
mov edi, OFFSET FLAT:.LC0
mov esi, eax
xor eax, eax
call printf
...
So gcc sees that sq is a pure function and only calls it once, even though it's called twice in the source code. Granted, this isn't quite the same as in Fortran as the compiler needs to be able to see the definition of the relevant function for this to work. But due to link-time optimisation this isn't as big a limitation as it used to be. I'm not convinced the Fortran way offers significant benefits in the real world.
Rust Posted Apr 7, 2013 14:04 UTC (Sun) by anselm (subscriber, #2796) [Link] A Fortran compiler is allowed by the language definition to make all sorts of assumptions that are unavailable to a C compiler. This gives a Fortran compiler room for various optimisations that a C compiler can't do to the same degree. This means that for the typical sort of program one would write in Fortran, a Fortran compiler is at a distinct advantage compared to a C compiler as far as optimisation is concerned. On the other hand, C allows you to write programs with reasonable ease that can't be conveniently expressed at all in Fortran (one notable example being the Linux kernel). In addition, direct translation of Fortran source code to C (and vice versa) usually leads to significantly worse performance in the new language if arrays are involved, simply because Fortran assumes that arrays are stored in row-major order while C assumes a column-major arrangement. In a speed comparison of programs written in both languages, factors like these ought to be controlled for.
Rust Posted Apr 7, 2013 15:10 UTC (Sun) by HelloWorld (guest, #56129) [Link]
> A Fortran compiler is allowed by the language definition to make all sorts of assumptions that are unavailable to a C compiler.
What assumptions? The one that people keep bringing up (pointer aliasing issues) was fixed a long time ago with the restrict keyword.
> In addition, direct translation of Fortran source code to C (and vice versa) usually leads to significantly worse performance in the new language if arrays are involved, simply because Fortran assumes that arrays are stored in row-major order while C assumes a column-major arrangement.
Rust Posted Apr 8, 2013 1:58 UTC (Mon) by roc (subscriber, #30627) [Link]
Rust isn't designed to be "a better C++". It's designed to provide features C++ doesn't have:
-- Type/memory safety guarantees -- Parallel programming with a guarantee of no data races (primarily by enforcing "no mutable shared memory") -- Lightweight isolated tasks as a unit of failure
Developers who don't want those things should stick to C++. Developers who want all those things can't get them from C++ and should consider Rust, among other alternatives. Developers who want those things in a language which is as close as possible to C++ in performance should strongly consider Rust.
|
|||||||||||||