www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - GCC 4.6

reply bearophile <bearophileHUGS lycos.com> writes:
Some changes in the new version of GCC, 4.6:

New warnings (I want something similar in D too):


New -Wunused-but-set-variable and -Wunused-but-set-parameter warnings were
added for C, C++, Objective-C and Objective-C++. These warnings diagnose
variables respective parameters which are only set in the code and never
otherwise used. Usually such variables are useless and often even the value
assigned to them is computed needlessly, sometimes expensively. The
-Wunused-but-set-variable warning is enabled by default by -Wall flag and
-Wunused-but-set-parameter by -Wall -Wextra flags.<



Link-Time Optimizations is now more powerful:


GCC itself, Mozilla Firefox and other large applications can be built with LTO
enabled.<




Static constructors and destructors from individual units are inlined into a
single function. This can significantly improve startup times of large C++
applications where static constructors are very common. <




Improved auto-detection of const and pure functions. Newly, noreturn functions
are auto-detected.<



Interesting:


The -Wsuggest-attribute=[const|pure|noreturn] flag is available that informs
users when adding attributes to headers might improve code generation.<


-Wsuggest-attribute=[pure|const|noreturn]
    Warn for cases where adding an attribute may be beneficial. The attributes
currently supported are listed below.
    -Wsuggest-attribute=pure
    -Wsuggest-attribute=const
    -Wsuggest-attribute=noreturn
        Warn about functions which might be candidates for attributes pure,
const or noreturn. The compiler only warns for functions visible in other
compilation units or (in the case of pure and const) if it cannot prove that
the function returns normally. A function returns normally if it doesn't
contain an infinite loop nor returns abnormally by throwing, calling abort() or
trapping. This analysis requires option -fipa-pure-const, which is enabled by
default at -O and higher. Higher optimization levels improve the accuracy of
the analysis. 


I will have to test this:


Virtual methods are considered for inlining when the caller is inlined and
devirtualization is then possible.<



Functions whose address was taken are now optimized out when all references to
them are dead.<



This is sometimes useful in smaller systems, I think:


A new switch -fstack-usage has been added. It makes the compiler output stack
usage information for the program, on a per-function basis, in an auxiliary
file.<



I don't undersatand why this is useful, why the compiler isn't able to infer
this by itself:


A new function attribute leaf was introduced. This attribute allows better
inter-procedural optimization across calls to functions that return to the
current unit only via returning or exception handling. This is the case for
most library functions that have no callbacks.<



And I understand this even less:


The new function attribute callee_pop_aggregate allows to specify if the caller
or callee is responsible for popping the aggregate return pointer value from
the stack.<



This is curious, in nothrow functions throws become halts:


The new -fnothrow-opt flag changes the semantics of a throw() exception
specification to match the proposed semantics of the noexcept specification:
just call terminate if an exception tries to propagate out of a function with
such an exception specification. This dramatically reduces or eliminates the
code size overhead from adding the exception specification.<



This seems useful:


The -Wshadow option now warns if a local variable or type declaration shadows
another type in C++. Note that the compiler will not warn if a local variable
shadows a struct/class/enum, but will warn if it shadows an explicit typedef.<



When an identifier is not found in the current scope, G++ now offers
suggestions about which identifier might have been intended.<




Support for the Go programming language has been added to GCC. It is not
enabled by default when you build GCC; use the --enable-languages configure
option to build it.<



It seems GCC now supports the TBM (Trailing Bit Manipulation) instructions too:
http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01767.html

Bye,
bearophile
Mar 26 2011
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/26/11 4:51 PM, bearophile wrote:

 Some changes in the new version of GCC, 4.6:


[snip]

Heh, I was just following the reddit discussion, in which D vs. Go was 
due to appear:

http://www.reddit.com/r/programming/comments/gbzvv/gcc_46_is_released/


Andrei
Mar 26 2011
prev sibling next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Mar 27, 11 05:51, bearophile wrote:

 I don't undersatand why this is useful, why the compiler isn't able to infer
this by itself:


A new function attribute leaf was introduced. This attribute allows better
inter-procedural optimization across calls to functions that return to the
current unit only via returning or exception handling. This is the case for
most library functions that have no callbacks.<






Most of these attributes are designed for control freaks that don't 
believe in the compiler's decision :).

gcc's manual says,


 Calls to external functions with this attribute must return to the current
compilation unit only by return or by exception handling. In particular, leaf
functions are not allowed to call callback function passed to it from the
current compilation unit or directly call functions exported by the unit or
longjmp into the unit. Leaf function might still call functions from other
compilation units and thus they are not necessarily leaf in the sense that they
contain no function calls at all.
 The attribute is intended for library functions to improve dataflow analysis.
The compiler takes the hint that any data not escaping the current compilation
unit can not be used or modified by the leaf function. For example, the sin
function is a leaf function, but qsort is not.

 Note that leaf functions might invoke signals and signal handlers might be
defined in the current compilation unit and use static variables. The only
compliant way to write such a signal handler is to declare such variables
volatile.

 The attribute has no effect on functions defined within the current
compilation unit. This is to allow easy merging of multiple compilation units
into one, for example, by using the link time optimization. For this reason the
attribute is not allowed on types to annotate indirect calls.


;


 And I understand this even less:


The new function attribute callee_pop_aggregate allows to specify if the caller
or callee is responsible for popping the aggregate return pointer value from
the stack.<






Just calling convention stuff.
Mar 26 2011
parent bearophile <bearophileHUGS lycos.com> writes:
KennyTM~:


 Just calling convention stuff.


Oh, right, now I understand that changelog comment :-)

Bye,
bearophile
Mar 26 2011
prev sibling next sibling parent Trass3r <un known.com> writes:
Am 26.03.2011, 22:51 Uhr, schrieb bearophile <bearophileHUGS lycos.com>:

 Some changes in the new version of GCC, 4.6:
 Link-Time Optimizations is now more powerful:


 GCC itself, Mozilla Firefox and other large applications can be built  
 with LTO enabled.<




LTO ftw!
Mar 26 2011
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/26/2011 2:51 PM, bearophile wrote:

 This seems useful:


 The -Wshadow option now warns if a local variable or type declaration
 shadows another type in C++. Note that the compiler will not warn if a
 local variable shadows a struct/class/enum, but will warn if it shadows an
 explicit typedef.<




D already does this.


 When an identifier is not found in the current scope, G++ now offers
 suggestions about which identifier might have been intended.




and this.
Mar 26 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:


 D already does this.
 and this.


But not this:


New -Wunused-but-set-variable and -Wunused-but-set-parameter warnings were
added for C, C++, Objective-C and Objective-C++. These warnings diagnose
variables respective parameters which are only set in the code and never
otherwise used. Usually such variables are useless and often even the value
assigned to them is computed needlessly, sometimes expensively. The
-Wunused-but-set-variable warning is enabled by default by -Wall flag and
-Wunused-but-set-parameter by -Wall -Wextra flags.<


Bye,
bearophile
Mar 26 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/26/2011 6:28 PM, bearophile wrote:

 Walter:


 D already does this. and this.


 But not this:


 New -Wunused-but-set-variable and -Wunused-but-set-parameter warnings were
 added for C, C++, Objective-C and Objective-C++. These warnings diagnose
 variables respective parameters which are only set in the code and never
 otherwise used. Usually such variables are useless and often even the value
 assigned to them is computed needlessly, sometimes expensively. The
 -Wunused-but-set-variable warning is enabled by default by -Wall flag and
 -Wunused-but-set-parameter by -Wall -Wextra flags.<




