Re: [rust-dev] Integer overflow, round -2147483648

On 23/06/14 14:46, comex wrote: On Mon, Jun 23, 2014 at 12:35 AM, Daniel Micay wrote: An operation that can unwind isn't pure. It impedes code motion such as hoisting operations out of a loop, which is very important for easing the performance issues caused by indexing bounds checks. LLVM doesn

Re: [rust-dev] Integer overflow, round -2147483648

I would think that something simple like let mut sum = 0; for x in some_int_array.iter() { sum += x; } would be very hard to vectorise with unwinding integer operations. It sounds like there are two problems. First, you need to give up on precise exceptions. So the code beco

Re: [rust-dev] Integer overflow, round -2147483648

> Ada's approach to integer overflows is substantially similar to AIR Isn't Ada's response to overflow implementation-defined? On Mon, Jun 23, 2014 at 11:37 AM, John Regehr wrote: > I would think that something simple like >> >>let mut sum = 0; >>for x in some_int_array.iter() { >>

Re: [rust-dev] Generic Database Bindings

hey rust community , i want initiate this project .. where can i get started ? * Laxmi Narayan Patel* * MCA NIT Durgapur (2011-2014)* * Mob:-8345847473* On Tue, Jun 10, 2014 at 2:09 AM, Eli Green wrote: > Having looked at this library and the other

Re: [rust-dev] Integer overflow, round -2147483648

On 22/06/14 12:16 PM, SiegeLord wrote: > On 06/22/2014 11:32 AM, Benjamin Striegel wrote: >> This is a mistaken assumption. Systems programming exists on the extreme >> end of the programming spectrum where edge cases are the norm, not the >> exception, and where 80/20 does not apply. > > Even in

Re: [rust-dev] Integer overflow, round -2147483648

> Ada's approach to integer overflows is substantially similar to AIR Isn't Ada's response to overflow implementation-defined? Sort of. First, the standard seems to require a Constraint_Error when signed integer overflow happens. For example, on page 47 of the ADA 2012 standard: "For a sig

Re: [rust-dev] Integer overflow, round -2147483648

Using checked overflow will reduce the performance of most code with non-trivial usage of integer arithmetic by 30-70%. No, this view is overly pessimistic. The last time we checked, Clang with the integer sanitizer turned on had a little less than 30% overhead for SPEC CINT 2006, on average.

Re: [rust-dev] Integer overflow, round -2147483648

On 23/06/14 03:15 PM, John Regehr wrote: >> Using checked overflow will >> reduce the performance of most code with non-trivial usage of integer >> arithmetic by 30-70%. > > No, this view is overly pessimistic. My numbers are based on real measurements, and are accurate. You can pick and choose d

Re: [rust-dev] Integer overflow, round -2147483648

On Jun 22, 2014, at 4:12 PM, Patrick Walton wrote: > On 6/22/14 2:12 PM, Cameron Zwarich wrote: >> For some applications, Rust’s bounds checks and the inability of rustc >> to eliminate them in nontrivial cases will already be too much of a >> performance sacrifice. What do we say to those people

Re: [rust-dev] Integer overflow, round -2147483648

On Mon, Jun 23, 2014 at 12:50 PM, Daniel Micay wrote: > The discussion here is about checking for both signed / unsigned integer > overflow, as in passing both `-fsanitize=signed-integer-overflow` and > `-fsanitize=unsigned-integer-overflow`. Rust has defined signed overflow > already so it doesn'

[rust-dev] Compiling Rust apps with Meson v2

Hi I finished basic Rust support for the Meson build system. It now supports shared and static libraries with full install support and all that. Here's the entire build definition for a library and two executables that use it. project('libproject', 'rust') corelib = shared_library('core',

Re: [rust-dev] Integer overflow, round -2147483648

I doubt it, since Swift has a high level IR above LLVM IR and the implementation isn't open-source. The language-specific optimizations like removing overflow / bounds checks based on type system rules will almost certainly be done on the high-level SIL IR, not at the LLVM IR layer where most of t

Re: [rust-dev] Integer overflow, round -2147483648

On Monday, June 23, 2014, Daniel Micay wrote: > Rust is not a language designed for an imaginary sufficiently smart > compiler. It targets real architectures and the real LLVM backend. > I hate to keep throwing hypotheticals at you, but here's another one: what if Apple invests in LLVM developme

Re: [rust-dev] Integer overflow, round -2147483648

