• bobef (2/2) Jul 17 2008 This has probably been asked many times before. If someone knows of such...
• dsimcha (25/25) Jul 17 2008 If we're going to make the jump and expose these features to the program...
• bearophile (4/7) Jul 17 2008 GCC has profile-guided optimization, that is often enough for the compil...
• Steven Schveighoffer (7/10) Jul 17 2008 Although a noinline directive would be ideal, it is technically possible...
• Nick Sabalausky (3/14) Jul 17 2008 You could write it as a string mixin.
• JAnderson (4/23) Jul 18 2008 What about using a template? Wouldn't that encourage the compiler to
• Bill Baxter (5/6) Jul 17 2008 Looking ahead, I think macro() will reduce the need for an inline
• Jason House (2/10) Jul 17 2008 The last thing I want from a language is two completely different method...
• Jarrett Billingsley (3/14) Jul 17 2008 Macros aren't coming until D3.
• Walter Bright (4/6) Jul 17 2008 I don't see the need for an inline or non-inline specifier. It's as
• Extrawurst (4/10) Jul 18 2008 All i can say is, that over at work when profiling our 3D Game Engine,
• Walter Bright (2/5) Jul 18 2008 The -inline switch to the compiler will inline functions.
• Jarrett Billingsley (4/9) Jul 18 2008 Walter, I think he's _well aware_ of that. He's talking about forcing
• Matti Niemenmaa (7/9) Jul 18 2008 Then why was "inout" renamed to "ref"?
• superdan (4/13) Jul 18 2008 how is that even close to making sense?
• Jarrett Billingsley (17/35) Jul 18 2008 Dan, you make good points and seem to have a head on your shoulders, but...
• BCS (6/9) Jul 18 2008 tactful and well put
• Matti Niemenmaa (7/12) Jul 18 2008 If it's a const reference, aliasing doesn't matter, no? Or am I missing
• Walter Bright (3/19) Jul 18 2008 It would have to be an invariant ref, not a const ref, for aliasing to
• superdan (4/49) Jul 22 2008 you're a good guy jarrett so i'll reply to this. the problem is i'm not ...
• JAnderson (9/13) Jul 29 2008 I'm glad I'm not the only one.
• superdan (2/18) Jul 29 2008 you almost had me convinced. then i saw the last word. shit man. edicate...
• BCS (10/13) Jul 29 2008 Bad speling does not invalideat a point (ignoreing things like "this st...
• JAnderson (4/22) Jul 31 2008 What if English was my second language? Would that invalidate my opinio...
• superdan (2/27) Jul 31 2008 odd. "edicate" is typical for americans who hear it and don't bother to ...
• Chris R. Miller (4/20) Jul 29 2008 Well if you're ______ity _____ cussing all the _____ time it makes your=...
• superdan (2/23) Jul 29 2008 did you mean "your"?
• Chris R. Miller (10/32) Jul 29 2008 =20
• BCS (5/22) Jul 29 2008 to give him /some/ credit: I think, depending on what ______ and _____ i...
• Simen Kjaeraas (4/26) Jul 29 2008 ___ _____ __! _____ __. ______ __ __ _____ __________________.
• superdan (3/32) Jul 29 2008 it was a legit question, einstein. i couldn't figure out what "____ity" ...
• Chris R. Miller (12/44) Jul 29 2008 ll=20
• Yigal Chripun (11/18) Aug 01 2008 I disagree. cussing shows lack of manners and lack of respect towards
• JAnderson (8/11) Jul 17 2008 May C++ compilers ignore the inline attribute because it has a better
• JAnderson (13/32) Jul 18 2008 I was working with MSVC++ the other day and found a couple of places
• Don (6/41) Jul 18 2008 Yup. Code cache can easily become a bottleneck. Similarly, turning on
• superdan (6/49) Jul 18 2008 just use the 'super' keyword:
• JAnderson (6/50) Jul 18 2008 I've had some good results with whole program optimisation. However not...
• Era Scarecrow (21/79) Jul 19 2008 A good point.
• Era Scarecrow (3/5) Jul 19 2008 My apologies, i'm catching up on 2 days of reading and digests. Perhaps...

bobef <bobef nosmap-abv.bg> writes:

This has probably been asked many times before. If someone knows of such
discussion please paste me a link. Why not an 'inline' attribute? We all know
that the compiler can be stupid some times, and even if it is not people may
want to inline something that is normally not appropriate for inlining. Auto
inlining is fine, but people should have control over such kind of things I
believe.

Regards, bobef

dsimcha <dsimcha yahoo.com> writes:

If we're going to make the jump and expose these features to the programmer, a
noinline attribute to do the opposite might be nice also.  Here's a hypothetical
example of where that might be nice:

void myFunc(int foo) {
   foreach(i, 0..1_000_000) {
       if(foo < 5) {  //This is an unusual case, foo usually >5.
          bar(foo);
       }
       //Stuff that may change the value of foo.
   }
   //More stuff that may change the value of foo.
   foreach(i; 0..1_000_000) {
       if(foo < 5) {  //Again unusual
           bar(foo);
       }
       //More stuff that may change the value of foo.
   }
}

In this case the compiler, not understanding the high-level meaning of what is
being done, would likely not realize that foo is almost always >= 5 in
real-world
scenarios.  It would likely inline bar at both places it's called from,
contributing to code bloat, especially since it's called from a loop that
iterates
a lot of times.  However, since the programmer knows that the branch that calls
bar() will be taken very infrequently, the programmer might want to specify that
bar() should not be inlined.

bearophile <bearophileHUGS lycos.com> writes:

dsimcha:
 In this case the compiler, not understanding the high-level meaning of what is
 being done, would likely not realize that foo is almost always >= 5 in
real-world
 scenarios.

GCC has profile-guided optimization, that is often enough for the compiler to
know what branch is the most frequent. In GCC there's the __builtin_expect()
too for a similar purpose (if a branch calls a function rarely, the compiler
understands it's probably not positive to inline it).

Bye,
bearophile

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"dsimcha" wrote
 If we're going to make the jump and expose these features to the 
 programmer, a
 noinline attribute to do the opposite might be nice also.

Although a noinline directive would be ideal, it is technically possible to 
force non-inlining of functions by using D interface files (.di) to define 
the functions as prototypes, and only compile the real code in an object 
file.  But that's a lot of work compared to just tagging the function.

Forcing inlining, on the other hand, is impossible currently.

-Steve 

"Nick Sabalausky" <a a.a> writes:

"Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
news:g5p23e$2iue$1 digitalmars.com...
 "dsimcha" wrote
 If we're going to make the jump and expose these features to the 
 programmer, a
 noinline attribute to do the opposite might be nice also.

 Although a noinline directive would be ideal, it is technically possible 
 to force non-inlining of functions by using D interface files (.di) to 
 define the functions as prototypes, and only compile the real code in an 
 object file.  But that's a lot of work compared to just tagging the 
 function.

 Forcing inlining, on the other hand, is impossible currently.

 -Steve

You could write it as a string mixin. 

JAnderson <ask me.com> writes:

Nick Sabalausky wrote:
 "Steven Schveighoffer" <schveiguy yahoo.com> wrote in message 
 news:g5p23e$2iue$1 digitalmars.com...
 "dsimcha" wrote
 If we're going to make the jump and expose these features to the 
 programmer, a
 noinline attribute to do the opposite might be nice also.

 Although a noinline directive would be ideal, it is technically possible 
 to force non-inlining of functions by using D interface files (.di) to 
 define the functions as prototypes, and only compile the real code in an 
 object file.  But that's a lot of work compared to just tagging the 
 function.

 Forcing inlining, on the other hand, is impossible currently.

 -Steve

 
 You could write it as a string mixin. 
 
 

What about using a template?  Wouldn't that encourage the compiler to 
inline?

-Joel

Bill Baxter <dnewsgroup billbaxter.com> writes:

bobef wrote:
 This has probably been asked many times before. If someone knows of such
discussion please paste me a link. Why not an 'inline' attribute? We all know
that the compiler can be stupid some times, and even if it is not people may
want to inline something that is normally not appropriate for inlining. Auto
inlining is fine, but people should have control over such kind of things I
believe.

Looking ahead, I think macro() will reduce the need for an inline 
specifier.  Yeh, it won't be quite the same, but it'll be close enough 
that making a separate inline keyword may not be worth it.

--bb

Jason House <jason.james.house gmail.com> writes:

Bill Baxter Wrote:

 bobef wrote:
 This has probably been asked many times before. If someone knows of such
discussion please paste me a link. Why not an 'inline' attribute? We all know
that the compiler can be stupid some times, and even if it is not people may
want to inline something that is normally not appropriate for inlining. Auto
inlining is fine, but people should have control over such kind of things I
believe.

 
 Looking ahead, I think macro() will reduce the need for an inline 
 specifier.  Yeh, it won't be quite the same, but it'll be close enough 
 that making a separate inline keyword may not be worth it.
 
 --bb

The last thing I want from a language is two completely different methods that
may require me to flip implementation methods for assumed gains from compiler
optimizations.

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"Bill Baxter" <dnewsgroup billbaxter.com> wrote in message 
news:g5od1q$2v3b$3 digitalmars.com...
 bobef wrote:
 This has probably been asked many times before. If someone knows of such 
 discussion please paste me a link. Why not an 'inline' attribute? We all 
 know that the compiler can be stupid some times, and even if it is not 
 people may want to inline something that is normally not appropriate for 
 inlining. Auto inlining is fine, but people should have control over such 
 kind of things I believe.

 Looking ahead, I think macro() will reduce the need for an inline 
 specifier.  Yeh, it won't be quite the same, but it'll be close enough 
 that making a separate inline keyword may not be worth it.

 --bb

Macros aren't coming until D3. 

Walter Bright <newshound1 digitalmars.com> writes:

Bill Baxter wrote:
 Looking ahead, I think macro() will reduce the need for an inline 
 specifier.

I don't see the need for an inline or non-inline specifier. It's as 
obsolete as the register keyword. Does anyone have a non-trivial 
non-contrived benchmark where a difference is measurable?

Extrawurst <spam extrawurst.org> writes:

All i can say is, that over at work when profiling our 3D Game Engine, 
it is often the case that forcing the compiler to inline (MSVC 2005) 
helps making peaces of code faster.


Walter Bright schrieb:
 Bill Baxter wrote:
 Looking ahead, I think macro() will reduce the need for an inline 
 specifier.

 I don't see the need for an inline or non-inline specifier. It's as 
 obsolete as the register keyword. Does anyone have a non-trivial 
 non-contrived benchmark where a difference is measurable?

Walter Bright <newshound1 digitalmars.com> writes:

Extrawurst wrote:
 All i can say is, that over at work when profiling our 3D Game Engine, 
 it is often the case that forcing the compiler to inline (MSVC 2005) 
 helps making peaces of code faster.

The -inline switch to the compiler will inline functions.

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:g5qnt3$227v$1 digitalmars.com...
 Extrawurst wrote:
 All i can say is, that over at work when profiling our 3D Game Engine, it 
 is often the case that forcing the compiler to inline (MSVC 2005) helps 
 making peaces of code faster.

 The -inline switch to the compiler will inline functions.

Walter, I think he's _well aware_ of that.  He's talking about forcing 
inlining, regardless of what the compiler thinks is best. 

Matti Niemenmaa <see_signature for.real.address> writes:

Walter Bright wrote:
 I don't see the need for an inline or non-inline specifier. It's as 
 obsolete as the register keyword.

Then why was "inout" renamed to "ref"?

Before you say, "so that we could have 'const ref'", let me note that ref in 
that sense is as obsolete as inline or register. It should just be "in" or the 
default and the compiler should figure out whether it's by-reference or
by-value.

-- 
E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi

superdan <super dan.org> writes:

Matti Niemenmaa Wrote:

 Walter Bright wrote:
 I don't see the need for an inline or non-inline specifier. It's as 
 obsolete as the register keyword.

 
 Then why was "inout" renamed to "ref"?
 
 Before you say, "so that we could have 'const ref'", let me note that ref in 
 that sense is as obsolete as inline or register. It should just be "in" or the 
 default and the compiler should figure out whether it's by-reference or
by-value.

how is that even close to making sense? 

before you say, "but value vs. 'in' is entirely transparent to the user", let
me note that aliasing is going to fuck that plan right there.

deciding value vs. reference only works for invariant shit. it's in fact part
of why invariant shit is so fucking brilliant.

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"superdan" <super dan.org> wrote in message 
news:g5qa4f$n1g$1 digitalmars.com...
 Matti Niemenmaa Wrote:

 Walter Bright wrote:
 I don't see the need for an inline or non-inline specifier. It's as
 obsolete as the register keyword.

 Then why was "inout" renamed to "ref"?

 Before you say, "so that we could have 'const ref'", let me note that ref 
 in
 that sense is as obsolete as inline or register. It should just be "in" 
 or the
 default and the compiler should figure out whether it's by-reference or 
 by-value.

 how is that even close to making sense?

 before you say, "but value vs. 'in' is entirely transparent to the user", 
 let me note that aliasing is going to fuck that plan right there.

 deciding value vs. reference only works for invariant shit. it's in fact 
 part of why invariant shit is so fucking brilliant.

Dan, you make good points and seem to have a head on your shoulders, but the 
swearing really is unnecessary.  That doesn't mean I don't swear, I do it 
all the time.  But this is not really the place for it.

Consider how much more coherent and reasonable your post sounds like this:

----
how is that even close to making sense?

before you say, "but value vs. 'in' is entirely transparent to the user", 
let me note that aliasing is going to completely invalidate that plan right 
there.

deciding value vs. reference only works for invariant data. it's in fact 
part of why invariant data is so incredibly brilliant.
----

Please don't take this as an attack, I'm not trying to make you feel like 
you're less of a member of the community.  Swearing on the internet just 
makes you seem like a 13-year-old boy. 

BCS <ao pathlink.com> writes:

Reply to Jarrett,

 Swearing on the
 internet just makes you seem like a 13-year-old boy.
 

tactful and well put

On the Internet often the /only/ available view of a person is what they 
type. As I often quit reading after the 2nd or 3rd cuss word, it's easy to 
never see anything inelegant that might be written later (and I don't consider 
this a problem).

Matti Niemenmaa <see_signature for.real.address> writes:

superdan wrote:
 before you say, "but value vs. 'in' is entirely transparent to the user", let
 me note that aliasing is going to fuck that plan right there.
 
 deciding value vs. reference only works for invariant shit. it's in fact part
 of why invariant shit is so fucking brilliant.

If it's a const reference, aliasing doesn't matter, no? Or am I missing 
something about D2's latest const system (quite possible)? One should only be 
reading from a const ref so it's semantically equivalent to just 'in'.

'inout' should still be there, with reasonable aliasing restrictions.

-- 
E-mail address: matti.niemenmaa+news, domain is iki (DOT) fi

Walter Bright <newshound1 digitalmars.com> writes:

Matti Niemenmaa wrote:
 superdan wrote:
 before you say, "but value vs. 'in' is entirely transparent to the 
 user", let
 me note that aliasing is going to fuck that plan right there.

 deciding value vs. reference only works for invariant shit. it's in 
 fact part
 of why invariant shit is so fucking brilliant.

 
 If it's a const reference, aliasing doesn't matter, no? Or am I missing 
 something about D2's latest const system (quite possible)? One should 
 only be reading from a const ref so it's semantically equivalent to just 
 'in'.

It would have to be an invariant ref, not a const ref, for aliasing to 
not matter.

 
 'inout' should still be there, with reasonable aliasing restrictions.
 

superdan <super dan.org> writes:

Jarrett Billingsley Wrote:

 "superdan" <super dan.org> wrote in message 
 news:g5qa4f$n1g$1 digitalmars.com...
 Matti Niemenmaa Wrote:

 Walter Bright wrote:
 I don't see the need for an inline or non-inline specifier. It's as
 obsolete as the register keyword.

 Then why was "inout" renamed to "ref"?

 Before you say, "so that we could have 'const ref'", let me note that ref 
 in
 that sense is as obsolete as inline or register. It should just be "in" 
 or the
 default and the compiler should figure out whether it's by-reference or 
 by-value.

 how is that even close to making sense?

 before you say, "but value vs. 'in' is entirely transparent to the user", 
 let me note that aliasing is going to fuck that plan right there.

 deciding value vs. reference only works for invariant shit. it's in fact 
 part of why invariant shit is so fucking brilliant.

 
 Dan, you make good points and seem to have a head on your shoulders, but the 
 swearing really is unnecessary.  That doesn't mean I don't swear, I do it 
 all the time.  But this is not really the place for it.
 
 Consider how much more coherent and reasonable your post sounds like this:
 
 ----
 how is that even close to making sense?
 
 before you say, "but value vs. 'in' is entirely transparent to the user", 
 let me note that aliasing is going to completely invalidate that plan right 
 there.
 
 deciding value vs. reference only works for invariant data. it's in fact 
 part of why invariant data is so incredibly brilliant.
 ----
 
 Please don't take this as an attack, I'm not trying to make you feel like 
 you're less of a member of the community.  Swearing on the internet just 
 makes you seem like a 13-year-old boy. 

you're a good guy jarrett so i'll reply to this. the problem is i'm not a good
guy. anyone who knows me would agree i'm a gaping asshole. but at least i'm not
bullshitting. if i say something online you know i could say the same to your
face. and anyone fucking with me will get a good serving of knuckle juice with
shin extract for good measure. so why would i lie online by being nice.

if anything pisses me off it's the opposite phenomenon: people who are all
nicey-nicey in real life and they let their fucking aggression go berserk
online. if most would have to say to another's face 10% of what they say
online, they'd shit in their pants. as an example. i couldn't make it to the d
conference last year. did anyone start a fight? i bet not. yet if this group
was any indication, that would've been a fucking ufc conference, not a d
conference.

sticking online with what you could afford saying irl is the best way.

JAnderson <ask me.com> writes:

superdan wrote:
 Jarrett Billingsley Wrote:

 Please don't take this as an attack, I'm not trying to make you feel like 
 you're less of a member of the community.  Swearing on the internet just 
 makes you seem like a 13-year-old boy. 


I'm glad I'm not the only one.

In general I find it hard to read someone text if it has swearing all 
over it.  I generally ignore those emails as I feel they have no 
valuable content and they make me feel sick.  I don't want to be 
thinking about the bathroom while in technical discussions.

If someone wants to be taken seriously they should try to at least 
communicate with proper edicate.

-Joel

superdan <super dan.org> writes:

JAnderson Wrote:

 superdan wrote:
 Jarrett Billingsley Wrote:

 
 Please don't take this as an attack, I'm not trying to make you feel like 
 you're less of a member of the community.  Swearing on the internet just 
 makes you seem like a 13-year-old boy. 


 
 I'm glad I'm not the only one.
 
 In general I find it hard to read someone text if it has swearing all 
 over it.  I generally ignore those emails as I feel they have no 
 valuable content and they make me feel sick.  I don't want to be 
 thinking about the bathroom while in technical discussions.
 
 If someone wants to be taken seriously they should try to at least 
 communicate with proper edicate.

you almost had me convinced. then i saw the last word. shit man. edicate? did
you mean etiquette? are you gwb undercover?

BCS <ao pathlink.com> writes:

Reply to superdan,

 you almost had me convinced. then i saw the last word. shit man.
 edicate? did you mean etiquette? are you gwb undercover?
 

Bad speling does not invalideat a point  (ignoreing things like "this
statemeant 
is speled corectly"). The only reson that bad speling wood make a diference 
is if the readar is incapeble of  logikal though and asumes that if the righter 
can spel that the argumint is valod.

Bad spelling does not invalidate a point (ignoring things like "this statement 
is spelled correctly"). The only reason that bad spelling would make a
difference 
is if the reader is incapable of logical though and assumes that if the writer 
can spell that the argument is valid.

QED

JAnderson <ask me.com> writes:

superdan wrote:
 JAnderson Wrote:
 
 superdan wrote:
 Jarrett Billingsley Wrote:
 Please don't take this as an attack, I'm not trying to make you feel like 
 you're less of a member of the community.  Swearing on the internet just 
 makes you seem like a 13-year-old boy. 


 I'm glad I'm not the only one.

 In general I find it hard to read someone text if it has swearing all 
 over it.  I generally ignore those emails as I feel they have no 
 valuable content and they make me feel sick.  I don't want to be 
 thinking about the bathroom while in technical discussions.

 If someone wants to be taken seriously they should try to at least 
 communicate with proper edicate.

 
 you almost had me convinced. then i saw the last word. edicate? did you mean
etiquette? are you gwb undercover?

What if English was my second language?  Would that invalidate my opinion?

-Joel

BTW: My first language is C++ followed by D, then English :)

superdan <super dan.org> writes:

JAnderson Wrote:

 superdan wrote:
 JAnderson Wrote:
 
 superdan wrote:
 Jarrett Billingsley Wrote:
 Please don't take this as an attack, I'm not trying to make you feel like 
 you're less of a member of the community.  Swearing on the internet just 
 makes you seem like a 13-year-old boy. 


 I'm glad I'm not the only one.

 In general I find it hard to read someone text if it has swearing all 
 over it.  I generally ignore those emails as I feel they have no 
 valuable content and they make me feel sick.  I don't want to be 
 thinking about the bathroom while in technical discussions.

 If someone wants to be taken seriously they should try to at least 
 communicate with proper edicate.

 
 you almost had me convinced. then i saw the last word. edicate? did you mean
etiquette? are you gwb undercover?

 
 What if English was my second language?  Would that invalidate my opinion?
 
 -Joel
 
 BTW: My first language is C++ followed by D, then English :)

odd. "edicate" is typical for americans who hear it and don't bother to spell
it. foreigners usually spell properly. at any rate: spell checkers leave little
room for excuse. until a good argument comes along, i'll continue making
sailors cry.

"Chris R. Miller" <lordSaurontheGreat gmail.com> writes:

JAnderson wrote:
 superdan wrote:
 Jarrett Billingsley Wrote:

=20
 Please don't take this as an attack, I'm not trying to make you feel =



 like you're less of a member of the community.  Swearing on the=20
 internet just makes you seem like a 13-year-old boy.=20


=20
 I'm glad I'm not the only one.
=20
 In general I find it hard to read someone text if it has swearing all=20
 over it.  I generally ignore those emails as I feel they have no=20
 valuable content and they make me feel sick.  I don't want to be=20
 thinking about the bathroom while in technical discussions.
=20
 If someone wants to be taken seriously they should try to at least=20
 communicate with proper edicate.

Well if you're ______ity _____ cussing all the _____ time it makes your=20
_______ing messages so much _______ing longer it takes so ______ing long =

to _______ing read them that I just _____ing ignore them.

superdan <super dan.org> writes:

Chris R. Miller Wrote:

 JAnderson wrote:
 superdan wrote:
 Jarrett Billingsley Wrote:

 
 Please don't take this as an attack, I'm not trying to make you feel 
 like you're less of a member of the community.  Swearing on the 
 internet just makes you seem like a 13-year-old boy. 


 
 I'm glad I'm not the only one.
 
 In general I find it hard to read someone text if it has swearing all 
 over it.  I generally ignore those emails as I feel they have no 
 valuable content and they make me feel sick.  I don't want to be 
 thinking about the bathroom while in technical discussions.
 
 If someone wants to be taken seriously they should try to at least 
 communicate with proper edicate.

 
 Well if you're ______ity _____ cussing all the _____ time it makes your 
 _______ing messages so much _______ing longer it takes so ______ing long 
 to _______ing read them that I just _____ing ignore them.

did you mean "your"?

"Chris R. Miller" <lordSaurontheGreat gmail.com> writes:

superdan wrote:
 Chris R. Miller Wrote:
=20
 JAnderson wrote:
 superdan wrote:
 Jarrett Billingsley Wrote:
 Please don't take this as an attack, I'm not trying to make you fee=





l=20
 like you're less of a member of the community.  Swearing on the=20
 internet just makes you seem like a 13-year-old boy.=20


 I'm glad I'm not the only one.

 In general I find it hard to read someone text if it has swearing all=



=20
 over it.  I generally ignore those emails as I feel they have no=20
 valuable content and they make me feel sick.  I don't want to be=20
 thinking about the bathroom while in technical discussions.

 If someone wants to be taken seriously they should try to at least=20
 communicate with proper edicate.

 Well if you're ______ity _____ cussing all the _____ time it makes you=


r=20
 _______ing messages so much _______ing longer it takes so ______ing lo=


ng=20
 to _______ing read them that I just _____ing ignore them.

=20
 did you mean "your"?

No, my grammar was correct.  You're =3D you are (contraction), your =3D y=
ou=20
(possessive).

Perhaps you'd like to go play the part of a Grammar Nazi with the other=20

BCS <ao pathlink.com> writes:

Reply to Chris,

 superdan wrote:
 
 Chris R. Miller Wrote:
 
 Well if you're ______ity _____ cussing all the _____ time it makes
 your _______ing messages so much _______ing longer it takes so
 ______ing long to _______ing read them that I just _____ing ignore
 them.
 

 did you mean "your"?
 

 No, my grammar was correct.  You're = you are (contraction), your =
 you (possessive).
 
 Perhaps you'd like to go play the part of a Grammar Nazi with the

 

to give him /some/ credit: I think, depending on what ______ and _____ is 
used, "your" and "you're" may both be correct. But who the _____* cares!

* I can see it now, this thread will end in a post with nothing but _s and 
' 's.

"Simen Kjaeraas" <simen.kjaras gmail.com> writes:

On Tue, 29 Jul 2008 23:47:41 +0200, BCS <ao pathlink.com> wrote:

 Reply to Chris,

 superdan wrote:

 Chris R. Miller Wrote:

 Well if you're ______ity _____ cussing all the _____ time it makes
 your _______ing messages so much _______ing longer it takes so
 ______ing long to _______ing read them that I just _____ing ignore
 them.

 did you mean "your"?

 No, my grammar was correct.  You're = you are (contraction), your =
 you (possessive).
  Perhaps you'd like to go play the part of a Grammar Nazi with the


 to give him /some/ credit: I think, depending on what ______ and _____  
 is used, "your" and "you're" may both be correct. But who the _____*  
 cares!

 * I can see it now, this thread will end in a post with nothing but _s  
 and ' 's.


___ _____ __! _____ __. ______ __ __ _____ __________________.

-- 
Simen

superdan <super dan.org> writes:

Chris R. Miller Wrote:

 superdan wrote:
 Chris R. Miller Wrote:
 
 JAnderson wrote:
 superdan wrote:
 Jarrett Billingsley Wrote:
 Please don't take this as an attack, I'm not trying to make you feel 
 like you're less of a member of the community.  Swearing on the 
 internet just makes you seem like a 13-year-old boy. 


 I'm glad I'm not the only one.

 In general I find it hard to read someone text if it has swearing all 
 over it.  I generally ignore those emails as I feel they have no 
 valuable content and they make me feel sick.  I don't want to be 
 thinking about the bathroom while in technical discussions.

 If someone wants to be taken seriously they should try to at least 
 communicate with proper edicate.

 Well if you're ______ity _____ cussing all the _____ time it makes your 
 _______ing messages so much _______ing longer it takes so ______ing long 
 to _______ing read them that I just _____ing ignore them.

 
 did you mean "your"?

 
 No, my grammar was correct.  You're = you are (contraction), your = you 
 (possessive).
 
 Perhaps you'd like to go play the part of a Grammar Nazi with the other 


it was a legit question, einstein. i couldn't figure out what "____ity" means.

at any rate. if someone asks me to change my language, they'd be a lot more
credible if they had theirs in good shape. cussing is a choice. "edicate" is
ignorance.

"Chris R. Miller" <lordSaurontheGreat gmail.com> writes:

superdan wrote:
 Chris R. Miller Wrote:
=20
 superdan wrote:
 Chris R. Miller Wrote:

 JAnderson wrote:
 superdan wrote:
 Jarrett Billingsley Wrote:
 Please don't take this as an attack, I'm not trying to make you f=







eel=20
 like you're less of a member of the community.  Swearing on the=20
 internet just makes you seem like a 13-year-old boy.=20


 I'm glad I'm not the only one.

 In general I find it hard to read someone text if it has swearing a=





ll=20
 over it.  I generally ignore those emails as I feel they have no=20
 valuable content and they make me feel sick.  I don't want to be=20
 thinking about the bathroom while in technical discussions.

 If someone wants to be taken seriously they should try to at least =





 communicate with proper edicate.

 Well if you're ______ity _____ cussing all the _____ time it makes y=




our=20
 _______ing messages so much _______ing longer it takes so ______ing =




long=20
 to _______ing read them that I just _____ing ignore them.

 did you mean "your"?

 No, my grammar was correct.  You're =3D you are (contraction), your =3D=


 you=20
 (possessive).

 Perhaps you'd like to go play the part of a Grammar Nazi with the othe=


r=20


=20
 it was a legit question, einstein. i couldn't figure out what "____ity"=

 means.

Fair enough.

 at any rate. if someone asks me to change my language, they'd be a lot =

more credible if they had theirs in good shape. cussing is a choice. "edi=
cate" is ignorance.

Cussing in a _public_ forum is absolutely intolerable.  Savvy?

Yigal Chripun <yigal100 gmail.com> writes:

superdan wrote:
<snip/>
 
 it was a legit question, einstein. i couldn't figure out what
 "____ity" means.
 
 at any rate. if someone asks me to change my language, they'd be a
 lot more credible if they had theirs in good shape. cussing is a
 choice. "edicate" is ignorance.

I disagree. cussing shows lack of manners and lack of respect towards
the people you try to communicate with. bad spelling can only show a
lack of a spell checker. you forget that this is an international forum
and so is most of the internet. Not all humanity is required to speak
English, and even English speakers can make typos.

I try to write in proper English (even though it's /not/ my native
tongue) and I also run the spell checker because I respect the people of
this forum. Certainly you can also show a little more respect towards
the people here.

JAnderson <ask me.com> writes:

bobef wrote:
 This has probably been asked many times before. If someone knows of such
discussion please paste me a link. Why not an 'inline' attribute? We all know
that the compiler can be stupid some times, and even if it is not people may
want to inline something that is normally not appropriate for inlining. Auto
inlining is fine, but people should have control over such kind of things I
believe.
 
 Regards, bobef

May C++ compilers ignore the inline attribute because it has a better 
handle on when to inline.  There have been some studies (does anyone 
have the links to these) where they've shown that most of the time the 
compiler can make a more intelligent guess then the average engineer.

But that's C++.  D does this automatic virtual's thing so its difficult 
to say whether the compiler can always make a good choice.

-Joel

JAnderson <ask me.com> writes:

JAnderson wrote:
 bobef wrote:
 This has probably been asked many times before. If someone knows of 
 such discussion please paste me a link. Why not an 'inline' attribute? 
 We all know that the compiler can be stupid some times, and even if it 
 is not people may want to inline something that is normally not 
 appropriate for inlining. Auto inlining is fine, but people should 
 have control over such kind of things I believe.

 Regards, bobef

 
 May C++ compilers ignore the inline attribute because it has a better 
 handle on when to inline.  There have been some studies (does anyone 
 have the links to these) where they've shown that most of the time the 
 compiler can make a more intelligent guess then the average engineer.
 
 But that's C++.  D does this automatic virtual's thing so its difficult 
 to say whether the compiler can always make a good choice.
 
 -Joel

I was working with MSVC++ the other day and found a couple of places 
where it wasn't inlining the code and was running slow.  So I placed a 
few inlines around and *bam* that code started running faster.  Then I 
profiled the code as a whole to see how much of an improvement I'd 
gained.  However the game was actually running slower.  It turned out 
that inlining had simply shifted the bottneck into memory and the 
program file size had got bigger, so the program cache was stalling all 
the time.

I'm not against inlining, I just think that you have to be really 
careful when using it and understand its implications (ie use a 
profiler), otherwise you could be making things worse.

-Joel

Don <nospam nospam.com.au> writes:

JAnderson wrote:
 JAnderson wrote:
 bobef wrote:
 This has probably been asked many times before. If someone knows of 
 such discussion please paste me a link. Why not an 'inline' 
 attribute? We all know that the compiler can be stupid some times, 
 and even if it is not people may want to inline something that is 
 normally not appropriate for inlining. Auto inlining is fine, but 
 people should have control over such kind of things I believe.

 Regards, bobef

 May C++ compilers ignore the inline attribute because it has a better 
 handle on when to inline.  There have been some studies (does anyone 
 have the links to these) where they've shown that most of the time the 
 compiler can make a more intelligent guess then the average engineer.

 But that's C++.  D does this automatic virtual's thing so its 
 difficult to say whether the compiler can always make a good choice.

 -Joel

 
 I was working with MSVC++ the other day and found a couple of places 
 where it wasn't inlining the code and was running slow.  So I placed a 
 few inlines around and *bam* that code started running faster.  Then I 
 profiled the code as a whole to see how much of an improvement I'd 
 gained.  However the game was actually running slower.  It turned out 
 that inlining had simply shifted the bottneck into memory and the 
 program file size had got bigger, so the program cache was stalling all 
 the time.
 
 I'm not against inlining, I just think that you have to be really 
 careful when using it and understand its implications (ie use a 
 profiler), otherwise you could be making things worse.
 
 -Joel

Yup. Code cache can easily become a bottleneck. Similarly, turning on 
'optimise for speed' for a whole program is almost always a bad idea.

More useful than 'inline', would be some way to tell the compiler 'this 
function is speed-critical'. If nothing else, it would have some 
documentation value.

superdan <super dan.org> writes:

Don Wrote:

 JAnderson wrote:
 JAnderson wrote:
 bobef wrote:
 This has probably been asked many times before. If someone knows of 
 such discussion please paste me a link. Why not an 'inline' 
 attribute? We all know that the compiler can be stupid some times, 
 and even if it is not people may want to inline something that is 
 normally not appropriate for inlining. Auto inlining is fine, but 
 people should have control over such kind of things I believe.

 Regards, bobef

 May C++ compilers ignore the inline attribute because it has a better 
 handle on when to inline.  There have been some studies (does anyone 
 have the links to these) where they've shown that most of the time the 
 compiler can make a more intelligent guess then the average engineer.

 But that's C++.  D does this automatic virtual's thing so its 
 difficult to say whether the compiler can always make a good choice.

 -Joel

 
 I was working with MSVC++ the other day and found a couple of places 
 where it wasn't inlining the code and was running slow.  So I placed a 
 few inlines around and *bam* that code started running faster.  Then I 
 profiled the code as a whole to see how much of an improvement I'd 
 gained.  However the game was actually running slower.  It turned out 
 that inlining had simply shifted the bottneck into memory and the 
 program file size had got bigger, so the program cache was stalling all 
 the time.
 
 I'm not against inlining, I just think that you have to be really 
 careful when using it and understand its implications (ie use a 
 profiler), otherwise you could be making things worse.
 
 -Joel

 
 Yup. Code cache can easily become a bottleneck. Similarly, turning on 
 'optimise for speed' for a whole program is almost always a bad idea.
 
 More useful than 'inline', would be some way to tell the compiler 'this 
 function is speed-critical'. If nothing else, it would have some 
 documentation value.

just use the 'super' keyword:

void myfunc() super 
{
}

:)

JAnderson <ask me.com> writes:

Don wrote:
 JAnderson wrote:
 JAnderson wrote:
 bobef wrote:
 This has probably been asked many times before. If someone knows of 
 such discussion please paste me a link. Why not an 'inline' 
 attribute? We all know that the compiler can be stupid some times, 
 and even if it is not people may want to inline something that is 
 normally not appropriate for inlining. Auto inlining is fine, but 
 people should have control over such kind of things I believe.

 Regards, bobef

 May C++ compilers ignore the inline attribute because it has a better 
 handle on when to inline.  There have been some studies (does anyone 
 have the links to these) where they've shown that most of the time 
 the compiler can make a more intelligent guess then the average 
 engineer.

 But that's C++.  D does this automatic virtual's thing so its 
 difficult to say whether the compiler can always make a good choice.

 -Joel

 I was working with MSVC++ the other day and found a couple of places 
 where it wasn't inlining the code and was running slow.  So I placed a 
 few inlines around and *bam* that code started running faster.  Then I 
 profiled the code as a whole to see how much of an improvement I'd 
 gained.  However the game was actually running slower.  It turned out 
 that inlining had simply shifted the bottneck into memory and the 
 program file size had got bigger, so the program cache was stalling 
 all the time.

 I'm not against inlining, I just think that you have to be really 
 careful when using it and understand its implications (ie use a 
 profiler), otherwise you could be making things worse.

 -Joel

 
 Yup. Code cache can easily become a bottleneck. Similarly, turning on 
 'optimise for speed' for a whole program is almost always a bad idea.

I've had some good results with whole program optimisation.  However not 
always.

 
 More useful than 'inline', would be some way to tell the compiler 'this 
 function is speed-critical'. If nothing else, it would have some 
 documentation value.

I think that's a good idea.  The compiler could also spin more cycles to 
optimize that piece of code.

-Joel

Era Scarecrow <rtcvb32 yahoo.com> writes:

 JAnderson wrote:
 bobef wrote:
 This has probably been asked many times before. If


 someone knows of 
 such discussion please paste me a link. Why not an


 'inline' attribute? 
 We all know that the compiler can be stupid some


 times, and even if it 
 is not people may want to inline something that is


 normally not 
 appropriate for inlining. Auto inlining is fine,


 but people should 
 have control over such kind of things I believe.

 Regards, bobef

 
 May C++ compilers ignore the inline attribute because

 it has a better 
 handle on when to inline.  There have been some

 studies (does anyone 
 have the links to these) where they've shown that

 most of the time the 
 compiler can make a more intelligent guess then the

 average engineer.
 
 But that's C++.  D does this automatic

 virtual's thing so its difficult 
 to say whether the compiler can always make a good

 choice.
 
 -Joel

 
 I was working with MSVC++ the other day and found a couple
 of places 
 where it wasn't inlining the code and was running slow.
  So I placed a 
 few inlines around and *bam* that code started running
 faster.  Then I 
 profiled the code as a whole to see how much of an
 improvement I'd 
 gained.  However the game was actually running slower.  It
 turned out 
 that inlining had simply shifted the bottneck into memory
 and the 
 program file size had got bigger, so the program cache was
 stalling all 
 the time.
 
 I'm not against inlining, I just think that you have to
 be really 
 careful when using it and understand its implications (ie
 use a 
 profiler), otherwise you could be making things worse.

 A good point.

 Recently i've stepped away from C and trying to get away from ultra-optimizing
code (which has made my best project look sloppy and i notice is ridden with
extra code, in order to get gains that i am not sure i'm actually getting)

 Could we, for instance use a profiler to comment and pull information from a
running program, and than use that to get optimizations that it might otherwise
have not noted?

 I recall something like this, but i don't want to look it up. bare with me.

(not exactly as before, but close)
 if (b)
   a = something;
 else
   a = somethingElse;

 Then say b had a 90% chance of being positive or negative, the running
profiler seeing that would then take the needed steps on a re-compiling stage
using that profiling in order to optimize, without worrying about portability
and readability problems?

We see the above code, the compiler does...

 (if b is greater for being positive)
a=something;
if (!b)
  a=somethingElse;

  Course, unless there's something big or slow in the calls, or SomethingElse
takes longer than something (besides a simple type), i don't think there's much
of a speed gain. If for example the opposite was true..


 (if b is greater for being positive)
char []buffer;  //what for i'm not sure.

buffer=something;
if (!someflag)
  buffer=new char[xxx];

  Then the speed gains from not having to initialize the memory for some flag
is still true, although it wouldn't be much speed gains honestly. hmm..

(Assembly would say, 1 compare, 1 jump, 1 assignment/call, regardless)

 Oh well. Thoughts on an external profiler to assist with the compiler with
optimization?

 Era


      

Era Scarecrow <rtcvb32 yahoo.com> writes:

  Oh well. Thoughts on an external profiler to assist with
 the compiler with optimization?

 My apologies, i'm catching up on 2 days of reading and digests. Perhaps i
should keep my mouth shut. It's only after i post that 3-4 messages later i see
the very topic i commented on is already in discussion. :(

 Era