This is quite deliberate. These kinds of errors tend to be very annoying when 
developing code.

The optimizer removes those as "dead assignments", so no value is computed 
needlessly or expensively.
Mar 26 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:


 New -Wunused-but-set-variable and -Wunused-but-set-parameter warnings were
 added for C, C++, Objective-C and Objective-C++. These warnings diagnose
 variables respective parameters which are only set in the code and never
 otherwise used. Usually such variables are useless and often even the value
 assigned to them is computed needlessly, sometimes expensively. The
 -Wunused-but-set-variable warning is enabled by default by -Wall flag and
 -Wunused-but-set-parameter by -Wall -Wextra flags.<







 These kinds of errors tend to be very annoying when developing code.


With "errors" do you mean the warnings GCC 4.6 shows you when you add the
"-Wunused-but-set-variable" to the switches? I have not tried GCC4.6 yet, but
GCC 4.5 has a related warning, for unused variables. This warning is present in

the C++ Microsoft compiler too). This warning has caught some bugs in my C/C++
code. So I like it/them a lot.



 The optimizer removes those as "dead assignments", so no value is computed 
 needlessly or expensively.


The point of those warnings is NOT to improve code/compiler optimizations, but
just to help programmers catch their bugs better.

A nice paper, "Using Redundancies to Find Errors", by Yichen Xie and Dawson
Engler, 2002:
http://www.stanford.edu/~engler/p401-xie.pdf

It shows that most programmers don't put deliberatively redundancies in their
programs, like assigning a value to a variable and never reading it again (in
all code paths). When this happens in programs, frequently that's a bug of the
programmer. So catching unused variables, or variables set and then never read
is a good way to catch programmers bugs.


my personal experience in C) tell the same story. A way to automatically find
unused variables is good in the compiler. I think it's not easy for you to
confute them all :-)

Bye,
bearophile
Mar 26 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/26/2011 7:10 PM, bearophile wrote:

 The optimizer removes those as "dead assignments", so no value is computed
 needlessly or expensively.


 The point of those warnings is NOT to improve code/compiler optimizations,
 but just to help programmers catch their bugs better.


You quoted a claim saying it was also an optimization.



 A nice paper, "Using Redundancies to Find Errors", by Yichen Xie and Dawson
 Engler, 2002: http://www.stanford.edu/~engler/p401-xie.pdf

 It shows that most programmers don't put deliberatively redundancies in their
 programs, like assigning a value to a variable and never reading it again (in
 all code paths). When this happens in programs, frequently that's a bug of
 the programmer. So catching unused variables, or variables set and then never
 read is a good way to catch programmers bugs.


As I said, these kinds of error messages are very annoying when developing
code, 
for example, when enabling and disabling various sections.




 my personal experience in C) tell the same story. A way to automatically find
 unused variables is good in the compiler. I think it's not easy for you to
 confute them all :-)


I get told I'm wrong on just about everything I do.
Mar 26 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-03-26 22:03, Walter Bright wrote:

 I get told I'm wrong on just about everything I do.


No, you're wrong about that! ;)

- Jonathan M Davis
Mar 26 2011
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:


 You quoted a claim saying it was also an optimization.


If GCC devs say so, then I presume they are right. But the main purpose of a
warning is to warn the programmer, in this case to avoid some bugs.



 As I said, these kinds of error messages are very annoying when developing
code, 
 for example, when enabling and disabling various sections.


Warnings have a cost. Sometimes they are locally wrong, becoming noise, so in
some situations people want to disable specific warnings locally (GCC 4.6 has
added ways to do this).

In some situations I agree that an error is better than a warning message,
indeed D has turned some C warnings into errors. There are even two D warnings
that I want to become errors:
http://d.puremagic.com/issues/show_bug.cgi?id=3836
http://d.puremagic.com/issues/show_bug.cgi?id=4216

Elsewhere you have explained that different compilers have different warnings,
this combined with the choice of many programmers to see warnings as errors
produces incompatible programs, it means that changing the compiler becomes
almost like changing language (a possible solution I see to this problem is to
standardize most warnings in a language. So most warnings are shared between
compilers of the same language).

Regarding what you say here, I agree that when you develop a part of code you
want a little more local freedom. Because you often have some scaffolding code,
variables, etc, that you use to build the main code. This means that in code
that's work in progress you sometimes have duplicated variables, redundancies,
and several other things that are probably seen as problems by a more strict
compiler.

On the other hand, the amount of code you work in a moment is not large, so the
amount of warnings your program generates is not large (assuming most other
part of the code don't generate warnings or have silenced warnings), so I think
such limited amount of warnings is going to be acceptable. Maybe there is a way
to disable the warnings in just the parts of the program you are working now.
But warnings sometimes are useful, so they may catch bugs you are adding in the
new code you are adding/changing now.

The most part of a largish program is not under change in any moment (even if
many people are working on a program at the same time). And experience has
shown me that unused variables in cold code (code you are not modifying right
now) are sometimes associated with bugs or other troubles (this was also the
main point of that paper by Yichen Xie). And removing them helps make the code
shorter, more tidy. It's worse than leaving useless phrases in a text.



 I get told I'm wrong on just about everything I do.


In D language/compiler I have found many good decisions, most of them are good,
that's why I am here :-) But there are things I don't agree with, and I try to
explain why.


Like that section 3 page 2 "Redundant assignments" on the Yichen Xie paper. In
my code and code written by other people I have seen many times little errors
like this, or several similar variations of it:

class Foo {
  int x, y, z;
  Foo(int x_, int y_, int z_) {
    x = x_;
    y = y;
    z = z_;
  }
...
}


If the lint is able to spot redundant assignments, it shows a warning. A
compiler may even turn redundant assignments into errors. D turns unassigned
pure expressions into errors:

void main() {
    int x = 10;
    int y = 20;
    x + y;
}

test.d(4): Error: + has no effect in expression (x + y)


But currently this gives no errors, despite it's the same situation, so I'd
like an error here too (this enhancement request is in Bugzilla already):

pure int add(int a, int b) { return a + b; }
void main() {
    int x = 10;
    int y = 20;
    add(x, y);
}


In the paper by Yichen Xie you see many other interesting cases, that come from
real world code, it's quite interesting stuff.

Bye,
bearophile
Mar 27 2011
next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article

 Walter:

 You quoted a claim saying it was also an optimization.


 If GCC devs say so, then I presume they are right. But the main purpose of a


warning is to warn the programmer, in this case to avoid some bugs.

Warnings have no effect on optimisations. And unused code are later removed via
general dead code elimination anyway (how aggressive this is depends on the
optimisation level).
Mar 27 2011
prev sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
 test.d(4): Error: + has no effect in expression (x + y)
 But currently this gives no errors, despite it's the same situation, so I'd
like


an error here too (this enhancement request is in Bugzilla already):

 pure int add(int a, int b) { return a + b; }
 void main() {
     int x = 10;
     int y = 20;
     add(x, y);
 }


I think it would be better if it were targeting memory/(re)allocation-related
functions.

ie:
{
  new int[4096];  // allocation has no effect, other than leaking memory.
}
Mar 27 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Iain Buclaw:


 I think it would be better if it were targeting memory/(re)allocation-related
 functions.
 
 ie:
 {
   new int[4096];  // allocation has no effect, other than leaking memory.
 }


(The memory does not leak, the GC will deallocate it later).
In Bugzilla I have proposed that if you call a pure function and you don't
assign its return value, then you have a bug, like the similar present in D for
unassigned expressions.
If the druntime function to allocate a new array is a pure function, then my
enhancement request catches your bug too :-)