On 23/06/14 04:10 PM, Tony Arcieri wrote: > On Monday, June 23, 2014, Daniel Micay > wrote: > > Rust is not a language designed for an imaginary sufficiently smart > compiler. It targets real architectures and the real LLVM backend. > > > I hate to keep thr

Re: [rust-dev] Integer overflow, round -2147483648

On 23/06/14 04:01 PM, John Regehr wrote: >> I doubt it, since Swift has a high level IR above LLVM IR and the >> implementation isn't open-source. The language-specific optimizations >> like removing overflow / bounds checks based on type system rules will >> almost certainly be done on the high-le

Re: [rust-dev] Integer overflow, round -2147483648

On 23/06/14 04:00 PM, Gregory Maxwell wrote: > On Mon, Jun 23, 2014 at 12:50 PM, Daniel Micay wrote: >> The discussion here is about checking for both signed / unsigned integer >> overflow, as in passing both `-fsanitize=signed-integer-overflow` and >> `-fsanitize=unsigned-integer-overflow`. Rust

Re: [rust-dev] Integer overflow, round -2147483648

On Mon, Jun 23, 2014 at 3:50 PM, Daniel Micay wrote: > I doubt it, since Swift has a high level IR above LLVM IR and the > implementation isn't open-source. The language-specific optimizations > like removing overflow / bounds checks based on type system rules will > almost certainly be done on th

Re: [rust-dev] Integer overflow, round -2147483648

On 23/06/14 03:59 PM, Cameron Zwarich wrote: > On Jun 22, 2014, at 4:12 PM, Patrick Walton wrote: > >> On 6/22/14 2:12 PM, Cameron Zwarich wrote: >>> For some applications, Rust’s bounds checks and the inability of rustc >>> to eliminate them in nontrivial cases will already be too much of a >>>

Re: [rust-dev] Integer overflow, round -2147483648

On 6/23/14 1:55 PM, Daniel Micay wrote: It's not much a systems language if it's slower than an inner loop in a JavaScript program without going out of your way to avoid the overhead. I agree with your general concerns, but I should nitpick that it won't be slower than JavaScript, since JS nee

Re: [rust-dev] Integer overflow, round -2147483648

On Mon, Jun 23, 2014 at 4:49 PM, Daniel Micay wrote: > I don't understand what the problem would be with my proposal to have > either `checked { }` or checked operators + a lint for unchecked usage. I don't see 'checked { }' anywhere in the discussion before this message... sounds like it should

Re: [rust-dev] Integer overflow, round -2147483648

On 6/23/14 2:04 PM, comex wrote: On Mon, Jun 23, 2014 at 4:49 PM, Daniel Micay wrote: I don't understand what the problem would be with my proposal to have either `checked { }` or checked operators + a lint for unchecked usage. I don't see 'checked { }' anywhere in the discussion before this

Re: [rust-dev] Integer overflow, round -2147483648

On Mon, Jun 23, 2014 at 1:32 PM, Daniel Micay wrote: > It would be an enormous mistake to ship a language with region typing / > move semantics and worse before than Java. You keep saying that, but if the argument is to use Swift's approach, i.e.: Non-overflow operators: + - * / % Overflow op

Re: [rust-dev] Integer overflow, round -2147483648

On Mon, Jun 23, 2014 at 1:49 PM, Daniel Micay wrote: > I already mentioned the issue of undefined overflow, and how using > inbounds pointer arithmetic is both higher-level (iterators) and just as > fast. It doesn't cover every case, but it covers enough of them that the > use case for undefined s

Re: [rust-dev] Integer overflow, round -2147483648

O Mon, Jun 23, 2014 at 2:08 PM, Tony Arcieri wrote: > Want to perform well at TIOBE or other (micro)benchmarks? Use the overflow > operators! > I meant http://shootout.alioth.debian.org here, but yeah, I hope you get the idea ;) -- Tony Arcieri ___ R

Re: [rust-dev] Integer overflow, round -2147483648

On 23/06/14 04:58 PM, Patrick Walton wrote: > On 6/23/14 1:55 PM, Daniel Micay wrote: >> It's not much a systems language if it's slower than an inner loop in a >> JavaScript program without going out of your way to avoid the overhead. > > I agree with your general concerns, but I should nitpick t

Re: [rust-dev] Integer overflow, round -2147483648

On 23/06/14 05:11 PM, Gregory Maxwell wrote: > > Calling things 'slower than java' is a little bit hyperbole with the > actual numbers posted here. But I agree any non-trivial slowdown by > default would adversely impact adoption, I don't consider that > desirable. It's really not hyperbole. Java

