[XInt] CoW/Move Timings
Below are the comparative timings with and without Copy-on-Write, and with and without Boost.Move. Times are measured in seconds, using two sets of ten integers (512, 2048, and 8192 bit). The tests consisted of adding each of those pairs of numbers together 10,000 times, multiplying them 10,000 times, and doing a "mulmod" operation on them (with a third randomly-generated modulus argument of the same size) 1,000 times. Each test was run three times, under as close to identical situations as I could manage, with the raw results in the first three columns; the fourth column is the average of the three. The compiler used was GCC 4.5.1, under Ubuntu Linux 10.10. The build was non-debug and used -O2 optimization. Otherwise, the settings were left at their defaults. The "review code" lines are for the unmodified review version of the code. All others are for the pass-by-reference version, with several other modifications that should have no measurable effect on the speed. The tests show pretty conclusively that Copy-on-Write, alone or in conjunction with Boost.Move, provides a noticeable speed improvement on all three sizes. They also prove that Boost.Move can work well in conjunction with it. I'll leave any further analysis to people who are probably more qualified than I. Note that the Boost.Move numbers could be a little better. The integer_t classes are move-enabled, but the internal data class is not as yet. The data class only sometimes uses return values, so the difference isn't likely to be great. I will make the updated code available on request for anyone who wants to examine the changes. 512bit CoW, no Move: 0.48, 0.47, 0.47: 0.48 No CoW, no Move: 0.61, 0.61, 0.62: 0.61 (worst) No CoW, Move: 0.57, 0.57, 0.55: 0.56 CoW, Move: 0.44, 0.44, 0.44: 0.44 (best) Review code, CoW, no Move: 0.50, 0.47, 0.47: 0.48 2Kbit CoW, no Move: 4.69, 4.79, 4.89: 4.79 (best) No CoW, no Move: 5.01, 5.19, 5.06: 5.09 (worst) No CoW, Move: 5.18, 5.00, 5.01: 5.06 CoW, Move: 4.80, 4.79, 4.86: 4.82 Review code, CoW, no Move: 4.88, 4.85, 4.94: 4.89 8Kbit CoW, no Move: 68.0, 68.8, 68.9: 68.6 No CoW, no Move: 70.4, 70.4, 70.2: 70.3 (worst) No CoW, Move: 70.9, 69.8, 69.6: 70.1 CoW, Move: 68.4, 68.2, 67.8: 68.1 (best) Review code, CoW, no Move: 68.8, 68.4, 68.8: 68.7 -- Chad Nelson Oak Circle Software, Inc. * * *
AMDG On 03/09/2011 05:23 PM, Chad Nelson wrote:
The "review code" lines are for the unmodified review version of the code. All others are for the pass-by-reference version, with several other modifications that should have no measurable effect on the speed.
Is this version of the code available somewhere? In Christ, Steven Watanabe
On Wed, 09 Mar 2011 17:36:40 -0800 Steven Watanabe <watanabesj@gmail.com> wrote:
The "review code" lines are for the unmodified review version of the code. All others are for the pass-by-reference version, with several other modifications that should have no measurable effect on the speed.
Is this version of the code available somewhere?
<http://www.oakcircle.com/download/xint-postreview1.zip> -- Chad Nelson Oak Circle Software, Inc. * * *
On 3/9/2011 9:35 PM, Chad Nelson wrote:
On Wed, 09 Mar 2011 17:36:40 -0800 Steven Watanabe<watanabesj@gmail.com> wrote:
The "review code" lines are for the unmodified review version of the code. All others are for the pass-by-reference version, with several other modifications that should have no measurable effect on the speed.
Is this version of the code available somewhere?
It doesn't look like any of the cpp files in libs/xint/test correspond to the benchmark you posted most recently. Am I blind, or should I be looking elsewhere? I'm stepping through an execution of test_main.cpp with "#define PERFORMANCE_TEST" uncommented in the MSVC9 debugger and with an added "#define BOOST_XINT_USE_MOVE" (why isn't this defined by default???). First thing I notice is that, indeed, CoW is used internally in the raw_integer_t -> magnitude_manager_t, unless one undefs BOOST_XINT_USE_COW (in which case, there are still reference counts floating around, sadly; but it looks like every attachment is immediately followed by a deep copy). However, it seems some operations still assume CoW behavior of raw_integer_t. For example, the operator+ for BOOST_XINT_RAWINT is defined as BOOST_XINT_RAWINT_TPL BOOST_XINT_RAWINT operator+(BOOST_XINT_RAWINT n1, const BOOST_XINT_RAWINT &n2) { n1 += n2; return n1; } which, when CoW is disabled (by this, I mean BOOST_XINT_USE_COW is *not* defined), could trigger an additional unnecessary allocation, due to the sum n1 + n2 having a longer length than n1's capacity. Did you undef BOOST_XINT_USE_COW in your benchmarking of sans-CoW? Even with CoW, there are some tweaks to your general approach that I think can speed things up a bit. Sticking to the execution I'm following in operator+ above, n1 and n2 each had length 64, so n1 is first resized to 65 (triggering an allocation), n1's data is copied into the new storage, and n2's data is then added to n1's data. Thus, we're making an extra unnecessary pass over n1's data. Probably better to take both parameters by reference-to-const, allocate an uninitialized block of max(n1.length, n2.length) + 1, and then run over all 3 arrays once. What I'm really finding troubling, though, is the deep copy performed at line 2119 in integer.hpp when using thread-safe integer_t's: integer_t<BOOST_XINT_APARAMS> r(n1._data() + n2._data()); n1._data() + n2._data() executes the BOOST_XINT_RAWINT overload of operator+, and this object is *not* moved into r, but deep copied (!), since the temporary raw_integer_t object makes the reference count 2 once the r object attaches to it. If my analysis is wrong on this, please correct me, but I'm guessing this isn't what was intended, right? The move constructor (invoked in the following line) seems to work as expected. By the way, if you're going to implement move construction in terms of swap, I'm told you should follow the swap with a clear of the moved-from object. Since a temporary exists all the way "'til the semicolon", which could be a long time in a real execution, this ensures that unused resources are never held by a temporary longer than necessary. That one deep copy, observed in a very short period of time stepping through the code, doesn't give me a lot of confidence in your non-CoW timings, as it's probably not unlikely there are multiple instances of this same problem. I hope this convinces you of the importance of tracking the number of allocations. Further, your non-CoW timings are somewhat poisoned anyway by the persistent presence of reference counting, which is just dead weight adding to the timings. I think until we get a stripped down integer class that just consists of a std::vector magnitude and a bool sign, it will be hard to trust any comparison between CoW and non-CoW. And it will be more convenient to code this up if the arithmetic algorithms can automatically work with a std::vector of digits ;) - Jeff
On Wed, 09 Mar 2011 23:30:21 -0800 "Jeffrey Lee Hellrung, Jr." <jhellrung@ucla.edu> wrote:
On 3/9/2011 9:35 PM, Chad Nelson wrote:
On Wed, 09 Mar 2011 17:36:40 -0800 Steven Watanabe<watanabesj@gmail.com> wrote:
The "review code" lines are for the unmodified review version of the code. All others are for the pass-by-reference version, with several other modifications that should have no measurable effect on the speed.
Is this version of the code available somewhere?
It doesn't look like any of the cpp files in libs/xint/test correspond to the benchmark you posted most recently. Am I blind, or should I be looking elsewhere?
I'm not sure what you mean. I simply defined PERFORMANCE_TEST in /libs/xint/test/test_main.cpp and used the Linux "time" command to get the timings for each run.
I'm stepping through an execution of test_main.cpp with "#define PERFORMANCE_TEST" uncommented in the MSVC9 debugger and with an added "#define BOOST_XINT_USE_MOVE" (why isn't this defined by default???).
Because Boost.Move was still very much up in the air when I wrote that code.
First thing I notice is that, indeed, CoW is used internally in the raw_integer_t -> magnitude_manager_t, unless one undefs BOOST_XINT_USE_COW
As I explained earlier.
(in which case, there are still reference counts floating around, sadly; but it looks like every attachment is immediately followed by a deep copy).
That was the only way I could see to provably disable it for timing purposes, without rewriting large portions of the code.
However, it seems some operations still assume CoW behavior of raw_integer_t.
As I pointed out in my original timings message: "Note that the Boost.Move numbers could be a little better. The integer_t classes are move-enabled, but the internal data class is not as yet. The data class only sometimes uses return values, so the difference isn't likely to be great."
Did you undef BOOST_XINT_USE_COW in your benchmarking of sans-CoW?
Yes. That was the point of putting BOOST_XINT_USE_COW in there. It wasn't there in the review version of the code.
Even with CoW, there are some tweaks to your general approach that I think can speed things up a bit. Sticking to the execution I'm following in operator+ above, n1 and n2 each had length 64, so n1 is first resized to 65 (triggering an allocation), n1's data is copied into the new storage, and n2's data is then added to n1's data. Thus, we're making an extra unnecessary pass over n1's data. Probably better to take both parameters by reference-to-const, allocate an uninitialized block of max(n1.length, n2.length) + 1, and then run over all 3 arrays once.
Good catch.
What I'm really finding troubling, though, is the deep copy performed at line 2119 in integer.hpp when using thread-safe integer_t's:
integer_t<BOOST_XINT_APARAMS> r(n1._data() + n2._data());
n1._data() + n2._data() executes the BOOST_XINT_RAWINT overload of operator+, and this object is *not* moved into r, but deep copied (!), since the temporary raw_integer_t object makes the reference count 2 once the r object attaches to it. If my analysis is wrong on this, please correct me, but I'm guessing this isn't what was intended, right?
That's not what was intended for the original code. The deep-copy-everything behavior is, as mentioned above, a hack that I added in the last few days to provably and completely disable copy-on-write.
The move constructor (invoked in the following line) seems to work as expected. By the way, if you're going to implement move construction in terms of swap, I'm told you should follow the swap with a clear of the moved-from object. Since a temporary exists all the way "'til the semicolon", which could be a long time in a real execution, this ensures that unused resources are never held by a temporary longer than necessary.
Noted.
That one deep copy, observed in a very short period of time stepping through the code, doesn't give me a lot of confidence in your non-CoW timings, as it's probably not unlikely there are multiple instances of this same problem. I hope this convinces you of the importance of tracking the number of allocations.
Further, your non-CoW timings are somewhat poisoned anyway by the persistent presence of reference counting, which is just dead weight adding to the timings. I think until we get a stripped down integer class that just consists of a std::vector magnitude and a bool sign, it will be hard to trust any comparison between CoW and non-CoW. And it will be more convenient to code this up if the arithmetic algorithms can automatically work with a std::vector of digits ;)
Then there's no way to prove whether CoW is useful or not until I rewrite the entire code to remove it anyway. -- Chad Nelson Oak Circle Software, Inc. * * *
On 3/10/2011 6:48 AM, Chad Nelson wrote:
On Wed, 09 Mar 2011 23:30:21 -0800 "Jeffrey Lee Hellrung, Jr."<jhellrung@ucla.edu> wrote:
On 3/9/2011 9:35 PM, Chad Nelson wrote:
On Wed, 09 Mar 2011 17:36:40 -0800 Steven Watanabe<watanabesj@gmail.com> wrote:
The "review code" lines are for the unmodified review version of the code. All others are for the pass-by-reference version, with several other modifications that should have no measurable effect on the speed.
Is this version of the code available somewhere?
It doesn't look like any of the cpp files in libs/xint/test correspond to the benchmark you posted most recently. Am I blind, or should I be looking elsewhere?
I'm not sure what you mean. I simply defined PERFORMANCE_TEST in /libs/xint/test/test_main.cpp and used the Linux "time" command to get the timings for each run.
Okay; I expected the timing to be encapsulated in the test, and more details somewhere on how to test each combination of parameters (CoW/non-CoW; move/non-move; and integer sizes). As it is, I think I figured it out. [...]
(in which case, there are still reference counts floating around, sadly; but it looks like every attachment is immediately followed by a deep copy).
That was the only way I could see to provably disable it for timing purposes, without rewriting large portions of the code.
With the current framework, you're probably right. But then I think any performance measurements you post to this list should be appropriately framed in that context. Your statement "The tests show pretty conclusively that Copy-on-Write, alone or in conjunction with Boost.Move, provides a noticeable speed improvement on all three sizes." is simply disingenuous. Not just for the above reason, but for the unnecessary deep-copy behavior I mention below.
However, it seems some operations still assume CoW behavior of raw_integer_t.
As I pointed out in my original timings message: "Note that the Boost.Move numbers could be a little better. The integer_t classes are move-enabled, but the internal data class is not as yet. The data class only sometimes uses return values, so the difference isn't likely to be great."
This doesn't preclude you from avoiding unnecessary copying...even with CoW, creating a reference-to-const is cheaper than creating a copy.
Did you undef BOOST_XINT_USE_COW in your benchmarking of sans-CoW?
Yes. That was the point of putting BOOST_XINT_USE_COW in there. It wasn't there in the review version of the code.
Okay, just trying to see which preprocessor definitions are relevant here. [...]
What I'm really finding troubling, though, is the deep copy performed at line 2119 in integer.hpp when using thread-safe integer_t's:
integer_t<BOOST_XINT_APARAMS> r(n1._data() + n2._data());
n1._data() + n2._data() executes the BOOST_XINT_RAWINT overload of operator+, and this object is *not* moved into r, but deep copied (!), since the temporary raw_integer_t object makes the reference count 2 once the r object attaches to it. If my analysis is wrong on this, please correct me, but I'm guessing this isn't what was intended, right?
That's not what was intended for the original code. The deep-copy-everything behavior is, as mentioned above, a hack that I added in the last few days to provably and completely disable copy-on-write.
Correct me if I'm wrong, but this is the behavior of the thread-safe version of integer_t regardless of BOOST_XINT_USE_COW. So am I to infer from your comment that this line did *not* deep copy in the review version of the library? [...]
That one deep copy, observed in a very short period of time stepping through the code, doesn't give me a lot of confidence in your non-CoW timings, as it's probably not unlikely there are multiple instances of this same problem. I hope this convinces you of the importance of tracking the number of allocations.
Further, your non-CoW timings are somewhat poisoned anyway by the persistent presence of reference counting, which is just dead weight adding to the timings. I think until we get a stripped down integer class that just consists of a std::vector magnitude and a bool sign, it will be hard to trust any comparison between CoW and non-CoW. And it will be more convenient to code this up if the arithmetic algorithms can automatically work with a std::vector of digits ;)
Then there's no way to prove whether CoW is useful or not until I rewrite the entire code to remove it anyway.
Well...yes, that's likely the case. I believe that adding CoW would give zero improvement, and add at least negligible overhead, over simply using move emulation for this particular test case, where the only relevant operations are "T r = x + y", "T r = x * y", and "T r = mulmod(x, y)" (assuming that CoW idioms are avoided in the respective implementations). If you really wanted to keep CoW around in the core implementation, you would be well served to come up with a test case where you *expect* CoW to perform better (of course, something other than creating spurious copies just for the hell of it). - Jeff
On Thu, 10 Mar 2011 07:37:40 -0800 "Jeffrey Lee Hellrung, Jr." <jhellrung@ucla.edu> wrote:
What I'm really finding troubling, though, is the deep copy performed at line 2119 in integer.hpp when using thread-safe integer_t's: [...]
That's not what was intended for the original code. The deep-copy-everything behavior is, as mentioned above, a hack that I added in the last few days to provably and completely disable copy-on-write.
Correct me if I'm wrong, but this is the behavior of the thread-safe version of integer_t regardless of BOOST_XINT_USE_COW. So am I to infer from your comment that this line did *not* deep copy in the review version of the library?
It's not meant to. Whether it did or not, I can't say without closely examining the code. -- Chad Nelson Oak Circle Software, Inc. * * *
On 3/9/2011 5:23 PM, Chad Nelson wrote:
Below are the comparative timings with and without Copy-on-Write, and with and without Boost.Move.
Times are measured in seconds, using two sets of ten integers (512, 2048, and 8192 bit). The tests consisted of adding each of those pairs of numbers together 10,000 times, multiplying them 10,000 times, and doing a "mulmod" operation on them (with a third randomly-generated modulus argument of the same size) 1,000 times. Each test was run three times, under as close to identical situations as I could manage, with the raw results in the first three columns; the fourth column is the average of the three.
The compiler used was GCC 4.5.1, under Ubuntu Linux 10.10. The build was non-debug and used -O2 optimization. Otherwise, the settings were left at their defaults.
The "review code" lines are for the unmodified review version of the code. All others are for the pass-by-reference version, with several other modifications that should have no measurable effect on the speed.
The tests show pretty conclusively that Copy-on-Write, alone or in conjunction with Boost.Move, provides a noticeable speed improvement on all three sizes. They also prove that Boost.Move can work well in conjunction with it. I'll leave any further analysis to people who are probably more qualified than I.
Note that the Boost.Move numbers could be a little better. The integer_t classes are move-enabled, but the internal data class is not as yet. The data class only sometimes uses return values, so the difference isn't likely to be great.
I will make the updated code available on request for anyone who wants to examine the changes.
512bit CoW, no Move: 0.48, 0.47, 0.47: 0.48 No CoW, no Move: 0.61, 0.61, 0.62: 0.61 (worst) No CoW, Move: 0.57, 0.57, 0.55: 0.56 CoW, Move: 0.44, 0.44, 0.44: 0.44 (best)
Review code, CoW, no Move: 0.50, 0.47, 0.47: 0.48
2Kbit CoW, no Move: 4.69, 4.79, 4.89: 4.79 (best) No CoW, no Move: 5.01, 5.19, 5.06: 5.09 (worst) No CoW, Move: 5.18, 5.00, 5.01: 5.06 CoW, Move: 4.80, 4.79, 4.86: 4.82
Review code, CoW, no Move: 4.88, 4.85, 4.94: 4.89
8Kbit CoW, no Move: 68.0, 68.8, 68.9: 68.6 No CoW, no Move: 70.4, 70.4, 70.2: 70.3 (worst) No CoW, Move: 70.9, 69.8, 69.6: 70.1 CoW, Move: 68.4, 68.2, 67.8: 68.1 (best)
Review code, CoW, no Move: 68.8, 68.4, 68.8: 68.7
To echo Steven's request, please make your test code available. The 2Kbit section has me wondering about the accuracy of these timings, as "CoW, no Move" outperformed "CoW, Move", which should definitely not be the case. I can't think of any circumstance where move emulation gives you a penalty... I think an equally important measure would be the # of allocation requests. Do you track those? - Jeff
On Wed, 09 Mar 2011 19:36:44 -0800 "Jeffrey Lee Hellrung, Jr." <jhellrung@ucla.edu> wrote:
[...] The 2Kbit section has me wondering about the accuracy of these timings, as "CoW, no Move" outperformed "CoW, Move", which should definitely not be the case. I can't think of any circumstance where move emulation gives you a penalty...
Those specific timings were close enough (within 0.03 seconds of each other) that they may well be within the margin of error. It's essentially impossible to do completely accurate timings on a multitasking OS.
I think an equally important measure would be the # of allocation requests. Do you track those?
Not yet. -- Chad Nelson Oak Circle Software, Inc. * * *
Chad Nelson wrote:
On Wed, 09 Mar 2011 19:36:44 -0800 "Jeffrey Lee Hellrung, Jr." <jhellrung@ucla.edu> wrote:
[...] The 2Kbit section has me wondering about the accuracy of these timings, as "CoW, no Move" outperformed "CoW, Move", which should definitely not be the case. I can't think of any circumstance where move emulation gives you a penalty...
Those specific timings were close enough (within 0.03 seconds of each other) that they may well be within the margin of error. It's essentially impossible to do completely accurate timings on a multitasking OS.
Repeat the experiment a large number of times and take the minimum runtime. That will be your runtime without interruption or with minimal interruption. Also, interleave your different tests. The first iteration of a test will generally be slower than the second because it warms to cache with code and data needed for the test. If you want warm or cold cache numbers depends on how you expect the code to be used. Usually warmed numbers are what people are interested in. Regards, Luke
On 10/03/2011 02:23, Chad Nelson wrote:
I will make the updated code available on request for anyone who wants to examine the changes.
512bit CoW, no Move: 0.48, 0.47, 0.47: 0.48 No CoW, no Move: 0.61, 0.61, 0.62: 0.61 (worst) No CoW, Move: 0.57, 0.57, 0.55: 0.56 CoW, Move: 0.44, 0.44, 0.44: 0.44 (best)
Review code, CoW, no Move: 0.50, 0.47, 0.47: 0.48
2Kbit CoW, no Move: 4.69, 4.79, 4.89: 4.79 (best) No CoW, no Move: 5.01, 5.19, 5.06: 5.09 (worst) No CoW, Move: 5.18, 5.00, 5.01: 5.06 CoW, Move: 4.80, 4.79, 4.86: 4.82
Review code, CoW, no Move: 4.88, 4.85, 4.94: 4.89
8Kbit CoW, no Move: 68.0, 68.8, 68.9: 68.6 No CoW, no Move: 70.4, 70.4, 70.2: 70.3 (worst) No CoW, Move: 70.9, 69.8, 69.6: 70.1 CoW, Move: 68.4, 68.2, 67.8: 68.1 (best)
Review code, CoW, no Move: 68.8, 68.4, 68.8: 68.7
In the move case, make your objects non-copiable to ensure you're not comparing oranges and apples. Clearly, you have copies going on somewhere. Size of the buffer should not affect *at all* the performance of move. Likewise the performance of COW should barely be affected.
On 10 Mar 2011, at 09:00, Mathias Gaunard wrote:
On 10/03/2011 02:23, Chad Nelson wrote:
I will make the updated code available on request for anyone who wants to examine the changes.
512bit CoW, no Move: 0.48, 0.47, 0.47: 0.48 No CoW, no Move: 0.61, 0.61, 0.62: 0.61 (worst) No CoW, Move: 0.57, 0.57, 0.55: 0.56 CoW, Move: 0.44, 0.44, 0.44: 0.44 (best)
Review code, CoW, no Move: 0.50, 0.47, 0.47: 0.48
2Kbit CoW, no Move: 4.69, 4.79, 4.89: 4.79 (best) No CoW, no Move: 5.01, 5.19, 5.06: 5.09 (worst) No CoW, Move: 5.18, 5.00, 5.01: 5.06 CoW, Move: 4.80, 4.79, 4.86: 4.82
Review code, CoW, no Move: 4.88, 4.85, 4.94: 4.89
8Kbit CoW, no Move: 68.0, 68.8, 68.9: 68.6 No CoW, no Move: 70.4, 70.4, 70.2: 70.3 (worst) No CoW, Move: 70.9, 69.8, 69.6: 70.1 CoW, Move: 68.4, 68.2, 67.8: 68.1 (best)
Review code, CoW, no Move: 68.8, 68.4, 68.8: 68.7
In the move case, make your objects non-copiable to ensure you're not comparing oranges and apples.
Is that fair? Sometimes, people do want to make a copy of ints. Chris
Christopher Jefferson wrote: On 10 Mar 2011, at 09:00, Mathias Gaunard wrote:
In the move case, make your objects non-copiable to ensure you're not comparing oranges and apples.
Is that fair? Sometimes, people do want to make a copy of ints.
At the very least, it would force using move semantics in all applicable cases in the library before restoring copy semantics for users. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
on 10.03.2011 at 4:23 Chad Nelson wrote :
Below are the comparative timings with and without Copy-on-Write, and with and without Boost.Move. ...
yeah, baby! move _AND_ cow rules as i said sorry, couldn't help it apart from some 3-to-20% boost (oh, sorry for a pun) cow saves some heap at least cow _DOES NOT_ make it worse good job indeed, chad! -- Pavel P.S. if you notice a grammar mistake or weird phrasing in my message please point it out
On 03/10/2011 12:33 PM, SATAN66613 wrote:
apart from some 3-to-20% boost (oh, sorry for a pun) cow saves some heap at least cow _DOES NOT_ make it worse
Was this a multithreaded test where interlocked ops on refcounts can potentially cause ping-ponging of cache lines across multiple cores? I'm not saying that this is an overriding concern, only that the "no free lunch" principle suggests that there is likely to be least some possible benchmark for which even the best optimization performs worse. - Marsh
At Thu, 10 Mar 2011 21:33:42 +0300, SATAN66613 wrote:
Pavel P.S. if you notice a grammar mistake or weird phrasing in my message please point it out
Well, since you asked, your email address is rather weirdly constructed; it's almost as though you desire to assault the sensibilities of some of your fellow Boosters. We tend to use our real names here and in any case try to promote a civil and professional respect in our interactions. If you care about how your communications here is perceived and understood, I suggest finding a handle that doesn't make such an aggressive statement. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
2011/3/12 Dave Abrahams <dave@boostpro.com>:
At Thu, 10 Mar 2011 21:33:42 +0300, SATAN66613 wrote:
Pavel P.S. if you notice a grammar mistake or weird phrasing in my message please point it out
Well, since you asked, your email address is rather weirdly constructed; it's almost as though you desire to assault the sensibilities of some of your fellow Boosters. We tend to use our real names here and in any case try to promote a civil and professional respect in our interactions. If you care about how your communications here is perceived and understood, I suggest finding a handle that doesn't make such an aggressive statement.
+1 In my experience Boosters are people who care to contribute and to develop ideas and innovations for generic library programming. They also foster a culture of honest and constructive communication. Choosing one's real name, instead of a pseudonym, seems to me as a conscious choice of most Boosters to appear as serious and accountable people in this communication. This culture of free and constructive communication includes the freedom to appear under pseudonyms, which is a choice for some. I do not understand what purpose it is going to serve or what value it is going to add to deliberately choose a bizarre psyeudonym here that has the potential to annoy people or hurt their feelings. So I'd like to second Dave's request. I found it much more courageous if you'd post under your real name instead of using a "satanic identity". If you prefer to hide your identity, please choose a more neutral pseudonym. Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de
From: Dave Abrahams SATAN66613 wrote:
Pavel P.S. if you notice a grammar mistake or weird phrasing in my message please point it out
Well, since you asked, your email address is rather weirdly constructed; it's almost as though you desire to assault the sensibilities of some of your fellow Boosters.
I really don't want to start a pointless discussion on religion here, but this seems a bit unjust to me. Satanism, after all, is just another variation on religion (and very different from what people usually "know" Satanism is). Mentioning Satan may be as assaulting to someone's sensibilities as mentioning God to someone's else, and the latter also happens from time to time on this list. So let's just be fair and consistent and equally tolerate all religious accents or tolerate none. Best regards, Robert
Robert Kawulak wrote:
From: Dave Abrahams SATAN66613 wrote:
Pavel P.S. if you notice a grammar mistake or weird phrasing in my message please point it out
Well, since you asked, your email address is rather weirdly constructed; it's almost as though you desire to assault the sensibilities of some of your fellow Boosters.
I really don't want to start a pointless discussion on religion here, but this seems a bit unjust to me. Satanism, after all, is just another variation on religion (and very different from what people usually "know" Satanism is). Mentioning Satan may be as assaulting to someone's sensibilities as mentioning God to someone's else, and the latter also happens from time to time on this list. So let's just be fair and consistent and equally tolerate all religious accents or tolerate none.
Personally, I would suggest to establish a policy that every single post to this mailing list be required to use person's "real name" in the "From" field. If we're supposed to have constructive technical discussion, it's reasonable to require that all participant be accountable for their words, which obviously requires using real names and not "handles" that can be changed every other day. As for one's religious, political, and other preferences, there's a custom that you have four lines of signature entirely at your disposal. - Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40
Vladimir Prus wrote:
Robert Kawulak wrote:
From: Dave Abrahams SATAN66613 wrote:
Pavel P.S. if you notice a grammar mistake or weird phrasing in my message please point it out
Well, since you asked, your email address is rather weirdly constructed; it's almost as though you desire to assault the sensibilities of some of your fellow Boosters.
I really don't want to start a pointless discussion on religion here, but this seems a bit unjust to me. Satanism, after all, is just another variation on religion (and very different from what people usually "know" Satanism is). Mentioning Satan may be as assaulting to someone's sensibilities as mentioning God to someone's else, and the latter also happens from time to time on this list. So let's just be fair and consistent and equally tolerate all religious accents or tolerate none.
Personally, I would suggest to establish a policy that every single post to this mailing list be required to use person's "real name" in the "From" field. If we're supposed to have constructive technical discussion, it's reasonable to require that all participant be accountable for their words, which obviously requires using real names and not "handles" that can be changed every other day.
As for one's religious, political, and other preferences, there's a custom that you have four lines of signature entirely at your disposal.
+1 Robert Ramey
- Volodya
Robert Ramey wrote:
Vladimir Prus wrote:
As for one's religious, political, and other preferences, there's a custom that you have four lines of signature entirely at your disposal.
+1
Robert Ramey
- Volodya
Thinking about this a lttle bit more. I think I'll just implement the personal policy not to read or answer read posts that have an obviously person name in the header. This will cut down on my personal workload. I would suggest that we add this suggestion to the same place where it suggests the same policy be applied to "digests" Robert Ramey
On 13 March 2011 20:05, Robert Ramey <ramey@rrsd.com> wrote:
Vladimir Prus wrote:
Personally, I would suggest to establish a policy that every single post to this mailing list be required to use person's "real name" in the "From" field. If we're supposed to have constructive technical discussion, it's reasonable to require that all participant be accountable for their words, which obviously requires using real names and not "handles" that can be changed every other day.
As for one's religious, political, and other preferences, there's a custom that you have four lines of signature entirely at your disposal.
+1
Robert Ramey
- Volodya
I find this policy not really fair. Not really fair for people (like me) who try to stay as anonymous as possible on the (wild) Internet. I know that anonymity is something that can sound weird those days with all the facebooks and the twitters out there but, well, for some people it's really important that their identity isn't leaked on the wild. I know I'm not really in position to discuss this with my really low activity on the various boost MLs, but as no one else seems to take a shot at it, I just want to remind you this point. The main argument is : real men _do_ assume their position, hence they don't need to hide behind a pseudonym. Can someone just explain me how my skills are related to my identity? Surely, I could use a fake identity, but I find it really hypocritical, and I won't do it (for various reasons, one of them being that I abhor hypocrisy). All in all, as I (now) care more about participating in boost than in my identity I will in the end use my real identity if it becomes mandatory to post here (even if it means breaking this anonymity I maintain since my first encounter with the wild wild web). Mathieu- (oh and, by the way, for what it's worth, this is my real first name.)
On 1:59 PM, Mathieu - wrote:
On 13 March 2011 20:05, Robert Ramey <ramey@rrsd.com> wrote:
Vladimir Prus wrote:
Personally, I would suggest to establish a policy that every single post to this mailing list be required to use person's "real name" in the "From" field. If we're supposed to have constructive technical discussion, it's reasonable to require that all participant be accountable for their words, which obviously requires using real names and not "handles" that can be changed every other day.
As for one's religious, political, and other preferences, there's a custom that you have four lines of signature entirely at your disposal.
I find this policy not really fair. Not really fair for people (like me) who try to stay as anonymous as possible on the (wild) Internet. I know that anonymity is something that can sound weird those days with all the facebooks and the twitters out there but, well, for some people it's really important that their identity isn't leaked on the wild.
Though I understand the tack against anonymity, even the Federalist Papers' authors (whom most Americans hold in high regard) wrote under pseudonyms. <http://www.ask.com/wiki/Federalist_Papers>
Op 15 mrt 2011, om 02:00 heeft Jim Bell het volgende geschreven:
On 1:59 PM, Mathieu - wrote:
On 13 March 2011 20:05, Robert Ramey <ramey@rrsd.com> wrote:
Vladimir Prus wrote:
Personally, I would suggest to establish a policy that every single post to this mailing list be required to use person's "real name" in the "From" field. If we're supposed to have constructive technical discussion, it's reasonable to require that all participant be accountable for their words, which obviously requires using real names and not "handles" that can be changed every other day.
I find this policy not really fair. Not really fair for people (like me) who try to stay as anonymous as possible on the (wild) Internet. I know that anonymity is something that can sound weird those days with all the facebooks and the twitters out there but, well, for some people it's really important that their identity isn't leaked on the wild.
Though I understand the tack against anonymity, even the Federalist Papers' authors (whom most Americans hold in high regard) wrote under pseudonyms. <http://www.ask.com/wiki/Federalist_Papers>
I agree that if somebody really wants to hide their identity while participating in this list, they should get the oppurtunity to do so. But perhaps we should consider that an exception, and still ask people to show their real name /unless they Really Really Need to Hide their Identity/. Not because hiding your identity is such a bad thing, but because people who use a pseudonym "just for fun" might change their handle more often, which would have a clear disadvantage for a mailing list like this. Hence I guess it's still reasonable in the exceptional case to expect the incognito participant to stick with the same handle/pseudonym? In that way, all participants can be reasonably held accountable for their words and it's also practically feasible to retrieve anybody's emails from the archive. -Julian
On Sun, 2011-03-13 at 21:01 +0300, Vladimir Prus wrote:
Robert Kawulak wrote:
From: Dave Abrahams SATAN66613 wrote:
Pavel P.S. if you notice a grammar mistake or weird phrasing in my message please point it out
Well, since you asked, your email address is rather weirdly constructed; it's almost as though you desire to assault the sensibilities of some of your fellow Boosters.
I really don't want to start a pointless discussion on religion here, but this seems a bit unjust to me. Satanism, after all, is just another variation on religion (and very different from what people usually "know" Satanism is). Mentioning Satan may be as assaulting to someone's sensibilities as mentioning God to someone's else, and the latter also happens from time to time on this list. So let's just be fair and consistent and equally tolerate all religious accents or tolerate none.
Personally, I would suggest to establish a policy that every single post to this mailing list be required to use person's "real name" in the "From" field. If we're supposed to have constructive technical discussion, it's reasonable to require that all participant be accountable for their words, which obviously requires using real names and not "handles" that can be changed every other day.
As someone who follows this list closely, I vote for people using the same name in the From header of their messages as they use for signing their messages. This makes searching for past posts much easier, especially when e-mail addresses change (because, for example, that way I can search for Pavel's messages by typing Pavel into my search box). -Hal
As for one's religious, political, and other preferences, there's a custom that you have four lines of signature entirely at your disposal.
- Volodya
2011/3/14 Hal Finkel <half@halssoftware.com>
As someone who follows this list closely, I vote for people using the same name in the From header of their messages as they use for signing their messages. This makes searching for past posts much easier, especially when e-mail addresses change (because, for example, that way I can search for Pavel's messages by typing Pavel into my search box).
-Hal
I prefere to sign 'Kris', for people who don't speak polish. Try saying 'Krzysztof' out loud or typing it from mempry ;) Regards, Kris
"Robert Kawulak" <robert.kawulak@gmail.com> wrote in message news:!&!AAAAAAAAAAAYAAAAAAAAAIOMVDziZelGq5Y6SEMPLILCgAAAEAAAADtlZSuuK/BMtVsYaIkMYa0BAAAAAA==@gmail.com...
[...] after all, is just another variation [...] [...] So let's just be fair and consistent and equally tolerate all [...] or tolerate none.
In order to facilitate peaceful, constructive and on-topic discussion in any non-political/philosophical/religious discussion group a certain 'common-law'-like ethos or a common/'axiomatic' set of 'civilized values' has to be accepted and respected by everyone. "Absolute tolerance" is just another self-contradicting post-modern idea for it would, of course, have to tolerate intolerance. In a multi-billion population you will find very many people (including university professors) that will argue for or have nothing against e.g. paedophilia, zoophilia, eugenics, euthanasia etc... And, until we "evolve" enough to accept these "behavioural patterns" as "generally acceptable", they should not be 'rubbed in' as "acceptable" in non-political/philosophical/religious discussion groups...the same goes for Satanism... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman
On Mon, Mar 14, 2011 at 5:31 PM, Domagoj Saric < domagoj.saric@littleendian.com> wrote:
"Robert Kawulak" <robert.kawulak@gmail.com> wrote in message
news:!&!AAAAAAAAAAAYAAAAAAAAAIOMVDziZelGq5Y6SEMPLILCgAAAEAAAADtlZSuuK/BMtVsYaIkMYa0BAAAAAA==@gmail.com...
[...] after all, is just another variation [...] [...] So let's just be fair and consistent and equally tolerate all [...] or tolerate none.
In order to facilitate peaceful, constructive and on-topic discussion in any non-political/philosophical/religious discussion group a certain 'common-law'-like ethos or a common/'axiomatic' set of 'civilized values' has to be accepted and respected by everyone.
"Absolute tolerance" is just another self-contradicting post-modern idea for it would, of course, have to tolerate intolerance.
In a multi-billion population you will find very many people (including university professors) that will argue for or have nothing against e.g. paedophilia, zoophilia, eugenics, euthanasia etc... And, until we "evolve" enough to accept these "behavioural patterns" as "generally acceptable", they should not be 'rubbed in' as "acceptable" in non-political/philosophical/religious discussion groups...the same goes for Satanism...
I am a little flummoxed at the amount of tension this has generated. I would really not care how your email address is spelt as long as what you write in the subject and body of your email does not offend me and does not violate the rules of the list. The email id is really your personal business, not mine, not anybody elses. I am entitled to have a personal take on it - I might think it is irreverent, ungodly, unsatanly, anti-karmic, polytheistic, weird or in completely bad taste - but I don't think I have a right to show my prejudice against you on the forum, or demand that you use an email id that doesn't offend me. If it is still a big issue, I'd expect the list admins to put in rules to check each email id and block those that are deemed offensive (and I know that sounds Draconian and pointless, not to mention un-foolproof). Cheers, Arindam
Arindam Mukherjee wrote:
I am a little flummoxed at the amount of tension this has generated. I would really not care how your email address is spelt as long as what you write in the subject and body of your email does not offend me and does not violate the rules of the list. [...]
Cory Nelson wrote:
The guy's handle had Satan in the name. That's all. Argue for people using their real names if you want, but discussion of satanism or religion of any kind was never there to begin with.
[...]
I agree with the above two reactions. In my opinion, it doesn't matter what your email address looks like as long as your real name appears in the "From:" field. Vladimir Prus and Hal Finkel pointed out good reasons why the real name should be included. If somebody in the list happens to be a satanist (or a christian, a vegetarian or a postal service employee) I don't think they have to take special effort or change their habits in order to hide that fact. Apart from that: I never expected my first post to this list would have anything to do with satanism! -Julian
Cory Nelson wrote:
The guy's handle had Satan in the name. That's all. Argue for people using their real names if you want, but discussion of satanism or religion of any kind was never there to begin with.
First I'd like to point out that Satan, as spelled using normal ASCII characters, is a regular Czech surname. Miroslav Satan plays in the NJ Devils. I believe the original poster signed off as Pavel, and you can find at least one Pavel Satan in Facebook. Just to show the name is common enough. Second, the nick was SATAN66613. The only sensible match you get with google is a song by the punk band Damnation. Lyrics and ring tones are easily available. For more information see for example http://www.metrolyrics.com/66613-lyrics-damnation.html http://www.sweetslyrics.com/bio-Damnation%20(Punk).html Once I started reading the list of like-minded bands, I kind of expected to see Spinal Tap in there. --> Mika Heiskanen
On Mon, Mar 14, 2011 at 5:53 PM, Mika Heiskanen <mika.heiskanen@fmi.fi> wrote:
First I'd like to point out that Satan, as spelled using normal ASCII characters, is a regular Czech surname. Miroslav Satan plays in the NJ Devils. I believe the original poster signed off as Pavel, and you can find at least one Pavel Satan in Facebook. Just to show the name is common enough.
Since this thread is already completely OT, I would like to point out that Miroslav Šatan is Slovak ;-) http://en.wikipedia.org/wiki/Miroslav_%C5%A0atan Matus
on Monday, March 14, 2011 at 17:14:45 Julian wrote:
Apart from that: I never expected my first post to this list would have anything to do with satanism! welcome to the boost mailing list!
on Monday, March 14, 2011 at 17:05:42 Olivier wrote:
That never seemed to be a problem in the past, so why the big fuss over an email address that he probably set-up as a teenager lacking inspiration for a good nickname ? you are sooooooo right! other cool names were occupied
on Monday, March 14, 2011 at 16:01:01 Arindam wrote:
I am a little flummoxed at the amount of tension this has generated. I would really not care how your email address is spelt as long as what you write in the subject and body of your email does not offend me and does not violate the rules of the list. The email id is really your personal business, not mine, not anybody elses. I am entitled to have a personal take on it - I might think it is irreverent, ungodly, unsatanly, anti-karmic, polytheistic, weird or in completely bad taste - but I don't think I have a right to show my prejudice against you on the forum, or demand that you use an email id that doesn't offend me.
If it is still a big issue, I'd expect the list admins to put in rules to check each email id and block those that are deemed offensive (and I know that sounds Draconian and pointless, not to mention un-foolproof). actually i expected that day would come but i didn't expect such heavy discussion on this (off)topic i conclude that this is important for the list since the thread keeps revolving eventually Dave could tell me about his thoughts on my email address off the list in order not to disturb others
anyway it's no problem for me if you care and... am i already a star of this list? -- Pavel P.S. if you notice a grammar mistake or weird phrasing in my message please point it out
pavel novikov wrote:
Julian wrote:
Apart from that: I never expected my first post to this list would have anything to do with satanism! welcome to the boost mailing list!
Thanks! I don't know whether it's customary on this list to introduce yourself, but here it goes: my main interests are in artificial intelligence and (of course) C++ programming. (And I'm a human that lives on earth.) -Julian
On Mon, Mar 14, 2011 at 5:01 AM, Domagoj Saric <domagoj.saric@littleendian.com> wrote:
"Robert Kawulak" <robert.kawulak@gmail.com> wrote in message news:!&!AAAAAAAAAAAYAAAAAAAAAIOMVDziZelGq5Y6SEMPLILCgAAAEAAAADtlZSuuK/BMtVsYaIkMYa0BAAAAAA==@gmail.com...
[...] after all, is just another variation [...] [...] So let's just be fair and consistent and equally tolerate all [...] or tolerate none.
In order to facilitate peaceful, constructive and on-topic discussion in any non-political/philosophical/religious discussion group a certain 'common-law'-like ethos or a common/'axiomatic' set of 'civilized values' has to be accepted and respected by everyone.
"Absolute tolerance" is just another self-contradicting post-modern idea for it would, of course, have to tolerate intolerance.
In a multi-billion population you will find very many people (including university professors) that will argue for or have nothing against e.g. paedophilia, zoophilia, eugenics, euthanasia etc... And, until we "evolve" enough to accept these "behavioural patterns" as "generally acceptable", they should not be 'rubbed in' as "acceptable" in non-political/philosophical/religious discussion groups...the same goes for Satanism...
The guy's handle had Satan in the name. That's all. Argue for people using their real names if you want, but discussion of satanism or religion of any kind was never there to begin with. The only overt "rubbing in" of religion I've ever seen on this board is in Steven Watanabe's signature, and I've never been offended by it despite not sharing his beliefs. His display of faith has never caused the kind of ruckus that this guy's HANDLE has. A little ridiculous. -- Cory Nelson
Hi All, I've hardly ever posted on the boost mailing list but have been a follower for quite some time. This is getting out of proportion, and that David would feel offended or fear that certain people would end up offended by an email address containing the word 'satan' is, honestly, pushing it a bit. Satan must be one of the most incarnated figures of religious belief in modern media and is a bit different than if he posted to this mailing list with an email address containing reference to paedophilia for example. Pavel did not promote satanism nor did he mention it in his post, as opposed to certain people who's signature openly display their religious views - which doesn't really have its place in a C++ development mailing list IMHO. That never seemed to be a problem in the past, so why the big fuss over an email address that he probably set-up as a teenager lacking inspiration for a good nickname ? O. On Mon, Mar 14, 2011 at 12:01 PM, Domagoj Saric < domagoj.saric@littleendian.com> wrote:
"Robert Kawulak" <robert.kawulak@gmail.com> wrote in message
news:!&!AAAAAAAAAAAYAAAAAAAAAIOMVDziZelGq5Y6SEMPLILCgAAAEAAAADtlZSuuK/BMtVsYaIkMYa0BAAAAAA==@gmail.com...
[...] after all, is just another variation [...] [...] So let's just be fair and consistent and equally tolerate all [...] or tolerate none.
In order to facilitate peaceful, constructive and on-topic discussion in any non-political/philosophical/religious discussion group a certain 'common-law'-like ethos or a common/'axiomatic' set of 'civilized values' has to be accepted and respected by everyone.
"Absolute tolerance" is just another self-contradicting post-modern idea for it would, of course, have to tolerate intolerance.
In a multi-billion population you will find very many people (including university professors) that will argue for or have nothing against e.g. paedophilia, zoophilia, eugenics, euthanasia etc... And, until we "evolve" enough to accept these "behavioural patterns" as "generally acceptable", they should not be 'rubbed in' as "acceptable" in non-political/philosophical/religious discussion groups...the same goes for Satanism...
-- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
At Mon, 14 Mar 2011 14:05:42 +0000, Olivier Grant wrote:
Hi All,
I've hardly ever posted on the boost mailing list but have been a follower for quite some time.
This is getting out of proportion, and that David would feel offended or fear that certain people would end up offended by an email address containing the word 'satan' is, honestly, pushing it a bit.
I didn't feel offended. However, the moderators did receive a complaint. I told the complainant I wasn't inclined to do anything "official" about it, and none of the other moderators responded. But then Pavel went out of his way to ask for feedback about his communication style, of which his email handle is certainly a part. I didn't feel it out of place to give him my personal reaction. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
2011/3/14 Domagoj Saric <domagoj.saric@littleendian.com>:
"Absolute tolerance" is just another self-contradicting post-modern idea for it would, of course, have to tolerate intolerance.
In a multi-billion population you will find very many people (including university professors) that will argue for or have nothing against e.g. paedophilia, zoophilia, eugenics, euthanasia etc...
Just to be clear - I wouldn't defend references to paedophilia since paedophilia is a crime. Satanism is not a crime, it's only a philosophy/religion. Sure, one may argue that people were doing horrible things under the banner of Satanism, but the same applies to most of the mainstream religions. I'm not advocating absolute tolerance. I'm only expressing my concern about David's feeling that someone's nick is assaulting someone's religious sensitivity while we have so many other religious manifests on the list at the same time. Let's not make a mountain out of the molehill and just leave this alone. Best regards, Robert
At Mon, 14 Mar 2011 15:46:20 +0100, Robert Kawulak wrote:
2011/3/14 Domagoj Saric <domagoj.saric@littleendian.com>:
"Absolute tolerance" is just another self-contradicting post-modern idea for it would, of course, have to tolerate intolerance.
In a multi-billion population you will find very many people (including university professors) that will argue for or have nothing against e.g. paedophilia, zoophilia, eugenics, euthanasia etc...
Just to be clear - I wouldn't defend references to paedophilia since paedophilia is a crime. Satanism is not a crime, it's only a philosophy/religion. Sure, one may argue that people were doing horrible things under the banner of Satanism, but the same applies to most of the mainstream religions.
I suppose if I had thought there was any chance that Pavel was an actual Satanist, I'd have written something different. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (26)
-
Arindam Mukherjee -
Chad Nelson -
Christopher Jefferson -
Cory Nelson -
Dave Abrahams -
Domagoj Saric -
Hal Finkel -
Jeffrey Lee Hellrung, Jr. -
Jim Bell -
Joachim Faulhaber -
Julian Gonggrijp -
Krzysztof Czainski -
Marsh Ray -
Mathias Gaunard -
Mathieu - -
Matus Chochlik -
Mika Heiskanen -
Olivier Grant -
pavel novikov -
Robert Kawulak -
Robert Ramey -
SATAN66613 -
Simonson, Lucanus J -
Steven Watanabe -
Stewart, Robert -
Vladimir Prus