Bye,
bearophile
Mar 27 2011
next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Mar 27, 11 22:30, bearophile wrote:

 In Bugzilla I have proposed that if you call a pure function and you don't
assign its return value, then you have a bug, like the similar present in D for
unassigned expressions.


This should be restricted to *strongly* pure functions. Weakly pure 
functions may have its major effect sent out via the input arguments, so 
ignoring the return value could make sense.

   import std.stdio;

   pure double[] set(double[] x, int index, double e) {
     x[index] = e;
     return x;
   }

   void main () {
     auto j = new double[](3);
     j.set(0, 1.5).set(1, 2.5).set(2, 5.1);
     writeln(j);
   }

BTW, which Bugzilla entry you are talking about?
Mar 27 2011
next sibling parent KennyTM~ <kennytm gmail.com> writes:
On Mar 27, 11 23:19, KennyTM~ wrote:

 On Mar 27, 11 22:30, bearophile wrote:

 In Bugzilla I have proposed that if you call a pure function and you
 don't assign its return value, then you have a bug, like the similar
 present in D for unassigned expressions.


 This should be restricted to *strongly* pure functions. Weakly pure
 functions may have its major effect sent out via the input arguments, so
 ignoring the return value could make sense.

 import std.stdio;

 pure double[] set(double[] x, int index, double e) {
 x[index] = e;
 return x;
 }

 void main () {
 auto j = new double[](3);
 j.set(0, 1.5).set(1, 2.5).set(2, 5.1);
 writeln(j);
 }

 BTW, which Bugzilla entry you are talking about?


OK, I see it is 3882.

http://d.puremagic.com/issues/show_bug.cgi?id=3882
Mar 27 2011
prev sibling parent bearophile <bearophileHUGS lycos.com> writes:
KennyTM~:


 This should be restricted to *strongly* pure functions.


Right, I have added the note. I have written the enhancement request 3882
before the introduction of the weakly pure ones.

Bye,
bearophile
Mar 27 2011
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from bearophile (bearophileHUGS lycos.com)'s article

 Iain Buclaw:

 I think it would be better if it were targeting memory/(re)allocation-related
 functions.

 ie:
 {
   new int[4096];  // allocation has no effect, other than leaking memory.
 }


 (The memory does not leak, the GC will deallocate it later).


Assuming you are using the stock implementation that comes bundled with
Druntime,
and not some stub implementation or freestanding environment. :~)
Mar 27 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/27/2011 7:30 AM, bearophile wrote:

 In Bugzilla I have proposed that if you call a pure function and you don't
 assign its return value, then you have a bug, like the similar present in D
 for unassigned expressions.



I think that's a reasonable proposal.
Mar 27 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:


 On 3/27/2011 7:30 AM, bearophile wrote:

 In Bugzilla I have proposed that if you call a pure function and you don't
 assign its return value, then you have a bug, like the similar present in D
 for unassigned expressions.


 
 I think that's a reasonable proposal.


:-) Thank you. This is the enhancement request (about one year old):
http://d.puremagic.com/issues/show_bug.cgi?id=3882

Bye,
bearophile
Mar 27 2011
parent reply Caligo <iteronvexor gmail.com> writes:
I've been doing a lot of coding in D in the past few weeks, and one
thing I've noticed is that performance is not great.  Surprisingly,
DMD generated binaries perform worse than GDC's, but even GDC is
lagging behind equivalent code written in C++ and compiled with G++.
Are we to expect performance to improve as more work is done on GDC?

Another thing that's bothering me is that there is currently only one
active developer working on GDC.
Mar 28 2011
next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
== Quote from Caligo (iteronvexor gmail.com)'s article

 I've been doing a lot of coding in D in the past few weeks, and one
 thing I've noticed is that performance is not great.  Surprisingly,
 DMD generated binaries perform worse than GDC's, but even GDC is
 lagging behind equivalent code written in C++ and compiled with G++.
 Are we to expect performance to improve as more work is done on GDC?


There's a lot going on behind the scenes, so that's hard to say that your code
is
'genuinely equivalent'™.


 Another thing that's bothering me is that there is currently only one
 active developer working on GDC.


:'(
Mar 28 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2011 9:09 AM, Caligo wrote:

 I've been doing a lot of coding in D in the past few weeks, and one
 thing I've noticed is that performance is not great.  Surprisingly,
 DMD generated binaries perform worse than GDC's, but even GDC is
 lagging behind equivalent code written in C++ and compiled with G++.
 Are we to expect performance to improve as more work is done on GDC?


There is no technical reason why performance should be worse. It's a matter of 
investing the time and effort into the code generation.
Mar 28 2011
parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Walter Bright (newshound2 digitalmars.com)'s article

 On 3/28/2011 9:09 AM, Caligo wrote:

 I've been doing a lot of coding in D in the past few weeks, and one
 thing I've noticed is that performance is not great.  Surprisingly,
 DMD generated binaries perform worse than GDC's, but even GDC is
 lagging behind equivalent code written in C++ and compiled with G++.
 Are we to expect performance to improve as more work is done on GDC?


 There is no technical reason why performance should be worse. It's a matter of
 investing the time and effort into the code generation.


Correct me if I'm wrong, but I think some important optimizations (like
inlining)
are performed in the front end.  It's pretty obvious that DMD's inliner needs
improvement, though I agree with Walter's decision to prioritize this below
fixing
major bugs, 64 support and (before that) finalizing the spec.  Therefore, the
performance of GDC is still a quality of implementation issue rather than a
fundamental technical issue.
Mar 28 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2011 11:49 AM, dsimcha wrote:

 Correct me if I'm wrong, but I think some important optimizations (like
inlining)
 are performed in the front end.  It's pretty obvious that DMD's inliner needs
 improvement, though I agree with Walter's decision to prioritize this below
fixing
 major bugs, 64 support and (before that) finalizing the spec.  Therefore, the
 performance of GDC is still a quality of implementation issue rather than a
 fundamental technical issue.


By fundamental technical issue, I mean things like Python's numeric types which 
require runtime testing for every operation, and are very resistant to known 
techniques of optimization.

D's perf problems have known causes that are not faults in the language, but
are 
fixable in the compiler using known techniques. It's just a matter of
priorities 
and manpower.

In fact, D has many attributes that offer the potential for significantly
better 
code generation than C/C++. They've just not been exploited yet.
Mar 28 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:


 By fundamental technical issue, I mean things like Python's numeric types
which 
 require runtime testing for every operation, and are very resistant to known 
 techniques of optimization.


Life is a bit more complex than that:
- The Lua JIT has shown once and for all that dynamic typing is not as bad
(performance-wise) as you think. I have floating-point heavy benchmarks that
run faster in jitted Lua than in D compiled with DMD.
- Python is a language, and there are many ways to run a language. You are able
to interpret D code and to compile Python code. Since several years I am
helping the develpment of ShedSkin, a Python->C++ compiler, that uses powerful
type inferencing to infer all the static types of an implicitly static Python
program. The results are sometimes faster than D programs compiled with DMD,
because they are essentially pretty clean C++ programs compiled by G++.
- Today GPUs are used more and more where the max performance is needed, and
example:
http://www.i-programmer.info/news/105-artificial-intelligence/2176-kinects-ai-breakthrough-explained.html
And you are able to write and run such GPU kernels from Python code too.

Bye,
bearophile
Mar 28 2011
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/28/2011 1:12 PM, bearophile wrote:

 Walter:


 By fundamental technical issue, I mean things like Python's numeric types
 which require runtime testing for every operation, and are very resistant
 to known techniques of optimization.


 Life is a bit more complex than that: - The Lua JIT has shown once and for
 all that dynamic typing is not as bad (performance-wise) as you think.