Re: [rust-dev] Integer overflow, round -2147483648

> I feel like Rust might be missing out on the free lunch I expect Swift to provide I think that it may be unfounded to expect Swift to spur drastic improvements to any aspect of LLVM. Apple is already the biggest benefactor of LLVM, which powers the C compiler their OS is built with, the Objectiv

Re: [rust-dev] Integer overflow, round -2147483648

On 23/06/14 05:08 PM, Tony Arcieri wrote: > On Mon, Jun 23, 2014 at 1:32 PM, Daniel Micay > wrote: > > It would be an enormous mistake to ship a language with region typing / > move semantics and worse before than Java. > > > You keep saying that, but if th

Re: [rust-dev] Integer overflow, round -2147483648

On 23/06/14 05:38 PM, Benjamin Striegel wrote: >> I feel like Rust might be missing out on the free lunch I expect Swift > to provide > > I think that it may be unfounded to expect Swift to spur drastic > improvements to any aspect of LLVM. Apple is already the biggest > benefactor of LLVM, which

Re: [rust-dev] Integer overflow, round -2147483648

On Mon, Jun 23, 2014 at 2:44 PM, Daniel Micay wrote: > Rust is a performance-centric systems language, Swift is not. > You say that, but I don't see how it applies to my argument. 2 of the 3 options I proposed are purely additive changes to Rust that would not affect at all how it works today, b

Re: [rust-dev] Integer overflow, round -2147483648

On 23/06/14 05:57 PM, Tony Arcieri wrote: > On Mon, Jun 23, 2014 at 2:44 PM, Daniel Micay > wrote: > > Rust is a performance-centric systems language, Swift is not. > > > You say that, but I don't see how it applies to my argument. 2 of the 3 > options I propos

Re: [rust-dev] Integer overflow, round -2147483648

On Mon, Jun 23, 2014 at 3:07 PM, Daniel Micay wrote: > The language shouldn't be designed around the hypothetical good will of > a corporation. Anyway, I don't know why Swift would have the high-level > SIL IR layer if that's not where they plan on doing these optimizations. > To flip the questi

Re: [rust-dev] Integer overflow, round -2147483648

On Mon, Jun 23, 2014 at 3:08 PM, Tony Arcieri wrote: > To flip the question around: what's wrong with Swift's approach? > Or perhaps to ask a less pointed question, what's wrong with Swift's approach besides making the slow operators the default? -- Tony Arcieri ___

Re: [rust-dev] Integer overflow, round -2147483648

On Mon, Jun 23, 2014 at 5:38 PM, Benjamin Striegel wrote: > I'd like to also note that Apple has no external incentive to improve Swift. > Objective-C was a dead language before Apple's fiat rocketed it into the > position of world's third-most-popular programming language. Regardless of > Swift's

Re: [rust-dev] Integer overflow, round -2147483648

On 23/06/14 06:08 PM, Tony Arcieri wrote: > On Mon, Jun 23, 2014 at 3:07 PM, Daniel Micay > wrote: > > The language shouldn't be designed around the hypothetical good will of > a corporation. Anyway, I don't know why Swift would have the high-level > SIL

Re: [rust-dev] Integer overflow, round -2147483648

On 23/06/14 06:34 PM, comex wrote: > On Mon, Jun 23, 2014 at 5:38 PM, Benjamin Striegel > wrote: >> I'd like to also note that Apple has no external incentive to improve Swift. >> Objective-C was a dead language before Apple's fiat rocketed it into the >> position of world's third-most-popular pro

Re: [rust-dev] Integer overflow, round -2147483648

I do think Rust should exposed either `checked { }` or operators for checked arithmetic along with an opt-in lint to deny the unchecked operators. You can opt-out of a lint for a function/impl/module after opting into it at a higher scope. I'm just making it clear that doing this by default would

Re: [rust-dev] Integer overflow, round -2147483648

On 23/06/14 08:16 PM, John Regehr wrote: >> I do think Rust should exposed either `checked { }` or operators for >> checked arithmetic along with an opt-in lint to deny the unchecked >> operators. You can opt-out of a lint for a function/impl/module after >> opting into it at a higher scope. >> >>

Re: [rust-dev] Integer overflow, round -2147483648

> the fact is that everyone is an optimist when it comes to integer overflow bugs. People just do not think they're going to get bitten. I agree, and I don't think anyone else here is going to try to argue that this doesn't cause real bugs. As so often seems to be the case, language design amount

