Re: Code speed

2010-04-16 Thread Don

Ary Borenszweig wrote:

Don wrote:

Ary Borenszweig wrote:

Don wrote:

Lars T. Kyllingstad wrote:

Don wrote:

bearophile wrote:

So far I've just given a light reading of the code. Notes:


- pow(x, 2) and sqrt(y) can be written as x ^^ 2 and y ^^ 0.5 
(but you have to import std.math anyway, because of a bug).


That's not a bug. It's intentional. x ^^ y will probably always 
require import std.math, if y is a floating point number.


Really?  Why is that?  I find that kind of disappointing, I always 
believed it to be a temporary solution.


I think the inconsistency with the other operators will make this a 
major WTF for people new to the language.  Why should a^^b require 
an explicit import while a*b doesn't?


Because pow() for floating point, when implemented properly, is a 
HUGE function, that ends up dragging almost all of std.math into the 
executable. And I think it's deceptive to do that silently.
To make it completely built-in, basically all of std.math would need 
to be moved into druntime. Feel free to try to change my mind, of 
course.


Is there a better way to do pow() for floating point numbers without 
importing std.math?


I see this:

1. You want to do x ^^ fp.
2. The compiler complains saying if you want to do that, import 
std.math. I'm telling you this just to let you know you'll be 
importing the whole module.


Alternative 1 for user:
User says Ok, I import std.math

Alternative 2 for user:
User says No way I'm importing std.math just to make a pow. But... I 
still *need* to make that pow... what is your advice, mr. compiler?


That's a good point, it should be possible to use a static import as 
well. I do think it's pretty odd to be doing floating point without 
importing std.math, though. I mean, abs() is absolutely fundamental.


But if you do a static import the whole module gets linked in, right?

My point is, if you are going to pow, you will need std.math, so it'll 
always be a burden to import it by hand when using it. ^^


But you're assuming that you're using ^^ without using anything else 
from std.math. I think that's a very obscure case.
For example, any code which is ported from C or C++, or D1, that uses 
pow, will already be importing std.math. Cases where you see that you 
could use ^^ that isn't already using pow() (eg, where you see z = x*x + 
y*y), you will need to add an import.




Re: Code speed (and back to the memory leaks...)

2010-04-16 Thread Joseph Wakeling
bearophile wrote:
 You are right, sorry.

No need to apologise!  You helped me significantly improve my code,
helped me understand D a lot better and left me feeling generally very
positive about developing further in D.  I'd call that a result. :-)

 So I think it's probably just compiler difference that's to blame for speed 
 differences
 
 This can be true, but such differences are not magic, they can be found, and 
 eventually they can even become precise enhancement requests for llvm 
 developers, they are open to such requests.

I hope my questions here have been useful in this respect ...

 After all, D in general and DMD in particular is in development.
 
 DMD has a quite old back-end that is not in active development. Maybe it will 
 become 64 bit.

The DMD backend seems a generally problematic piece of code given the
proprietary restrictions that apply to it.  I have the impression that
it's being used simply because it's the backend that is known and tested
and that over the longer term there may be a switch ... ?

The one compiler-related concern I have is whether there will be an
effective free-as-in-freedom compiler for D2 in the near future.  Work
is going on GDC but it's moving slowly -- and I don't see a clear LDC
roadmap to D2 support.

 In this program I have seen that a good percentage of the speed difference 
 between ldc/dmd is caused by foreach loops. When you iterate over structs 
 longer than size_t use ref (or in D2 better ref const(...)).
 foreach (Rating r; ratings)
 ==
 foreach (ref const(Rating) r; ratings)
 
 There is nothing algorithmically strange going on here, but to be sure you 
 can take a look at the produced asm.

Interesting ... !  I'm afraid the asm is over my head, but I will read
up and try to understand it.

 To find why the C++ code is faster you can show me the equivalent C++
 code that I can compile myself, or you can compile your C++ code and
 show me the asm of the two functions that are hot spots.