There's a lot of money and manpower behind Python. If this were true, why
hasn't 
this technology been done for Python?

Secondly, even Lua's proponents (like ilikecakes) says he uses Lua in hybrid 
configurations with C and C++, so there is clearly some sort of deficit with
Lua.



 I have
 floating-point heavy benchmarks that run faster in jitted Lua than in D
 compiled with DMD.


Come on. As has been discussed to death here, dmd's back end does not do 
floating point well, in particular, it does not make use of XMM instructions. 
Any code generator that does will perform better.

And, Python does not have the dynamic typing issue with floats that it does
with 
integers. Jitted floating point Python code *should* match performance with 
statically compiled floating point code.
Mar 28 2011
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:


There's a lot of money and manpower behind Python. If this were true, why
hasn't this technology been done for Python?<


It was done, more than one time. One good JIT was Psyco. And more recently PyPy
is about to surpass Psyco in performance:
http://codespeak.net/pypy/dist/pypy/doc/

But the Lua JIT is quite better than Psyco, its programmer is very intelligent
(Psyco author too is an intelligent programmer, Armin Rigo).

And more importantly, this whole discussion can't be reduced to just a static
Vs dynamic typing. Lua and Python are different languages, Python is probably
more dynamic than Lua, it is quite more powerful than Lua, and it's different.
So creating a really efficient JIT for Python is much harder than doing it for
Lua, and you can't compare them much.

The result is that currently PyPy is generally about 8/10 times slower than D
code, while Lua-Jit is about 2-3 times slower than D compiled well, and
JavaScript running on the V8-CrankShaft JIT is about 3-4 times slower than D.
And Mozilla hopes to someday beat V8, though a local static inferencer
(probably to be seen in Firefox 5? See the "(TypeInference)" here, it's in
development still: http://arewefastyet.com/?a=b&view=regress ).



 Secondly, even Lua's proponents (like ilikecakes) says he uses Lua in hybrid
 configurations with C and C++, so there is clearly some sort of deficit with
Lua.


Lua is a quite simple language, there are some things you can't do well with
it, so you need other languages. And even with a JIT Lua is often not as fast
as good C code. I have never said that Lua+JIT is better than D, I am not much
interested in Lua.



 And, Python does not have the dynamic typing issue with floats that it does
with
 integers. Jitted floating point Python code *should* match performance with
 statically compiled floating point code.


Regarding strictly *dynamic typing* Python floats are as dynamic as Python
integers. You probably mean that Python floats are structs that wrap around CPU
doubles, while Python3 integers are multi-precision ones (Python2 integers are
hybrids).

The fact they are multi-precision is orthogonal to dynamic typing: you are able
to use multi-precision integers in D too (BigInt). Multi-precision integers are
not intrinsically dynamically typed.

Regarding multi-precision integers, CommonLisp, OcaML and Factor languages show
that tagged integers (that become multi-precision when the stack-allocated
fixed ones have an overflow) are not as slow as you think. I have written small
programs in Factor (a modern and quite refined stack-based language), and if
you don't go past the precision of the tagged integers, they don't slow down
the code a lot. Their slowdown is comparable to the difference of runtime
performance of array-heavy D code compiled with and with -release switch.

Bye,
bearophile
Mar 28 2011
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/28/11 4:31 PM, bearophile wrote:

 Walter:


 There's a lot of money and manpower behind Python. If this were true, why
hasn't this technology been done for Python?<


 It was done, more than one time. One good JIT was Psyco. And more recently
PyPy is about to surpass Psyco in performance:
 http://codespeak.net/pypy/dist/pypy/doc/

 But the Lua JIT is quite better than Psyco, its programmer is very intelligent
(Psyco author too is an intelligent programmer, Armin Rigo).

 And more importantly, this whole discussion can't be reduced to just a static
Vs dynamic typing.


To be brutally honest, I'd say that this discussion (and a few others) 
could be reduced to zero.

We have a good list of things we know need to be done, all vying for top 
positions. We're gearing up for a GSoC 2011 program that will be, it 
seems, extremely rewarding but quite taxing for those of us who are 
overseeing the process. This is a good time to stay focused and productive.

Discussions about some or another minutia or comparative merits and 
demerits of various approaches can quickly drown the good content. At 
best this newsgroup would contain a majority of GSoC proposals and 
related discussions, review discussions for the currently proposed 
modules, preliminary design discussions on emerging libraries, progress 
reports, and the such.


Thanks,

Andrei
Mar 28 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Andrei:


 To be brutally honest, I'd say that this discussion (and a few others) 
 could be reduced to zero.


I have suggested the Google Summer of Code for D even the past year, and I
agree it's important for D future. But I think Walter has to know something
about modern JITs & dynamic languages too. I have had bad experiences with
Guido (Python author) that until no more than one or two years ago seemed to
didn't even know what a trampoline stub is, and this has caused some problems.
You have to take care of the knowledge of your Benevolent Dictator For Life, I
want Walter to know lot of things.

Bye,
bearophile
Mar 28 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/28/11 5:47 PM, bearophile wrote:

 Andrei:


 To be brutally honest, I'd say that this discussion (and a few
 others) could be reduced to zero.


 I have suggested the Google Summer of Code for D even the past year,
 and I agree it's important for D future. But I think Walter has to
 know something about modern JITs&  dynamic languages too. I have had
 bad experiences with Guido (Python author) that until no more than
 one or two years ago seemed to didn't even know what a trampoline
 stub is, and this has caused some problems. You have to take care of
 the knowledge of your Benevolent Dictator For Life, I want Walter to
 know lot of things.

 Bye, bearophile


Teaching van Rossum or Bright is a bit assuming. I suggest a simpler 
path - apply the noble goal of knowing a lot of things to yourself, and 
use that expertise to contribute to the community.

Thanks,

Andrei
Mar 28 2011
parent reply jasonw <user webmails.org> writes:
Andrei Alexandrescu Wrote:


 On 3/28/11 5:47 PM, bearophile wrote:

 Andrei:


 To be brutally honest, I'd say that this discussion (and a few
 others) could be reduced to zero.


 I have suggested the Google Summer of Code for D even the past year,
 and I agree it's important for D future. But I think Walter has to
 know something about modern JITs&  dynamic languages too. I have had
 bad experiences with Guido (Python author) that until no more than
 one or two years ago seemed to didn't even know what a trampoline
 stub is, and this has caused some problems. You have to take care of
 the knowledge of your Benevolent Dictator For Life, I want Walter to
 know lot of things.

 Bye, bearophile


 
 Teaching van Rossum or Bright is a bit assuming. I suggest a simpler 
 path - apply the noble goal of knowing a lot of things to yourself, and 
 use that expertise to contribute to the community.


I've managed to keep my mouth shut about non-technical issues until earlier
today. But since I already started, I'd like to stay as constructive as
possible and suggest finding some kind of unified guidelines for technical
discussion.

The reason for this is, I find bearophile's tone a bit annoying more often than
I'd want. This isn't a personal attack, I just wish that there was a better way
for him to interact with the community. Bearophile's actions have already been
criticized several times in the past, but he doesn't seem to respond in any
way. <tasteless>I can't keep wondering if he has Asperger syndrome</tasteless>.
I just want to bring up some remarks about improving the quality of posts and
raising the S/N ratio. Thanks.

Basically what bearophile discusses is: 
 - feature proposals (sometimes useful, more often not)
 - bug reports and fixes
 - optimization tips
 - benchmark results
 - user experience reports
 - links to research papers
 - links to discussion boards (most often reddit)
 - "education"
 - uninformed and totally uncalled-for remarks about personal motives and other
