Re: [rust-dev] Encapsulating mutiple generic types
Can you use a trait for that?
trait Database: Store + Logger {}
On Mon, Dec 1, 2014 at 11:48 AM, Philippe Daouadi blastro...@free.fr
wrote:
Hi,
In my project, I use something like:
struct Database {
db: BoxStore + 'static,
logger: BoxLogger + 'static,
}
Does anyone know what is the difference? They seem to work the same to me.
Philippe
On 12/01/2014 05:04 PM, Federico Ravasio wrote:
понедельник, 1 декабря 2014 г. в 16:59, Ryan Michael написал:
I'm curious if the community has some design approaches to encapsulating
interfaces to multiple generic implementations. For example, imagine I was
writing an abstract database interface with multiple backing
implementations for different stores (sqlite, pgsql, mysql, etc) and
logging data to different types of loggers (stdout, file, network-attached,
etc). The goal would be to implement some shared methods (insert, query,
delete) to be delegated to different stores, with logging about the results.
My first approach to this was to create traits, and use them in a
struct
trait Logger {
fn log(mut self, message: String),
}
trait Store {
fn insert(mut self, value: String),
fn query(mut self, conditions: String) - VecString,
fn delete(mut self, value: String),
}
struct Database {
db: Store,
logger: Logger,
}
AFAICT, this isn't possible - struct fields seem to require concrete
types.
Hello Ryan,
I’ve had some luck by wrapping trait fields into boxes, with explicit
lifetimes.
This should work:
struct Database'a {
db: BoxStore + 'a,
logger: BoxLogger + 'a,
}
Now, I’m not sure if that’s a community-accepted solution. Let’s see what
the others think. :)
Cheers,
Federico
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Why there's this asymmetry in defining a generic type/function/method and calling it?
On Tue, Nov 18, 2014 at 12:23 PM, Daniel Trstenjak daniel.trsten...@gmail.com wrote: Hi Steven, On Tue, Nov 18, 2014 at 07:41:38PM +, Steven Fackler wrote: The syntax is ambiguous: let foo = (HashMapFoo, Barnew()); You mean 'let foo = (HashMapFoo, Bar::new());' , right? Is '::new()' a valid expression for accessing some kind of global or super namespace? Correct http://is.gd/6T0U3R; the `::` prefix resolves from the crate root; unprefixed resolves from the module root. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] type annotaion of mut
That doesn't seem to be what the compilation error says:
mut.rs:10:19: 10:20 error: use of moved value: `a`
mut.rs:10 println!({},a);
^
note: in expansion of format_args!
std macros:2:23: 2:77 note: expansion site
std macros:1:1: 3:2 note: in expansion of println!
mut.rs:10:5: 10:22 note: expansion site
mut.rs:6:13: 6:14 note: `a` moved here because it has type `mut int`,
which is moved by default (use `ref` to override)
mut.rs:6 let b = a;
It isn't intuitive that type-annotating `b` would make this error go away.
On Mon, Sep 22, 2014 at 10:54 AM, Steve Klabnik st...@steveklabnik.com
wrote:
Because you need to make b mutable to change its value. Rust's
variable bindings are immutable by default.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] reader.lines() swallows io errors
On Tue, Feb 18, 2014 at 11:52 PM, Phil Dawes rustp...@phildawes.net wrote:
Is that not a big problem for production code? I think I'd prefer the
default case to be to crash the task than deal with a logic bug.
The existence of library functions that swallow errors makes reviewing
code and reasoning about failure cases a lot more difficult.
There are other methods that allow one to read lines and handle error
cases. `Lines` is a convenience method by design.
On Tue, Feb 18, 2014 at 11:02 AM, Kang Seonghoon some...@mearie.orgwrote:
I think the following documentations describe this behavior pretty well.
http://static.rust-lang.org/doc/master/std/io/trait.Buffer.html#method.lines
http://static.rust-lang.org/doc/master/std/io/struct.Lines.html
As the documentation puts, this behavior is intentional as it would be
annoying for casual uses otherwise.
2014-02-18 17:16 GMT+09:00 Phil Dawes rustp...@phildawes.net:
Hello everyone,
I was cutting and pasting the following example from the std lib docs:
http://static.rust-lang.org/doc/master/std/io/index.html
Iterate over the lines of a file
use std::io::BufferedReader;
use std::io::File;
let path = Path::new(message.txt);
let mut file = BufferedReader::new(File::open(path));
for line in file.lines() {
print!({}, line);
}
.. and I noticed that file.lines() swallows io errors. Given that this
code
will probably be copied a bunch by people new to the language (including
me!) I was thinking it might be worth adding a comment to point this
out or
changing to remove the source of bugs.
(BTW, thanks for Rust - I'm enjoying following the language and hope to
use
it as a safer replacement for C++ for latency sensitive code.)
Cheers,
Phil
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
-- Kang Seonghoon | Software Engineer, iPlateia Inc. | http://mearie.org/
-- Opinions expressed in this email do not necessarily represent the
views of my employer.
--
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Nick Cameron joins the Rust team at Mozilla
Fantastic! Good luck, Nick! On Mon, Feb 3, 2014 at 6:51 PM, Alex Crichton a...@crichton.co wrote: Welcome Nick! I can't wait to see that 1.0 issue count go down! On Mon, Feb 3, 2014 at 6:20 PM, Brian Anderson bander...@mozilla.com wrote: Hi Rusties, I'm just thrilled to announce today that Nick Cameron (nrc) has joined Mozilla's Rust team full-time. Nick has a PhD in programming language theory from Imperial College London and has been hacking on Gecko's graphics and layout for two years, but now that he's all ours you'll be seeing him eradicate critical Rust bugs by the dozens. Good luck, Nick, and welcome to the party. Regards, Brian ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Proposal: Change Parametric Polymorphism Declaration Syntax
On Sat, Feb 1, 2014 at 3:06 PM, Benjamin Striegel ben.strie...@gmail.comwrote:
Another point in favor of this plan is that it would eliminate the need to
put type parameters directly after the `impl`, which to be honest *is*
pretty weird and inconsistent with the rest of the language. But I'm still
not sure how I feel about the look of it:
for T: Clone+Eq, U fn foo(t: T, u: U) - (T, U) {
If you choose *not* to wrap after the type parameters there, you're really
obscuring what the heck you're trying to declare.
Heck, maybe what we're really asking for is for the ability to have
generic blocks within which type parameters can be declared once:
for T: Clone+Eq, U {
fn foo(t: T, u: U) - (T, U) {
...but that's even *more* boilerplate!
It'd mirror how impls work, though, which would be nice. It could be
optional.
On Sat, Feb 1, 2014 at 5:59 PM, Benjamin Striegel
ben.strie...@gmail.comwrote:
Yes, and I don't have a solution for that.
Well, it's not like we don't already stumble here a bit, what with
requiring :: instead of just . Not sure how much other people value the
consistency here.
On Sat, Feb 1, 2014 at 5:58 PM, Corey Richardson co...@octayn.netwrote:
On Sat, Feb 1, 2014 at 5:55 PM, Benjamin Striegel
ben.strie...@gmail.com wrote:
First of all, why a new keyword? Reusing `for` here would be totally
unambiguous. :P And also save us from creating the precedent of
multi-word
keywords.
I'd be equally happy with for instead of forall.
Secondly, currently Rust has a philosophy of use-follows-declaration
(i.e.
the syntax for using something mirrors the syntax for declaring it).
This
would eliminate that.
Yes, and I don't have a solution for that.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Placement new and the loss of `new` to keywords
On Sun, Dec 1, 2013 at 8:04 AM, spir denis.s...@gmail.com wrote: On 12/01/2013 02:51 AM, Florian Zeitz wrote: If I may chime in here. I agree with Kevin that the different semantics of `new` are more likely to create confusion, than alleviate it. Personally I would suggest calling this operator `box`, since it boxes its argument into a newly allocated memory box. After all, these are different semantics from C++'s `new` (and also Go's `make` AFAICT), therefore, presuming that a sigil is not a sufficient indicator of a non-stack allocation, using an unprecedented keyword seems the way to go to me. +++ to all 3 points Denis I, too, am in favor of the `box` proposal. Short, intuitive, not already commonly used. What's not to like? Cheers, Tim ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Removing some autoref magic
This strikes me as a good point. I think the incongruity this would create between functions and methods -- along with the additional syntactic burden -- could lead to the use of functions feeling second class in some sense. Also, how would static methods be treated? Cheers, Tim On Wed, Nov 20, 2013 at 8:47 PM, Tommi rusty.ga...@icloud.com wrote: On 2013-11-20, at 18:27, Patrick Walton pcwal...@mozilla.com wrote: On 11/19/13 9:42 PM, Tommi wrote: Our problem is that, given let arg: ~A;, seeing only foo(arg) in code doesn't tell us whether arg is moved or borrowed. The proposed solution is that auto-borrowing in that context would be deprecated and thus would require an explicit borrowing: foo(*arg). Now, given that it seems that the upcoming UFCS would simply re-write arg.foo() to foo(arg), it would mean that seeing only arg.foo() in code doesn't tell us whether arg is moved or borrowed. Thus, the proposed solution would fix only half of the problem. Again, I don't see this as an argument against the proposal. The dot operator is always magical. Magic on one place doesn't justify magic everywhere. Patrick The goal of the proposal is to disambiguate code by forcing programmers to write foo(*arg) instead of foo(arg). But I claim that the proposal will at least partly fail to achieve that goal because programmers will simply resort to writing arg.foo() rather than foo(*arg), and we finish where we started. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] How would you map one vector to a vector of a different element type?
Instead of `do spawn` try `do spawn_with(s) |s| { ... }`. Then the closure
won't close over s, but rather take it as an argument, allowing it to move
it out.
Cheers
On Sat, Nov 2, 2013 at 5:05 PM, Leah Hanson astriea...@gmail.com wrote:
Thanks, Brendan. :)
You’re trying to move the ~strs out of the vector. You’ll need to use
`move_iter`:
Is this moving about moving memory around or about promising the
compiler that I won't use those elements of the vector again?
~~~
let ports = do myvect.move_iter().map |s| {
let (pport, cchan) = stream();
do spawn {
cchan.send(fun(s))
}
pport
}.to_owned_vec();
There is still a problem because something (I guess the `do spawn {...}`)
is a heap closure.
- error: cannot move out of captured outer variable in a heap closure
- cchan.send(fun(s))
I think that this error message is complaining because I'm trying to move
s, the ~str that the `do spawn {...}` closes over, to a new task.
And I'm not allowed to move it because it is apparently a heap closure.
Is there some other kind of closure that does work here? Or some way to
make this not a closure?
Thanks,
Leah
On Sat, Nov 2, 2013 at 4:24 PM, Brendan Zabarauskas
bjz...@yahoo.com.auwrote:
You’re trying to move the ~strs out of the vector. You’ll need to use
`move_iter`:
~~~
let ports = do myvect.move_iter().map |s| {
let (pport, cchan) = stream();
do spawn {
cchan.send(fun(s))
}
pport
}.to_owned_vec();
~~~
Also note the use of `to_owned_vec`. `map` lazily returns a `Map`
iterator - you need to explicitly drain it.
(Note I haven’t tried compiling this)
~Brendan
On 3 Nov 2013, at 7:04 am, Leah Hanson astriea...@gmail.com wrote:
Thanks, Scott, I think that's closer.
However, now I'm having trouble with my pointer types. Using the
element inside a spawn means that I need to capture the owned string in the
right way so that the compiler allows me to give it to the other task.
This version:
~~~
let ports = do myvect.iter().map |s| {
let (pport, cchan) = stream();
do spawn {
cchan.send(fun(*s))
}
pport
};
~~~
gives me pointer-type related errors:
• error: cannot move out of dereference of pointer
• cchan.send(fun(*s))
• error: cannot borrow immutable local variable as mutable
• when I iterate over the Ports later
• error: cannot capture variable of type `~str`, which does not
fulfill `Send`, in a bounded closure
• cchan.send(fun(*s))
I also tried a version with |s| and cchan.send(fun(s)), which gave me
different errors:
• error: cannot move out of captured outer variable in a heap
closure
• cchan.send(fun(*s))
• error: cannot move out of dereference of pointer
• on the |s|
• error: cannot borrow immutable local variable as mutable
• when I iterate over the Ports later
I'm very new to Rust. What do I need to do to let the compiler know
that I'm not going to use anything in the first vec anymore? That I just
want the ~str pointers directly?
(I put the |s| outside the {} because putting it inside seemed to
confuse things -- in that case, rustc expected an identifier instead of the
`let` that comes next, so I assumed that `do v.iter().map {|s| ...}` is a
syntax error.)
Thanks,
Leah
On Sat, Nov 2, 2013 at 3:23 PM, Scott Lawrence byt...@gmail.com
wrote:
I would think:
let ports = do myvect.iter().map { |e| something(e) }
On Sat, 2 Nov 2013, Leah Hanson wrote:
Hi,
I have a ~[~str]. I have code that will turn a ~str into a Portuint.
I want to end up with a [Portuint]. (or ~ or @ or whatever. I just
want
to be able to iterate over the Ports later.)
Since I'm not sure what looping construct to use, I tried with a
for-each
loop.
~~~
let ports = for s in myvect.iter() {
let (pport, cchan) = stream();
do spawn {
cchan.send(fun(*s))
}
pport
};
~~~
As you might, expect I got an error:
error: mismatched types: expected `()` but found `std::comm::Portuint`
(expected () but found struct std::comm::Port)
From this, I take it that for loops must return `()`, rather than an
actual
value. When I searched for a map function in the documentation, I only
found a Map type.
How would you map one vector to a vector of a different element type?
Thanks,
Leah
--
Scott Lawrence
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Re: [rust-dev] Unified function/method call syntax and further
simplification MIME-Version: 1.0 Content-Type: multipart/mixed; boundary7823106168118235853== --===7823106168118235853== Content-Type: multipart/alternative; boundary=4SVSQE8L3ECYN7Z8RACUF07S828YYG --4SVSQE8L3ECYN7Z8RACUF07S828YYG Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I haven't been completely following this discussion as it's a bit over my head, but if two different types define a method of the same name, it seems to me that there'd be no ambiguity. Java allows function overloading; wouldn't this sort of be similar? From: Patrick Walton Sent: =E2=80=8E10/=E2=80=8E20/=E2=80=8E2013 2:01 PM To: G=C3=A1bor Lehel; Marijn Haverbeke Cc: rust-dev@mozilla.org Subject: Re: [rust-dev] Unified function/method call syntax and further simplification What would happen if two types defined a method called, say, foo, and the= importing module glob imported them both? Patrick G=C3=A1bor Lehel illiss...@gmail.com wrote: On Sun, Oct 20, 2013 at 7:31 PM, G=C3=A1bor Lehel illiss...@gmail.com wrote: So I very much agree with Patrick. Some aspects of this proposal are attractive, but it breaks some essential properties of the way methods currently work (and probably can't be adjusted to work around that without losing most of it attraction). The main cost would be having to import methods explicitly (or using a glob), as Patrick notes. Now I'm wondering, though: going with my proposal, if the module structure were just a little bit more fine-grained, I think you could achieve basically the same effect as the current system, if you wanted to. If the convention were to use a module to enclose a type together with its methods (which is already the case in many places), and you did a glob import of that module, you would get what you have now: the type and its methods would all come into scope. Except you could still import selectively, if you wanted to, or do things any other way, if you wanted to, and all of the warts I mentioned would still disappear. In a different crate, you could similarly create a module of extension methods, which could be imported together or selectively, if you wanted to. I don't want to push this too hard if it's past the point of being productive, but I'm now even more convinced that this would be a beneficial change. Types should be types, grouping and scoping should be done with modules (Rust's modules are very capable), and traits should be used for type-based abstraction. I think it would work great. --=20 Your ship was destroyed in a monadic eruption. --=20 Sent from my Android phone with K-9 Mail. Please excuse my brevity. --4SVSQE8L3ECYN7Z8RACUF07S828YYG Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable HTMLHEAD META content=3Dtext/html; charset=3Dutf-8 http-equiv=3DContent-Type/HE= AD BODY DIV DIV style=3DFONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serifI haven't b= een completely following this discussion as it's a bit over my head, but if= two different types define a method of the same name, it seems to me that = there'd be no ambiguity. Java allows function overloading; wouldn't this so= rt of be similar?/DIV/DIV DIV dir=3Dltr HR SPAN style=3DFONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGH= T: boldFrom: /SPANSPAN style=3DFONT-SIZE: 11pt; FONT-FAMILY: Calibri,= sans-serifA href=3Dmailto:pwal...@mozilla.com;Patrick Walton/A/SPAN= BRSPAN style=3DFONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-= WEIGHT: boldSent: /SPANSPAN style=3DFONT-SIZE: 11pt; FONT-FAMILY: Cal= ibri,sans-serif=E2=80=8E10/=E2=80=8E20/=E2=80=8E2013 2:01 PM/SPANBRS= PAN style=3DFONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGHT:= boldTo: /SPANSPAN style=3DFONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans= -serifA href=3Dmailto:illiss...@gmail.com;G=C3=A1bor Lehel/A; A hre= f=3Dmailto:mari...@gmail.com;Marijn Haverbeke/A/SPANBRSPAN style= =3DFONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGHT: boldCc= : /SPANSPAN style=3DFONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif= A href=3Dmailto:rust-dev@mozilla.org;rust-dev@mozilla.org/A/SPANBR= SPAN style=3DFONT-SIZE: 11pt; FONT-FAMILY: Calibri,sans-serif; FONT-WEIGHT= : boldSubject: /SPANSPAN style=3DFONT-SIZE: 11pt; FONT-FAMILY: Calibr= i,sans-serifRe: [rust-dev] Unified function/method call syntax and furthe= r simplification/SPANBRBR/DIV/BODY/HTMLhtmlhead/headbody= What would happen if two types defined a method called, say, quot;fooquo= t;, and the importing module glob imported them both?br br Patrickbrbrdiv class=3Dgmail_quotequot;G=C3=A1bor Lehelquot; lt;= illiss...@gmail.comgt; wrote:blockquote class=3Dgmail_quote style=3Dma= rgin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding= -left: 1ex; div dir=3Dltrdiv class=3Dgmail_extradiv class=3Dgmail_quoteOn S= un, Oct 20, 2013 at 7:31 PM, G=C3=A1bor Lehel span dir=3Dltrlt;a href= =3Dmailto:illiss...@gmail.com;
Re: [rust-dev] Minimal raytracer
To make it a fair fight, I converted the Go and C++ versions to trace Rust instead. These are my results on my Macbook Pro: === RUST === $ rustc -O bin.rs $ time ./bin rrays.ppm real 0m14.472s user 0m14.102s sys 0m0.365s === GO === $ go build main.go $ time ./main grays.ppm real 0m13.928s user 0m13.914s sys 0m0.020s === C++ === $ gcc -O crays.cpp $ time ./a.out crays.ppm real 0m10.800s user 0m10.794s sys 0m0.005s === RANKINGS === 1) C++ : 10.8s 2) Go : 13.9s 3) Rust : 14.5s On Tue, Sep 24, 2013 at 1:59 PM, Geoffrey Irving irv...@naml.us wrote: It seems like rust would perform better in this benchmark against languages like Erlang and Haskell, which have even longer names. Geoffrey On Sep 24, 2013, at 10:08 AM, John Mija jon...@proinbox.com wrote: Summary: Rustc 17.7s, Go 13.6s, Clang 11.2s, GCC 10.4s. Note that the versions in Clang, G++ and Go are rendering the word Go while that the Rust version is rendering a word bigger Rust System: x86_64 GNU/Linux 3.8.0-30-generic Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz 4 GB RAM I've used Rust trunk, Go 1.1.2: $ gcc --version gcc (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3 $ clang --version Ubuntu clang version 3.2-1~exp9ubuntu1 (tags/RELEASE_32/final) (based on LLVM 3.2) Target: x86_64-pc-linux-gnu Thread model: posix $ go version go version go1.1.2 linux/amd64 $ rust --version rust 0.8 (b6fe27c 2013-09-24 07:06:09 -0700) host: x86_64-unknown-linux-gnu * * * $ rustc --opt-level=3 raytracer.rs -o rayt-rust $ time ./rayt-rust rayt-rust.ppm real 0m17.746s user 0m17.332s sys 0m0.404s $ go tool 6g raytracer.go go tool 6l -o rayt-go raytracer.6 rm raytracer.6 $ time ./rayt-go rayt-go.ppm real 0m13.664s user 0m13.656s sys 0m0.008s $ clang -O3 -lm raytracer.cpp -o rayt-clang $ time ./rayt-clang rayt-clang.ppm real 0m11.199s user 0m11.188s sys 0m0.004s $ g++ -O3 -lm raytracer.cpp -o rayt-g++ $ time ./rayt-g++ rayt-g++.ppm real 0m10.411s user 0m10.404s sys 0m0.000s El 24/09/13 14:52, Huon Wilson escribió: On 24/09/13 16:18, John Mija wrote: Since a post in HN about a raytracer into a business card, a guy built the implementation in Go: https://groups.google.com/forum/#!topic/golang-nuts/mxYzHQSV3rw The C++ version: https://gist.github.com/kid0m4n/6680629 The Go version: https://github.com/kid0m4n/gorays Performance (2.2 Ghz Quad Core (2675QM), 16 GB RAM, OX 10.9, Go 1.1.2): C++ version: 11.803 s Go version: 28.883 s * * * It would be interesting if somebody with experience in Rust could build the version in Rust to compare the speed. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev I bit: https://github.com/huonw/card-trace Summary: Clang 13.8s, GCC 17.9s, Rustc 17.9s. (1.9GHz 3517U, 8 GB, linux. GCC: 4.8.1, Clang: 3.3, rustc: 18e3bcd 2013-09-23 23:46:05 -0700.) I just did essentially a transliteration of the C++ into (reasonably idiomatic) Rust, I imagine one could make it faster with some effort, but that would be cheating (at least, it would then become a test of *my* micro-optimisation ability, rather than that of the compilers). It appears that clang vectorises/uses SSE directly more eagerly than either gcc or rustc from some quick poking with perf. (I don't have Go on this computer to compare; although I imagine the only comparison of interest would be with gccgo, since normal go doesn't optimise anywhere near as much as LLVM does.) Huon ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] Minimal raytracer
I'd be curious to know if changing rustc -O to rustc --opt-level=3 has any effect. Which is to say, I'm curious if currently we make any distinction at all between opt levels 2 and 3. There was no difference when I ran it with --opt-level=3. Also, what version of Rust? I believe our support for LLVM-SIMD-vectorization-pass voodoo only landed recently. My rust is current as of sometime yesterday. On Tue, Sep 24, 2013 at 3:51 PM, Benjamin Striegel ben.strie...@gmail.comwrote: I'd be curious to know if changing rustc -O to rustc --opt-level=3 has any effect. Which is to say, I'm curious if currently we make any distinction at all between opt levels 2 and 3. Also, what version of Rust? I believe our support for LLVM-SIMD-vectorization-pass voodoo only landed recently. On Tue, Sep 24, 2013 at 2:13 PM, Tim Kuehn tku...@cmu.edu wrote: To make it a fair fight, I converted the Go and C++ versions to trace Rust instead. These are my results on my Macbook Pro: === RUST === $ rustc -O bin.rs $ time ./bin rrays.ppm real 0m14.472s user 0m14.102s sys 0m0.365s === GO === $ go build main.go $ time ./main grays.ppm real 0m13.928s user 0m13.914s sys 0m0.020s === C++ === $ gcc -O crays.cpp $ time ./a.out crays.ppm real 0m10.800s user 0m10.794s sys 0m0.005s === RANKINGS === 1) C++ : 10.8s 2) Go : 13.9s 3) Rust : 14.5s On Tue, Sep 24, 2013 at 1:59 PM, Geoffrey Irving irv...@naml.us wrote: It seems like rust would perform better in this benchmark against languages like Erlang and Haskell, which have even longer names. Geoffrey On Sep 24, 2013, at 10:08 AM, John Mija jon...@proinbox.com wrote: Summary: Rustc 17.7s, Go 13.6s, Clang 11.2s, GCC 10.4s. Note that the versions in Clang, G++ and Go are rendering the word Go while that the Rust version is rendering a word bigger Rust System: x86_64 GNU/Linux 3.8.0-30-generic Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz 4 GB RAM I've used Rust trunk, Go 1.1.2: $ gcc --version gcc (Ubuntu/Linaro 4.7.3-1ubuntu1) 4.7.3 $ clang --version Ubuntu clang version 3.2-1~exp9ubuntu1 (tags/RELEASE_32/final) (based on LLVM 3.2) Target: x86_64-pc-linux-gnu Thread model: posix $ go version go version go1.1.2 linux/amd64 $ rust --version rust 0.8 (b6fe27c 2013-09-24 07:06:09 -0700) host: x86_64-unknown-linux-gnu * * * $ rustc --opt-level=3 raytracer.rs -o rayt-rust $ time ./rayt-rust rayt-rust.ppm real 0m17.746s user 0m17.332s sys 0m0.404s $ go tool 6g raytracer.go go tool 6l -o rayt-go raytracer.6 rm raytracer.6 $ time ./rayt-go rayt-go.ppm real 0m13.664s user 0m13.656s sys 0m0.008s $ clang -O3 -lm raytracer.cpp -o rayt-clang $ time ./rayt-clang rayt-clang.ppm real 0m11.199s user 0m11.188s sys 0m0.004s $ g++ -O3 -lm raytracer.cpp -o rayt-g++ $ time ./rayt-g++ rayt-g++.ppm real 0m10.411s user 0m10.404s sys 0m0.000s El 24/09/13 14:52, Huon Wilson escribió: On 24/09/13 16:18, John Mija wrote: Since a post in HN about a raytracer into a business card, a guy built the implementation in Go: https://groups.google.com/forum/#!topic/golang-nuts/mxYzHQSV3rw The C++ version: https://gist.github.com/kid0m4n/6680629 The Go version: https://github.com/kid0m4n/gorays Performance (2.2 Ghz Quad Core (2675QM), 16 GB RAM, OX 10.9, Go 1.1.2): C++ version: 11.803 s Go version: 28.883 s * * * It would be interesting if somebody with experience in Rust could build the version in Rust to compare the speed. ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev I bit: https://github.com/huonw/card-trace Summary: Clang 13.8s, GCC 17.9s, Rustc 17.9s. (1.9GHz 3517U, 8 GB, linux. GCC: 4.8.1, Clang: 3.3, rustc: 18e3bcd 2013-09-23 23:46:05 -0700.) I just did essentially a transliteration of the C++ into (reasonably idiomatic) Rust, I imagine one could make it faster with some effort, but that would be cheating (at least, it would then become a test of *my* micro-optimisation ability, rather than that of the compilers). It appears that clang vectorises/uses SSE directly more eagerly than either gcc or rustc from some quick poking with perf. (I don't have Go on this computer to compare; although I imagine the only comparison of interest would be with gccgo, since normal go doesn't optimise anywhere near as much as LLVM does.) Huon ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev ___ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
Re: [rust-dev] average function
There's also std::iter::AdditiveIterator.
fn averageT: Num + NumCast + Clone(values: [T]) - T {
let sum = values.iter().map(|n| n.clone()).sum();
sum / num::cast(values.len())
}
On Tue, Sep 24, 2013 at 7:36 PM, Brendan Zabarauskas bjz...@yahoo.com.auwrote:
I normally prefer using `std::num::{cast, zero}` as its a tad more
readable. So:
use std::num;
fn averageT:Int(values: [T]) - T {
values.iter()
.fold(num::zero::T(), |x, y| x.add(y))
.div(num::cast(values.len()))
}
fn main() {
print!({}, average([1,2,3]))
}
On 25/09/2013, at 8:09 AM, Scott Lawrence byt...@gmail.com wrote:
Use NumCast::from(count).
You'll also want to be sure to initialize sum. I'd use the Zero instance.
use std::num::Zero;
fn averageT:Int(values:[T]) - T {
let count = values.len();
let mut sum:T = Zero::zero();
for v in values.iter() {
sum = sum.add(v);
}
return sum / NumCast::from(count);
}
fn main() {
println(fmt!(%d, average([1,2,3])))
}
On Wed, 25 Sep 2013, Andreas Zwinkau wrote:
I tried to write an average function, but so far failed to convince
the type checker.
fn averageT:Int(values:[T]) - T {
let count = values.len();
let mut sum:T;
for v in values.iter() {
sum = sum.add(v);
}
return sum / count;
}
error: mismatched types: expected `T` but found `uint` (expected type
parameter but found uint)
The problem is that sum is the generic type T, but count is uint due
to the definition of the len function. Casting count as T should
work, i thought, but rustc seems to have another opinion?
--
Andreas Zwinkau
work email: zwin...@kit.edu
private email: q...@web.de
homepage: http://beza1e1.tuxen.de
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
--
Scott Lawrence
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