Sure -- attached.  The key functions are the ones in tref.cpp (the
smalltref class) and trefsim.cpp, and the treftest.cpp file that runs a
roughly-equivalent simulation to test.d.

It's a little embarrassing to share because it's fairly badly-designed
code -- my first serious C++ attempt -- it served its purpose some time
ago and was done with.  It started to become vaguely relevant again so I
thought I'd try and redo it with a better design, and rather than do it
in C++ (which I could do much better by now) this seemed like a nice
excuse to build my first D project ... :-)

I already made a couple of tweaks based on your improvements to the D
code, but I think g++ probably already has such optimizations during the
compile process.

I also realised that I wasn't comparing like with like -- the code was
using the RanLux random number generator, and with mt19937 it shaves
quite a bit of time off.  So C++ still has a bit of an edge right now.

There's surely a lot of other stuff that can be done to improve this
C++, but please don't put lots of effort in unless it helps with
improving D (the language and/or frontend, not my code, which is not so
important:-).

Thanks  best wishes,

-- Joe
#ifndef __TREF_HPP__
#define __TREF_HPP__

#include vector

typedef long unsigned int objectID;
typedef long unsigned int userID;

namespace tref
{

class rating {
public:
	objectID o;
	userID u;
	double value;
	rating(objectID _o, userID _u, double _value);
};

// class __tref
// Base class for all iterative refinement algorithms.
// Contains only minimally needed info and functions.
class __tref {
protected:
	bool verbose;
	std::vectortref::rating ratings;
	std::vectordouble quality;
	std::vectordouble weight;
	double beta;
	double epsilon;
	double convergence;
	virtual void addLink(objectID o, userID u);
	virtual void iterationInit();
	virtual double qualityUpdate();
	virtual void weightUpdate();
public:
	__tref(long unsigned int _objects, long unsigned int _users, long unsigned int _links,
	   double _beta, double _epsilon, double _convergence,
	   bool _verbose);
	void addRating(objectID o, userID u, double value);
	unsigned int iterationCycle();
	long unsigned int objects();
	long unsigned int users();
	long unsigned int links();
	double objectQuality(objectID o);
	double userWeight(userID u);
	void printRatings();
};

// class smalltref : public __tref
// Memory-efficient but slow algorithm.
class smalltref : public __tref {
protected:
	std::vectordouble qualityLast;
	std::vectordouble weightSum;
	std::vectorunsigned long int userLinks;
	virtual void addLink(objectID o, userID u);
	virtual double qualityUpdate();
	virtual void weightUpdate();
public:
	smalltref(long unsigned int _objects, long unsigned int _users, long unsigned int _links,
	  double _beta, double _epsilon, double _convergence,
	  bool _verbose);
};

// class bigtref : public __tref
// Supposedly faster algorithm, but needs more memory.
// Extra allocation required may actually 

Re: Code speed

2010-04-16 Thread Ary Borenszweig

bearophile wrote:

Ary Borenszweig:
My point is, if you are going to pow, you will need std.math, so it'll 
always be a burden to import it by hand when using it. ^^


Can the automatic import happen only iff a module uses the ^^fp?

Bye,
bearophile


That's what I'm asking for.


Newsgroups, off-topic

2010-04-16 Thread eles
Hello,

 I just started using D (2.0). I have three or four questions:

 1) How to use the newsgroup link (e.g. news://news.digitalmars.com/
digitalmars.D.learn) to read the newsgroup? Is the news://; protocol handled
by some program under Linux (Ubuntu, 64)? I write this using the HTTP interface
(e.g. http://www.digitalmars.com/pnews/indexing.php?
server=news.digitalmars.comgroup=digitalmars.D) which is not very pleasant.
COuld we, at least, have an interface like the one used by archives? (e.g.
http://www.digitalmars.com/d/archives/digitalmars/D/
Re_value_range_propagation_for_bitwise_OR_108807.html)? And a SEARCH button?

 2) What is the status of complex numbers in D2? Is stated that module