personal things

How we could improve the process is that
1) We stop making "guesses" about the motivations and timetables of community
members.
2) I also hate these "time ago i suggested this feature, and bla bla bla, see

of your bug reports doesn't help in any way. If you're such a rocket scientist,
write some patches instead.
3) We should spent some time learning english and communicating the main idea
with less words. Seriously, if you've been hitting the "post this!!" button for
years, you should consider improving your grammar every now and then. Reading
posts, spanning multiple pages, written in incomprehensible "semi-engrish" is
really boring. I mostly react with "tl;dr".
4) Stop posting so many feature requests. They are often contradictory and just
annoy the key persons.

And finally a reply to the bearophile's:

  You have to take care of
 the knowledge of your Benevolent Dictator For Life, I want Walter to
 know lot of things.




Listen kid, you're some biology student, right? You're just coding for fun. And
more importantly, you haven't participated in any long term real world systems
programming projects. This kind of work experience doesn't give you the
competence to evaluate the knowledge and work of people with tens of years of
programming experience under their belt.

You might be terribly smart, but you're missing the point. Can you see what we
are building here? A whole language ecosystem. Andrei has done great work by
attracting competent CS persons in to the community. The development is
changing. We need to find important persons, organizations, solve project
management issues and all kinds of non-technical stuff now. Some kid posting
yet another daily feature proposal isn't helping us at all. It's distracting
and just plain noise. Can you see this from our POV? I really hope this forum
is getting moderation once the community grows large enough.
Mar 28 2011
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
On 3/28/2011 9:54 PM, jasonw wrote:

 Listen kid, you're some biology student, right? You're just coding for fun.
And more importantly, you haven't participated in any long term real world
systems programming projects. This kind of work experience doesn't give you the
competence to evaluate the knowledge and work of people with tens of years of
programming experience under their belt.

 You might be terribly smart, but you're missing the point. Can you see what we
are building here? A whole language ecosystem. Andrei has done great work by
attracting competent CS persons in to the community.


While I think some good points were raised here, I find the implication 
that biologists and generally non-CS people can't do first rate 
programming mildly offensive.  Formal education in CS helps especially 
when doing CS research, but it's not a requirement for being a "real" 
programmer.  I'm a biomedical engineering student and primarily write 
research and hobby code, not industrial code.  Walter's degree is in 
mechanical engineering and he's one of the best programmers I can think 
of.  Heck, even Andrei didn't have a formal degree in CS until recently. 
  (His undergrad, IIRC, is in electrical engineering.)

That said, I think bearophile's posts are well-intentioned.  The problem 
is that the signal-to-noise is terrible.  What D needs now is bug fixing 
of what's already there and solid implementations of basic stuff like 
database APIs, better garbage collection, IDEs, etc.  Bringing up the 
latest cool idea is fine if you've also got an implementation or it's 
exceptionally well thought out and solves a severe, pressing problem. 
The constant bombardment with ideas to solve minor or niche problems, 
with no implementation and no intention of creating an implementation, 
is more distracting than useful.
Mar 28 2011
next sibling parent jasonw <user webmails.org> writes:
dsimcha Wrote:


 On 3/28/2011 9:54 PM, jasonw wrote:

 Listen kid, you're some biology student, right? You're just coding for fun.
And more importantly, you haven't participated in any long term real world
systems programming projects. This kind of work experience doesn't give you the
competence to evaluate the knowledge and work of people with tens of years of
programming experience under their belt.

 You might be terribly smart, but you're missing the point. Can you see what we
are building here? A whole language ecosystem. Andrei has done great work by
attracting competent CS persons in to the community.


 
 While I think some good points were raised here, I find the implication 
 that biologists and generally non-CS people can't do first rate 
 programming mildly offensive.  Formal education in CS helps especially 
 when doing CS research, but it's not a requirement for being a "real" 
 programmer.  I'm a biomedical engineering student and primarily write 
 research and hobby code, not industrial code.  Walter's degree is in 
 mechanical engineering and he's one of the best programmers I can think 
 of.  Heck, even Andrei didn't have a formal degree in CS until recently. 
   (His undergrad, IIRC, is in electrical engineering.)


Didn't want to give that kind of impression. I think "computer engineering"
graduates often have a much better view of the software industry than pure
computer science graduates. Non-CS people can also be great developers, no
doubt.

I wanted to point out that bearophile tries to act like a main architect of the
D language. I'm overall impressed how well he handles the theoretical side, but
the price is that the ideas are always presented like from an ivory tower.
Concrete compiler / library patches and better relevance to real "simple"
everyday problems would help a lot more. I'll mention one concrete example:
typestates. While I think this idea is interesting, I really can't trust
bearophile if I want to know if it's a good feature to have and testing it
would require studying some small unpopular language (Rust). I don't think the
main branch of D is a suitable target for experimenting with this kind of
features. If he wants to use them, he could fork D and come back with concrete
results.


 
 That said, I think bearophile's posts are well-intentioned.  The problem 
 is that the signal-to-noise is terrible.  What D needs now is bug fixing 
 of what's already there and solid implementations of basic stuff like 
 database APIs, better garbage collection, IDEs, etc.  Bringing up the 
 latest cool idea is fine if you've also got an implementation or it's 
 exceptionally well thought out and solves a severe, pressing problem. 
 The constant bombardment with ideas to solve minor or niche problems, 
 with no implementation and no intention of creating an implementation, 
 is more distracting than useful.


I fully agree with this, but just wanted to bring this up because in my opinion
he is wasting a lot of time trying to emphasize things which have been noted,
but are on the bottom of the current priority list. I don't want to discourage
him from posting, but he should also consider the reactions of the audience a
bit.
Mar 28 2011
prev sibling parent reply Don <nospam nospam.com> writes:
dsimcha wrote:

 On 3/28/2011 9:54 PM, jasonw wrote:

 Listen kid, you're some biology student, right? You're just coding for 
 fun. And more importantly, you haven't participated in any long term 
 real world systems programming projects. This kind of work experience 
 doesn't give you the competence to evaluate the knowledge and work of 
 people with tens of years of programming experience under their belt.

 You might be terribly smart, but you're missing the point. Can you see 
 what we are building here? A whole language ecosystem. Andrei has done 
 great work by attracting competent CS persons in to the community.


 
 While I think some good points were raised here, I find the implication 
 that biologists and generally non-CS people can't do first rate 
 programming mildly offensive.  Formal education in CS helps especially 
 when doing CS research, but it's not a requirement for being a "real" 
 programmer.  I'm a biomedical engineering student and primarily write 
 research and hobby code, not industrial code.  Walter's degree is in 
 mechanical engineering and he's one of the best programmers I can think 
 of.  Heck, even Andrei didn't have a formal degree in CS until recently. 
  (His undergrad, IIRC, is in electrical engineering.)


I have a physics degree, and have worked in solar photovoltaics for 
fifteen years.
Mar 28 2011
next sibling parent spir <denis.spir gmail.com> writes:
On 03/29/2011 07:47 AM, Don wrote:

 dsimcha wrote:

 On 3/28/2011 9:54 PM, jasonw wrote:

 Listen kid, you're some biology student, right? You're just coding for fun.
 And more importantly, you haven't participated in any long term real world
 systems programming projects. This kind of work experience doesn't give you
 the competence to evaluate the knowledge and work of people with tens of
 years of programming experience under their belt.

 You might be terribly smart, but you're missing the point. Can you see what
 we are building here? A whole language ecosystem. Andrei has done great work
 by attracting competent CS persons in to the community.


 While I think some good points were raised here, I find the implication that
 biologists and generally non-CS people can't do first rate programming mildly
 offensive. Formal education in CS helps especially when doing CS research,
 but it's not a requirement for being a "real" programmer. I'm a biomedical
 engineering student and primarily write research and hobby code, not
 industrial code. Walter's degree is in mechanical engineering and he's one of
 the best programmers I can think of. Heck, even Andrei didn't have a formal
 degree in CS until recently. (His undergrad, IIRC, is in electrical
 engineering.)


 I have a physics degree, and have worked in solar photovoltaics for fifteen