Re: [rust-dev] Integer overflow, round -2147483648

In short: - everybody wants checked integer arithmetic because it helps to write better code (thanks to compile time and runtime errors) - nobody wants to pay the price in performances, but maybe in the future, hardware++ will make it easier... or so on... What about: - Defining "safe" integer

Re: [rust-dev] Integer overflow, round -2147483648

On 23/06/14 11:58 PM, François-Xavier Bourlet wrote: > In short: > - everybody wants checked integer arithmetic because it helps to > write better code (thanks to compile time and runtime errors) > - nobody wants to pay the price in performances, but maybe in the > future, hardware++ will make it

Re: [rust-dev] Integer overflow, round -2147483648

On Mon, Jun 23, 2014 at 1:49 PM, Daniel Micay wrote: > On 23/06/14 04:00 PM, Gregory Maxwell wrote: > > On Mon, Jun 23, 2014 at 12:50 PM, Daniel Micay > wrote: > >> The discussion here is about checking for both signed / unsigned integer > >> overflow, as in passing both `-fsanitize=signed-integ

Re: [rust-dev] Integer overflow, round -2147483648

On Tue, Jun 24, 2014 at 1:17 AM, Jerry Morrison wrote: > Does `checked { }` mean all functions within that scope use checked-integer > arithmetic? This sounds great to me. Bikeshed: If this happens there should also be a module-level attribute alternative to avoid unnecessary indentation. ___

Re: [rust-dev] Integer overflow, round -2147483648

On 24/06/14 01:17 AM, Jerry Morrison wrote: > > Does `checked { }` mean all functions within that scope use > checked-integer arithmetic? This sounds great to me. It would only apply to local operations. It's not possible to alter the behaviour of functions in general because of crates. It would

Re: [rust-dev] Integer overflow, round -2147483648

On 24/06/14 01:22 AM, comex wrote: > On Tue, Jun 24, 2014 at 1:17 AM, Jerry Morrison wrote: >> Does `checked { }` mean all functions within that scope use checked-integer >> arithmetic? This sounds great to me. > > Bikeshed: If this happens there should also be a module-level > attribute alternat

Re: [rust-dev] Integer overflow, round -2147483648

On 24/06/14 01:34 AM, Daniel Micay wrote: > On 24/06/14 01:22 AM, comex wrote: >> On Tue, Jun 24, 2014 at 1:17 AM, Jerry Morrison wrote: >>> Does `checked { }` mean all functions within that scope use checked-integer >>> arithmetic? This sounds great to me. >> >> Bikeshed: If this happens there sh

[rust-dev] Text Mode File Reading/Writing

Hello, I'm looking through the File API at http://doc.rust-lang.org/std/io/ and I don't see a way to open a file in binary-mode vs text-mode. It seems the default is binary mode from tests that I've done. AFAIK, this only matters on Windows since a carriage return would not be returned to the prog

[rust-dev] [ANN] Initial Alpha of Cargo

Folks, I'm happy to announce that Cargo is now ready to try out! The Cargo repository is now at https://github.com/rust-lang/cargo and you can learn all about it at http://crates.io/. Don't forget to check out the FAQ at http://crates.io/faq. You can build Cargo from master using the latest `rus

Re: [rust-dev] [ANN] Initial Alpha of Cargo

There is an Ubuntu PPA available at https://launchpad.net/~cmrx64/+archive/cargo, for use on travis or otherwise. On Mon, Jun 23, 2014 at 10:50 PM, Yehuda Katz wrote: > Folks, > > I'm happy to announce that Cargo is now ready to try out! > > The Cargo repository is now at https://github.com/rust-

Re: [rust-dev] Integer overflow, round -2147483648

On Mon, Jun 23, 2014 at 10:32 PM, Daniel Micay wrote: > On 24/06/14 01:17 AM, Jerry Morrison wrote: > > > > Does `checked { }` mean all functions within that scope use > > checked-integer arithmetic? This sounds great to me. > > It would only apply to local operations. It's not possible to alter

Re: [rust-dev] Integer overflow, round -2147483648

On 24/06/14 01:55 AM, Jerry Morrison wrote: > > > On Mon, Jun 23, 2014 at 10:32 PM, Daniel Micay > wrote: > > On 24/06/14 01:17 AM, Jerry Morrison wrote: > > > > Does `checked { }` mean all functions within that scope use > > checked-integer arithme