std.complex will replace the built-in types cfloat, cdouble, creal, ifloat,
idouble, and ireal. When and... how?

 2a) Why the following program has the following output?

 import std.stdio;
real x;
ireal y;
creal z;

int main(){
x=3;
y=5i;
z=x+y;
writefln(x=%f,x);
writefln(y=%f,y);
writefln(z=%f,z);
return 0;
}
=
x=3.00
y=5.00
z=3.00+5.00i

Since y is an ireal number, I would have expected to be written as 5.00i,
not 5.00. This is even more confussing as %f formatting seems to handle
well creal numbers, but not ireal ones.


 3) When DMD for Linux will be 64-bit, too? (Now it works, with multilib).
However, it is a nuisance to install multilib.

 Thanks everybody.

 Eles





Re: Newsgroups, off-topic

2010-04-16 Thread Lars T. Kyllingstad

eles wrote:

Hello,

 I just started using D (2.0). I have three or four questions:

 1) How to use the newsgroup link (e.g. news://news.digitalmars.com/
digitalmars.D.learn) to read the newsgroup? Is the news://; protocol handled
by some program under Linux (Ubuntu, 64)? I write this using the HTTP interface
(e.g. http://www.digitalmars.com/pnews/indexing.php?
server=news.digitalmars.comgroup=digitalmars.D) which is not very pleasant.
COuld we, at least, have an interface like the one used by archives? (e.g.
http://www.digitalmars.com/d/archives/digitalmars/D/
Re_value_range_propagation_for_bitwise_OR_108807.html)? And a SEARCH button?


The news:// protocol should be handled by a news reader.  Whether one is 
started automatically depends on whether you have one installed, and 
whether your browser handles such links correctly.


I am writing this from Thunderbird, which has a very capable news reader 
built in.




 2) What is the status of complex numbers in D2? Is stated that module
std.complex will replace the built-in types cfloat, cdouble, creal, ifloat,
idouble, and ireal. When and... how?


I am almost done writing a replacement for std.complex.  Some minor work 
remains, and then it will have to be reviewed/approved.  Assuming that 
goes well it shouldn't be too far away. :)




 2a) Why the following program has the following output?

 import std.stdio;
real x;
ireal y;
creal z;

int main(){
x=3;
y=5i;
z=x+y;
writefln(x=%f,x);
writefln(y=%f,y);
writefln(z=%f,z);
return 0;
}
=
x=3.00
y=5.00
z=3.00+5.00i

Since y is an ireal number, I would have expected to be written as 5.00i,
not 5.00. This is even more confussing as %f formatting seems to handle
well creal numbers, but not ireal ones.


The built-in complex numbers are weird in several ways.  The above will 
be addressed in the new std.complex.




 3) When DMD for Linux will be 64-bit, too? (Now it works, with multilib).
However, it is a nuisance to install multilib.


The D2 language, which has so far been the experimental branch of D 
and as such has been a rapidly moving target, is in its final stages of 
completion.  The specification has more or less been frozen, and 
currently work is being done on bringing the DMD compiler up to spec. 
When this is done (this summer, I believe) work is supposed to start on 
a 64-bit compiler.


-Lars


Re: Newsgroups, off-topic

2010-04-16 Thread Joseph Wakeling
Lars T. Kyllingstad wrote:
 The D2 language, which has so far been the experimental branch of D
 and as such has been a rapidly moving target, is in its final stages of
 completion.  The specification has more or less been frozen, and
 currently work is being done on bringing the DMD compiler up to spec.
 When this is done (this summer, I believe) work is supposed to start on
 a 64-bit compiler.

My concern about this is more along the lines of: when will D2 versions
of LDC and/or GDC be available?

To an extent I'm not sure I understand why, with two great backends
available, D2 development did not switch over entirely to one or the
other of these -- though I understand the fact that the DMD backend is
probably the one the Digital Mars developers are most comfortable with.