years.


I have a degree in "technical training" (dunno proper english term, if any), 
specialised in automation. Seems I'm the closer one to CS/programming here ;-) 
(while in a highly specialised area) But certainly one of the least competent 
in those fields :-( Learning every day, though.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Mar 29 2011
prev sibling parent dsimcha <dsimcha yahoo.com> writes:
== Quote from Don (nospam nospam.com)'s article

 dsimcha wrote:

 On 3/28/2011 9:54 PM, jasonw wrote:

 Listen kid, you're some biology student, right? You're just coding for
 fun. And more importantly, you haven't participated in any long term
 real world systems programming projects. This kind of work experience
 doesn't give you the competence to evaluate the knowledge and work of
 people with tens of years of programming experience under their belt.

 You might be terribly smart, but you're missing the point. Can you see
 what we are building here? A whole language ecosystem. Andrei has done
 great work by attracting competent CS persons in to the community.


 While I think some good points were raised here, I find the implication
 that biologists and generally non-CS people can't do first rate
 programming mildly offensive.  Formal education in CS helps especially
 when doing CS research, but it's not a requirement for being a "real"
 programmer.  I'm a biomedical engineering student and primarily write
 research and hobby code, not industrial code.  Walter's degree is in
 mechanical engineering and he's one of the best programmers I can think
 of.  Heck, even Andrei didn't have a formal degree in CS until recently.
  (His undergrad, IIRC, is in electrical engineering.)


 I have a physics degree, and have worked in solar photovoltaics for
 fifteen years.


I'd have put you in my original post, too if I had known more detail about your
background.  Generally I think having non-CS people heavily involved in D's
design
helps immensely rather than hurting.  CS people are great when you need
something
with strong theoretical underpinnings, but some things require a different, more
real-world implementation and use case oriented mindset.  I'm not saying CS
people
**can't** think this way, just that it's not the primary way they're **trained**
to think.  Having people with natural science and engineering backgrounds
involved
prevents D from becoming too ivory-tower.  I also think it's a positive feedback
loop:  D refuses to compromise practicality to satisfy the Higher Principles of
Computer Science, thus it attracts scientists and engineers who are more
interested in practicality than the Higher Principles of Computer Science.

Ironically, this branch started with a discussion about Bearophile's posts and
despite his biology background I find most of them too ivory-tower.
Mar 29 2011
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 28 Mar 2011 21:54:27 -0400, jasonw <user webmails.org> wrote:


 <tasteless>I can't keep wondering if he has Asperger  
 syndrome</tasteless>.


I have no tolerance for this.  I think the community shares this opinion.   
Please please, instead of tagging stuff like this, just remove it.

Thanks

-Steve
Mar 29 2011
prev sibling parent reply so <so so.so> writes:
 Listen kid, you're some biology student, right? You're just coding for  
 fun. And more importantly, you haven't participated in any long term  
 real world systems programming projects. This kind of work experience  
 doesn't give you the competence to evaluate the knowledge and work of  
 people with tens of years of programming experience under their belt.

 You might be terribly smart, but you're missing the point. Can you see  
 what we are building here? A whole language ecosystem. Andrei has done  
 great work by attracting competent CS persons in to the community. The  
 development is changing. We need to find important persons,  
 organizations, solve project management issues and all kinds of  
 non-technical stuff now. Some kid posting yet another daily feature  
 proposal isn't helping us at all. It's distracting and just plain noise.  
 Can you see this from our POV? I really hope this forum is getting  
 moderation once the community grows large enough.


I find his posts among the most informative.
As you also pointed out, he is doing a lot. Still, if one doesn't like it  
he can always ignore.

On another note: I just hope this language never gets matured in the sense  
you are suggesting and the community improves it in every opportunity. To  
make this even more possible we need language features that ease (or make  
possible) the development of library solutions.
Mar 29 2011
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/29/11 4:37 PM, so wrote:
[snip]

 I find his posts among the most informative.


I don't meant to offend anyone here but I think it's worth making a 
point for your benefit and others'. If you are interested in programming 
language theory, probably there are better sources of information to 
use. Though I don't consider myself anywhere near an expert, my masters 
thesis was on programming language theory, which gives me some amount of 
perspective. "Cargo culture" would be a gross exaggeration, but much of 
the knowledge disseminated by bearophile is superficially absorbed 
literature that is served back semi-digested along with a hodge-podge of 
personal opinions of various degrees of correctness.

The only reason I felt compelled to make this point is the (now obvious) 
risk in taking such posts as a good source of information. It is is 
dangerous to take non-critically the occasional enormity that sneaks in. 
That's why I suggested in the past and am suggesting it again - please 
don't feign expertise as some may actually fall for it.

I have no doubt great personal improvement has been made in the past 
years, but the tone is still an octave above what it could be at its best.


Thanks,

Andrei
Mar 29 2011
parent so <so so.so> writes:
On Wed, 30 Mar 2011 02:04:04 +0300, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 On 3/29/11 4:37 PM, so wrote:
 [snip]

 I find his posts among the most informative.


 I don't meant to offend anyone here but I think it's worth making a  
 point for your benefit and others'. If you are interested in programming  
 language theory, probably there are better sources of information to  
 use. Though I don't consider myself anywhere near an expert, my masters  
 thesis was on programming language theory, which gives me some amount of  
 perspective. "Cargo culture" would be a gross exaggeration, but much of  
 the knowledge disseminated by bearophile is superficially absorbed  
 literature that is served back semi-digested along with a hodge-podge of  
 personal opinions of various degrees of correctness.

 The only reason I felt compelled to make this point is the (now obvious)  
 risk in taking such posts as a good source of information. It is is  
 dangerous to take non-critically the occasional enormity that sneaks in.  
 That's why I suggested in the past and am suggesting it again - please  
 don't feign expertise as some may actually fall for it.

 I have no doubt great personal improvement has been made in the past  
 years, but the tone is still an octave above what it could be at its  
 best.


 Thanks,

 Andrei


Probably i misused the word informative, what i meant was he occasionally  
brings up topics that i wasn't aware of and quite possibly i wouldn't even  
if i try to browse some PL related sites. They tend to be biased on  
certain languages and paradigms which leads to an hostility towards some  
ideas. I would be the last one on earth that would buy something because  
of a commercial, it is just a starting point.
Mar 29 2011
prev sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Mon, 2011-03-28 at 17:31 -0400, bearophile wrote:

 Walter:
=20

There's a lot of money and manpower behind Python. If this were true,


 why hasn't this technology been done for Python?<


It has been and is being.  The problem is complicated by the GIL, so it
is not a simple situation.


 It was done, more than one time. One good JIT was Psyco. And more
 recently PyPy is about to surpass Psyco in performance:
 http://codespeak.net/pypy/dist/pypy/doc/


And there was Unladen Swallow which was a Google funded project to add a
JIT to CPython 2.6.  It failed to meet it's goals.  However the results
will nonetheless filter into CPython 3.2 or 3.3.


 But the Lua JIT is quite better than Psyco, its programmer is very
 intelligent (Psyco author too is an intelligent programmer, Armin
 Rigo).


The Lua JIT can hardly be compared to something for Python since the
underlying VMs are totally different -- as you point out below..  What
can be said is that the Lua JIT works very well for Lua, whilst there is
no production quality equivalent for Python as yet.=20


 And more importantly, this whole discussion can't be reduced to just a
 static Vs dynamic typing. Lua and Python are different languages,
 Python is probably more dynamic than Lua, it is quite more powerful
 than Lua, and it's different. So creating a really efficient JIT for
 Python is much harder than doing it for Lua, and you can't compare
 them much.


Indeed.


 The result is that currently PyPy is generally about 8/10 times slower
 than D code, while Lua-Jit is about 2-3 times slower than D compiled
 well, and JavaScript running on the V8-CrankShaft JIT is about 3-4
 times slower than D. And Mozilla hopes to someday beat V8, though a
 local static inferencer (probably to be seen in Firefox 5? See the
 "(TypeInference)" here, it's in development still:
 http://arewefastyet.com/?a=3Db&view=3Dregress ).


Sadly PyPy is still only implementing CPython 2.5 which is a
significantly worse barrier than any speed issues.


 Lua is a quite simple language, there are some things you can't do
 well with it, so you need other languages. And even with a JIT Lua is
 often not as fast as good C code. I have never said that Lua+JIT is
 better than D, I am not much interested in Lua.


Which leads to the real point as to why Python is becoming the leading
language for scientific computing, it is a dynamic language for
coordinating C/C++/Fortran computations and providing GUI front ends.
Performance of Python is thus a side issue since grunt computation is
done in languages which are closer to the machine -- with all the crap
that entails.

I know, Python, and indeed Lua, are used for plugins to big C/C++
systems as well.  Here is is to provide the dynamic partner to a static
system.  This exactly how Groovy works with Java.  The nature of the
modern world is a symbiosis of languages not trying to do everything
with one.

<...stuff on floating point representations elided...>

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Mar 29 2011
parent dsimcha <dsimcha yahoo.com> writes:
On 3/29/2011 3:00 AM, Russel Winder wrote:

 Which leads to the real point as to why Python is becoming the leading
 language for scientific computing, it is a dynamic language for
 coordinating C/C++/Fortran computations and providing GUI front ends.
 Performance of Python is thus a side issue since grunt computation is
 done in languages which are closer to the machine -- with all the crap
 that entails.


The problem with this is when you're the poor bastard that has to write 
said C/C++/Fortran code, or when you want to pass complex object graphs 
between the languages.
Mar 29 2011
prev sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Mar 29, 11 04:33, Walter Bright wrote:

 On 3/28/2011 1:12 PM, bearophile wrote:

 Walter:


 By fundamental technical issue, I mean things like Python's numeric
 types
 which require runtime testing for every operation, and are very
 resistant
 to known techniques of optimization.


 Life is a bit more complex than that: - The Lua JIT has shown once and
 for
 all that dynamic typing is not as bad (performance-wise) as you think.


 There's a lot of money and manpower behind Python. If this were true,
 why hasn't this technology been done for Python?


Psyco? (http://psyco.sourceforge.net/, though it seems to be stuck at 2.6)

PyPy also supports JITting 
(http://codespeak.net/pypy/dist/pypy/doc/jit/index.html)


 Secondly, even Lua's proponents (like ilikecakes) says he uses Lua in
 hybrid configurations with C and C++, so there is clearly some sort of
 deficit with Lua.
Mar 28 2011
parent Russel Winder <russel russel.org.uk> writes:
On Tue, 2011-03-29 at 05:41 +0800, KennyTM~ wrote:
[ . . . ]

 Psyco? (http://psyco.sourceforge.net/, though it seems to be stuck at 2.6=


)

If I remember correctly the author of Psyco explicitly stopped work on
it exactly because he moved to doing the JIT for PyPy . . .=20


 PyPy also supports JITting=20
 (http://codespeak.net/pypy/dist/pypy/doc/jit/index.html)


. . . which has the problem of being Python 2.5 instead of Python 2.7 or
3.2 :-((

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder ekiga.n=
et
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
Mar 29 2011
prev sibling parent Caligo <iteronvexor gmail.com> writes:
GCC 4.7 Stage 1 has begun.  Does anyone know if GDC is schedule for inclusion?
Mar 26 2011
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
 But not this:


Sorry, I meant: "But not this yet" :-)

Bye,
bearophile
Mar 26 2011
prev sibling parent reply jasonw <user webmails.org> writes:
Andrei Alexandrescu Wrote:


 On 3/29/11 4:37 PM, so wrote:
 [snip]

 I find his posts among the most informative.


 
 I don't meant to offend anyone here but I think it's worth making a 
 point for your benefit and others'. If you are interested in programming 
 language theory, probably there are better sources of information to 
 use. Though I don't consider myself anywhere near an expert, my masters 
 thesis was on programming language theory, which gives me some amount of 
 perspective. "Cargo culture" would be a gross exaggeration, but much of 
 the knowledge disseminated by bearophile is superficially absorbed 
 literature that is served back semi-digested along with a hodge-podge of 
 personal opinions of various degrees of correctness.
 
 The only reason I felt compelled to make this point is the (now obvious) 
 risk in taking such posts as a good source of information. It is is 
 dangerous to take non-critically the occasional enormity that sneaks in. 
 That's why I suggested in the past and am suggesting it again - please 
 don't feign expertise as some may actually fall for it.


You hit the nail on the head here. I see two real problems with his messages:

1) he's "force fitting" every possible language feature he learns into D.
Clearly some features are useful, others are not, and this is why many of
bearophile's ideas fail and generate endless debates and unnecessary noise. He
can't see that the features just don't fit in.

If you lack the vision of good language design as a whole, you shouldn't start
suggesting new features like this. I'd appreciate it more if we won't introduce
"new" concepts in this way. If some feature X is terribly useful in some
language Y, why not explain the feature in that concept. It's a total failure
to port every possible feature to D in one way or another before even
discussing the feature in general. If we start talking programming language
discussion in a neutral tone, I don't think digitalmars.d is the best place to
continue. The traffic is already quite large for someone who doesn't work in
the core language development team

2) Programming language design requires rigorous definition of terms and other
things. The D community doesn't encourage using precise, well-defined, unique
terms. This leads to some subtleties and other problems in the discussions.
Again I think the best place for general PL discussion is somewhere else,
preferable in the academia. I'm sorry to say this, but I likely need to study
how to put him in the kill file. The whole bearophile phenomenon takes place on
an isolated island somewhere in the dark corners of D's history. The bug
reports and benchmarks are priceless, but these "lectures" about other language
often aren't.


 
 I have no doubt great personal improvement has been made in the past 
 years, but the tone is still an octave above what it could be at its best.


That's true, but it's also a bad sign that he doesn't react in any way when we
are criticizing him in the public.
Mar 30 2011
parent reply so <so so.so> writes:
On Thu, 31 Mar 2011 05:09:44 +0300, jasonw <user webmails.org> wrote:


 You hit the nail on the head here. I see two real problems with his  
 messages:

 1) he's "force fitting" every possible language feature he learns into  
 D. Clearly some features are useful, others are not, and this is why  
 many of bearophile's ideas fail and generate endless debates and  
 unnecessary noise. He can't see that the features just don't fit in.


This is not true, there are ideas here from many others as well that  
generate endless debates.
The reason is as far as i can see not always the ideas "just don't fit  
in". The reasons IMO are the chain of command and the resources.
Take the last long discussion on named arguments, i don't think anyone was  
against it.
One another thing is that a few of us evasive to some questions.


 If you lack the vision of good language design as a whole, you shouldn't  
 start suggesting new features like this. I'd appreciate it more if we  
 won't introduce "new" concepts in this way.


This is oxymoron, by that logic there is not a single soul on earth with  
that vision.
You just dismissed whole academia, isn't this the way it operates?
Don't you think this is harmful? Why does D2 exist? D1 wasn't enough?


 2) Programming language design requires rigorous definition of terms and  
 other things. The D community doesn't encourage using precise,  
 well-defined, unique terms. This leads to some subtleties and other  
 problems in the discussions. Again I think the best place for general PL  
 discussion is somewhere else, preferable in the academia. I'm sorry to  
 say this, but I likely need to study how to put him in the kill file.  
 The whole bearophile phenomenon takes place on an isolated island  
 somewhere in the dark corners of D's history. The bug reports and  
 benchmarks are priceless, but these "lectures" about other language  
 often aren't.


I agree he should slow down proposing, at the same time people better stop  
ad hominem attacks.
If it is way to go, we all need to shut up.
Mar 31 2011
parent reply Christopher Bergqvist <spambox0 digitalpoetry.se> writes:
Why not split this NG in two?
d-pragmatism - Concrete stuff, TDPL + absolutely necessary adjustments
which are probably discussed first in the other ng...
d-theory - A place to discuss the future of D, stuff with a longer timeline.

Or maybe we should accept this NG for being a mix of both and that at
least d-announce is d-pragmatism condensed, kind of.

On Thu, Mar 31, 2011 at 10:26 AM, so <so so.so> wrote:

 On Thu, 31 Mar 2011 05:09:44 +0300, jasonw <user webmails.org> wrote:


 You hit the nail on the head here. I see two real problems with his
 messages:

 1) he's "force fitting" every possible language feature he learns into D.
 Clearly some features are useful, others are not, and this is why many of
 bearophile's ideas fail and generate endless debates and unnecessary noise.
 He can't see that the features just don't fit in.


 This is not true, there are ideas here from many others as well that
 generate endless debates.
 The reason is as far as i can see not always the ideas "just don't fit in".
 The reasons IMO are the chain of command and the resources.
 Take the last long discussion on named arguments, i don't think anyone was
 against it.
 One another thing is that a few of us evasive to some questions.


 If you lack the vision of good language design as a whole, you shouldn't
 start suggesting new features like this. I'd appreciate it more if we won't
 introduce "new" concepts in this way.


 This is oxymoron, by that logic there is not a single soul on earth with
 that vision.
 You just dismissed whole academia, isn't this the way it operates?
 Don't you think this is harmful? Why does D2 exist? D1 wasn't enough?


 2) Programming language design requires rigorous definition of terms and
 other things. The D community doesn't encourage using precise, well-defined,
 unique terms. This leads to some subtleties and other problems in the
 discussions. Again I think the best place for general PL discussion is
 somewhere else, preferable in the academia. I'm sorry to say this, but I
 likely need to study how to put him in the kill file. The whole bearophile
 phenomenon takes place on an isolated island somewhere in the dark corners
 of D's history. The bug reports and benchmarks are priceless, but these
 "lectures" about other language often aren't.


 I agree he should slow down proposing, at the same time people better stop
 ad hominem attacks.
 If it is way to go, we all need to shut up.
