Re: [plt-dev] performance-oriented unsafe operations (v4.2.1.8)
At Sun, 6 Sep 2009 18:59:01 -0600, Doug Williams wrote: Would it be better to call the operations 'unchecked-whatever' instead of 'unsafe-whatever'? Generally, we are calling the function because we know it is safe to avoid some constraint check - not because it is unsafe. Just a nit. Despite the distinction between unsafety for performance and unsafety to get at new things, I like having all unsafe operations marked the same way. Also, unchecked doesn't sound dangerous enough to me. So, you make a good point, but I'm still in favor of unsafe. _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] performance-oriented unsafe operations (v4.2.1.8)
And, given your post on the JIT optimizations for unsafe operations, I can see where they are truly unsafe (in terms of possibly crashing instead of just erroring.) When I make the changes to use the unsafe-fl/unsafe-fx operations, I'll change to using unsafe- as a prefix for the science collection operations. Doug On Sat, Oct 3, 2009 at 10:33 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Sun, 6 Sep 2009 18:59:01 -0600, Doug Williams wrote: Would it be better to call the operations 'unchecked-whatever' instead of 'unsafe-whatever'? Generally, we are calling the function because we know it is safe to avoid some constraint check - not because it is unsafe. Just a nit. Despite the distinction between unsafety for performance and unsafety to get at new things, I like having all unsafe operations marked the same way. Also, unchecked doesn't sound dangerous enough to me. So, you make a good point, but I'm still in favor of unsafe. _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] performance-oriented unsafe operations (v4.2.1.8)
If the operations in the science collection have the loops inside them, then it probably wouldn't hurt to add a check at boundary and you can make them safe, even thought the depend on the unsafe operations. Robby On Sat, Oct 3, 2009 at 11:33 AM, Doug Williams m.douglas.willi...@gmail.com wrote: And, given your post on the JIT optimizations for unsafe operations, I can see where they are truly unsafe (in terms of possibly crashing instead of just erroring.) When I make the changes to use the unsafe-fl/unsafe-fx operations, I'll change to using unsafe- as a prefix for the science collection operations. Doug On Sat, Oct 3, 2009 at 10:33 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Sun, 6 Sep 2009 18:59:01 -0600, Doug Williams wrote: Would it be better to call the operations 'unchecked-whatever' instead of 'unsafe-whatever'? Generally, we are calling the function because we know it is safe to avoid some constraint check - not because it is unsafe. Just a nit. Despite the distinction between unsafety for performance and unsafety to get at new things, I like having all unsafe operations marked the same way. Also, unchecked doesn't sound dangerous enough to me. So, you make a good point, but I'm still in favor of unsafe. _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] performance-oriented unsafe operations (v4.2.1.8)
Actually, I would probably do what Matthew did and coerce to a float with exact-inexact, which would error instead of crashing. [Although a complex value, for example, would get through that and still crash.] But, the idea of having unchecked/unsafe operations is to ONLY call them when the data has already been through some contract check already. On Sat, Oct 3, 2009 at 12:40 PM, Robby Findler ro...@eecs.northwestern.eduwrote: If the operations in the science collection have the loops inside them, then it probably wouldn't hurt to add a check at boundary and you can make them safe, even thought the depend on the unsafe operations. Robby On Sat, Oct 3, 2009 at 11:33 AM, Doug Williams m.douglas.willi...@gmail.com wrote: And, given your post on the JIT optimizations for unsafe operations, I can see where they are truly unsafe (in terms of possibly crashing instead of just erroring.) When I make the changes to use the unsafe-fl/unsafe-fx operations, I'll change to using unsafe- as a prefix for the science collection operations. Doug On Sat, Oct 3, 2009 at 10:33 AM, Matthew Flatt mfl...@cs.utah.edu wrote: At Sun, 6 Sep 2009 18:59:01 -0600, Doug Williams wrote: Would it be better to call the operations 'unchecked-whatever' instead of 'unsafe-whatever'? Generally, we are calling the function because we know it is safe to avoid some constraint check - not because it is unsafe. Just a nit. Despite the distinction between unsafety for performance and unsafety to get at new things, I like having all unsafe operations marked the same way. Also, unchecked doesn't sound dangerous enough to me. So, you make a good point, but I'm still in favor of unsafe. _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] performance-oriented unsafe operations (v4.2.1.8)
On Mon, Sep 7, 2009 at 1:59 AM, Doug Williamsm.douglas.willi...@gmail.com wrote: One other thing that is really just semantics. Actually, that's just syntax. ;) On this list, semantics is the important stuff. Would it be better to call the operations 'unchecked-whatever' instead of 'unsafe-whatever'? Generally, we are calling the function because we know it is safe to avoid some constraint check - not because it is unsafe. Just a nit. --Carl _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] performance-oriented unsafe operations (v4.2.1.8)
Maybe it's better to keep the very same name as the safe operation, and let whoever imports it choose a different prefix. The immediate benefit is that switching from safe to unsafe becomes trivial, which is great for developing and testing in safe mode but delivering and running in unsafe mode. What will be interesting is to see if TypedScheme modules allow to squeeze extra performance by expanding to unsafe operations. [ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ] If it's not worth doing right, it's not worth doing. -- Scott McKay 2009/9/7 Carl Eastlund carl.eastl...@gmail.com: On Mon, Sep 7, 2009 at 1:59 AM, Doug Williamsm.douglas.willi...@gmail.com wrote: One other thing that is really just semantics. Actually, that's just syntax. ;) On this list, semantics is the important stuff. Would it be better to call the operations 'unchecked-whatever' instead of 'unsafe-whatever'? Generally, we are calling the function because we know it is safe to avoid some constraint check - not because it is unsafe. Just a nit. --Carl _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] performance-oriented unsafe operations (v4.2.1.8)
In this case, I prefer having a nice, ugly name with something like unsafe or unchecked in it. And, I want it at the point the unsafe/unchecked operation is being done. For production code, it's important for whoever wants to understand (i.e., maintain) it later to know the intent and its implications. Changing between them (generally) should not be a trivial decision. Doug On Mon, Sep 7, 2009 at 12:11 PM, Faré fah...@gmail.com wrote: Maybe it's better to keep the very same name as the safe operation, and let whoever imports it choose a different prefix. The immediate benefit is that switching from safe to unsafe becomes trivial, which is great for developing and testing in safe mode but delivering and running in unsafe mode. What will be interesting is to see if TypedScheme modules allow to squeeze extra performance by expanding to unsafe operations. [ François-René ÐVB Rideau | ReflectionCybernethics | http://fare.tunes.org ] If it's not worth doing right, it's not worth doing. -- Scott McKay 2009/9/7 Carl Eastlund carl.eastl...@gmail.com: On Mon, Sep 7, 2009 at 1:59 AM, Doug Williamsm.douglas.willi...@gmail.com wrote: One other thing that is really just semantics. Actually, that's just syntax. ;) On this list, semantics is the important stuff. Would it be better to call the operations 'unchecked-whatever' instead of 'unsafe-whatever'? Generally, we are calling the function because we know it is safe to avoid some constraint check - not because it is unsafe. Just a nit. --Carl _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] performance-oriented unsafe operations (v4.2.1.8)
Matthew Flatt wrote: Version 4.2.1.8 (now in SVN) starts an experiment with performance-oriented unsafe operations. The new `scheme/unsafe/ops' library provides operations such as `unsafe-vector-ref' and `unsafe-fl+' (for inexact real addition) that are inlined by the JIT without contract checks. If a call violates the contract of a function from `scheme/unsafe/ops', arbitrarily bad things can happen. As long as contracts are satisfied, however, performance should be a little better than with corresponding safe operations. As part of the experiment, the expansion of `for' with `in-range' and `in-vector' now uses unsafe operations (in a safe way). For example, `in-vector' uses `unsafe-vector-ref' as well as a fixnum comparison for detecting when it has reached the end of a vector; it also uses unsafe fixnum arithmetic to increment the index as long as the step is 1 or -1 (in which case no overflow can occur during the increment). These improvements make a 10-20% difference in a tight loop over a vector. I get about a 25% speedup. dual-core amd64 running with a 32-bit ubuntu. pre-unsafe cpu time: 1040 real time: 1046 gc time: 72 cpu time: 1064 real time: 1089 gc time: 132 cpu time: 1000 real time: 1005 gc time: 8 cpu time: 940 real time: 954 gc time: 12 cpu time: 940 real time: 947 gc time: 0 unsafe: cpu time: 748 real time: 749 gc time: 20 cpu time: 732 real time: 738 gc time: 4 cpu time: 776 real time: 782 gc time: 44 cpu time: 736 real time: 749 gc time: 12 cpu time: 744 real time: 743 gc time: 8 code: (for/fold ([sum 0]) ([i (in-range 400)]) (+ sum i)) _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] performance-oriented unsafe operations (v4.2.1.8)
Matthew, These look like good things for me to use for efficiency in the science collection. Will these these be in the upcoming 4.2.2 release? I assume that if I use these and introduce a dependency on 4.2.2 or later that I should also bump the version number of the science collection in PLaneT - even if the interface remains the same. Does that make sense? I guess the term 'experiment' here confuses me. Is this something that might go away again? Should I wait until everyone is comfortable with the results? Doug On Sun, Sep 6, 2009 at 12:27 PM, Matthew Flatt mfl...@cs.utah.edu wrote: Version 4.2.1.8 (now in SVN) starts an experiment with performance-oriented unsafe operations. The new `scheme/unsafe/ops' library provides operations such as `unsafe-vector-ref' and `unsafe-fl+' (for inexact real addition) that are inlined by the JIT without contract checks. If a call violates the contract of a function from `scheme/unsafe/ops', arbitrarily bad things can happen. As long as contracts are satisfied, however, performance should be a little better than with corresponding safe operations. As part of the experiment, the expansion of `for' with `in-range' and `in-vector' now uses unsafe operations (in a safe way). For example, `in-vector' uses `unsafe-vector-ref' as well as a fixnum comparison for detecting when it has reached the end of a vector; it also uses unsafe fixnum arithmetic to increment the index as long as the step is 1 or -1 (in which case no overflow can occur during the increment). These improvements make a 10-20% difference in a tight loop over a vector. Future possible directions include making the JIT specialize combinations of inexact operations to avoid boxing intermediate results. The exports of `scheme/unsafe/ops' are protected, so that a code inspector can prevent access to unsafe operations by untrusted code. _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] performance-oriented unsafe operations (v4.2.1.8)
On Sun, Sep 6, 2009 at 6:14 PM, Matthew Flattmfl...@cs.utah.edu wrote: At Sun, 6 Sep 2009 14:22:34 -0600, Doug Williams wrote: I assume that if I use these and introduce a dependency on 4.2.2 or later that I should also bump the version number of the science collection in PLaneT - even if the interface remains the same. Does that make sense? No, I think you wouldn't change the major version, since there's no API change. You would, however, add a constraint that the latest version of the science collection depends on 4.2.2 and so people using 4.2.1 (and lower) wouldn't see that new version. Robby _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
Re: [plt-dev] performance-oriented unsafe operations (v4.2.1.8)
I will do that. One other thing that is really just semantics. Would it be better to call the operations 'unchecked-whatever' instead of 'unsafe-whatever'? Generally, we are calling the function because we know it is safe to avoid some constraint check - not because it is unsafe. Just a nit. Doug On Sun, Sep 6, 2009 at 6:10 PM, Robby Findler ro...@eecs.northwestern.eduwrote: On Sun, Sep 6, 2009 at 6:14 PM, Matthew Flattmfl...@cs.utah.edu wrote: At Sun, 6 Sep 2009 14:22:34 -0600, Doug Williams wrote: I assume that if I use these and introduce a dependency on 4.2.2 or later that I should also bump the version number of the science collection in PLaneT - even if the interface remains the same. Does that make sense? No, I think you wouldn't change the major version, since there's no API change. You would, however, add a constraint that the latest version of the science collection depends on 4.2.2 and so people using 4.2.1 (and lower) wouldn't see that new version. Robby _ For list-related administrative tasks: http://list.cs.brown.edu/mailman/listinfo/plt-dev