Re: Newsgroups, off-topic

2010-04-16 Thread Petru Avram



On Fri, 16 Apr 2010 16:26:00 +0300, eles e...@eles.com wrote: Hello,  I just started using D (2.0). I have three or four questions:  1) How to use the newsgroup link (e.g. news://news.digitalmars.com/ digitalmars.D.learn) to read the newsgroup? Is the "news://" protocol   handled by some program under Linux (Ubuntu, 64)? I write this using the HTTP   interface (e.g. http://www.digitalmars.com/pnews/indexing.php? server=news.digitalmars.comgroup=digitalmars.D) which is not very   pleasant. COuld we, at least, have an interface like the one used by archives?   (e.g. http://www.digitalmars.com/d/archives/digitalmars/D/ Re_value_range_propagation_for_bitwise_OR_108807.html)? And a SEARCH   button?  2) What is the status of complex numbers in D2? Is stated that module std.complex will replace the built-in types cfloat, cdouble, creal,   ifloat, idouble, and ireal. When and... how?Knode is for KDE but it is the best I have used so far. You can also try Pan for Gnome (I heard it is the best) or you can try the new Opera browser that has this feature included in the mail module (along many other features – I recommend downloading the preview deb package of Opera 10.5 from http://snapshot.opera.com/unix/snapshot-6317/ which is usable as a browser too and is as fast/faster than Chromium (it uses more memory though). -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

Re: Newsgroups, off-topic

2010-04-16 Thread Moritz Warning
On Fri, 16 Apr 2010 17:28:36 +0200, Joseph Wakeling wrote:

 Lars T. Kyllingstad wrote:
 The D2 language, which has so far been the experimental branch of D
 and as such has been a rapidly moving target, is in its final stages of
 completion.  The specification has more or less been frozen, and
 currently work is being done on bringing the DMD compiler up to spec.
 When this is done (this summer, I believe) work is supposed to start on
 a 64-bit compiler.
 
 My concern about this is more along the lines of: when will D2 versions
 of LDC and/or GDC be available?
 
 To an extent I'm not sure I understand why, with two great backends
 available, D2 development did not switch over entirely to one or the
 other of these -- though I understand the fact that the DMD backend is
 probably the one the Digital Mars developers are most comfortable with.

I think many people behind these compilers lack the personal motivation
to integrate the D2 front end.
That may change, but it may take time.

Some reasons I can think of:
- it's quite some work to integrate a new front end (there are a lot of 
new features in D2)
- D1 works quite well for many people and is more stable (important!)
- D2 doesn't offer much gain for many existing projects atm. (features 
vs. stability and transition cost)
- not everybody likes the road the D2 design takes

anyway, gdc has D2 support already (but not up to date/DMD), see http://
bitbucket.org/goshawk/gdc/overview


Re: Newsgroups, off-topic

2010-04-16 Thread eles
Thank you for your answer. I hope to see std.complex integrated in the next
release of dmd. I am mainly interested in scientific (i.e. numerical)
computations, so a good numerical library (GSL, Lapack etc.) would be welcome
in D.

I like the std.algorithm, though.

Eles

PS Thanks to everybody for pointing me to Thunderbird and Opera. Both are nice.

PS2 What does really means to use LLVM or GCC backends for dmd? Is a front-end
somewhat like a parser (or bytecode compiler) and the back-end something like
an assembler?


Re: Newsgroups, off-topic

2010-04-16 Thread Ellery Newcomer

On 04/16/2010 03:13 PM, eles wrote:


PS2 What does really means to use LLVM or GCC backends for dmd? Is a front-end
somewhat like a parser (or bytecode compiler) and the back-end something like
an assembler?


Pretty much.

Except in the case of D, the front end also requires a backend of sorts 
(for ctfe), and from what I understand, DMD's frontend and backend are 
kind of squooshed together. (Like certain errors don't get caught unless 
and until the backend's optimizer gets run)