Mar 31 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Christopher Bergqvist:


 Why not split this NG in two?
 d-pragmatism - Concrete stuff, TDPL + absolutely necessary adjustments
 which are probably discussed first in the other ng...
 d-theory - A place to discuss the future of D, stuff with a longer timeline.
 
 Or maybe we should accept this NG for being a mix of both and that at
 least d-announce is d-pragmatism condensed, kind of.


I am against a further NG split, I have explained why in another post. But here
are some more comments.

On one hand online groups of people that work to develop some software need
some discipline and organization of their work, to improve their productivity.

On the other hand it's all voluntary service, most people don't get paid to
help D development, so they _can't_ be managed as employed people, especially
in a public forum designed for generic discussions about a language.

Some people are more interested in coding a lot, other people are more
interested in talking and ideas, and so on. If such desires aren't respected,
some people may just decrease their interest in the community, if not leave.
And given the small size of this group, this is bad.

This is why I have said those discussions are not eating away lot of coding
time that's usable for Phobos and GSoC: because some people are not interested
in writing lot of Phobos code or doing GSoC, so if they get shut up, the total
coding time/mind share for Phobos/GSoC don't increase significantly.

And from what I have seen on myself (I have written more than 100_000 lines of
D1 code), even people that do want to write lot of code don't waste a lot of
"coding time" on the discussions, because their brain needs rest once in a
while while they write down code. Writing down some answers about ideas doesn't
reduce a lot the time they spend coding.

That said, now work on the already designed/planned features, on Phobos and on
GSoC is more important than inventing new language features for D3. Still the
group must keep being friendly toward people that want to talk about more
general things. There are already groups focused on DMD development, Phobos,
etc.

Bye,
bearophile
Mar 31 2011
next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 01/04/2011 01:50, bearophile wrote:

 On the other hand it's all voluntary service, most people don't get paid to
help D development, so they_can't_  be managed as employed people, especially
in a public forum designed for generic discussions about a language.

 Some people are more interested in coding a lot, other people are more
interested in talking and ideas, and so on. If such desires aren't respected,
some people may just decrease their interest in the community, if not leave.
And given the small size of this group, this is bad.


Frankly, (and regardless of how small our group may be) if the people 
leaving the community would be of those "more interested in talking and 
ideas" than "coding a lot", I don't think it would be bad at all.

-- 
Bruno Medeiros - Software Engineer
Apr 07 2011
parent so <so so.so> writes:
On Thu, 07 Apr 2011 23:45:54 +0300, Bruno Medeiros  
<brunodomedeiros+spam com.gmail> wrote:


 On 01/04/2011 01:50, bearophile wrote:

 On the other hand it's all voluntary service, most people don't get  
 paid to help D development, so they_can't_  be managed as employed  
 people, especially in a public forum designed for generic discussions  
 about a language.

 Some people are more interested in coding a lot, other people are more  
 interested in talking and ideas, and so on. If such desires aren't  
 respected, some people may just decrease their interest in the  
 community, if not leave. And given the small size of this group, this  
 is bad.


 Frankly, (and regardless of how small our group may be) if the people  
 leaving the community would be of those "more interested in talking and  
 ideas" than "coding a lot", I don't think it would be bad at all.


You could have as well signed it - Flat Earth Society
Apr 08 2011
prev sibling parent reply Matthias Pleh <jens konrad.net> writes:
Am 01.04.2011 02:50, schrieb bearophile:

 inventing new language features for D3


Why do you always mention D3.

version.
I'm satisfied with D2, and let's improve it in quality not in quantity 
of features.


just my 2 cents
°Matthias
Apr 07 2011
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 07 Apr 2011 18:46:06 -0400, Matthias Pleh <jens konrad.net> wrote:


 Am 01.04.2011 02:50, schrieb bearophile:

 inventing new language features for D3


 Why do you always mention D3.

 version.
 I'm satisfied with D2, and let's improve it in quality not in quantity  
 of features.


D2 is essentially feature-frozen.  Very little can change in terms of the  
language.  D3 is the logical place to put radical new feature ideas.  It  
has nothing to do with a schedule, it has to do with what version of the  
language has the ability to accept bearophile's pythonesque ideas ;)

-Steve
Apr 08 2011