www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - U++ Core vs D programming language

reply Jason House <jason.james.house gmail.com> writes:
Poking around the U++ web site, I spotted this page:
http://www.ultimatepp.org/www$uppweb$vsd$en-us.html

It says "C++ is still well ahead of D (by 70%) if not being hold back by
standard library design and average implementation..."

Since Walter is very proud of D's strings, I wonder if this'll get any
attention.  They use 64 bit gdc for their speed test.  I guess they're using D1
even though they link to a D2 page...
May 01 2008
next sibling parent janderson <askme me.com> writes:
Jason House wrote:

 Poking around the U++ web site, I spotted this page:
 http://www.ultimatepp.org/www$uppweb$vsd$en-us.html
 
 It says "C++ is still well ahead of D (by 70%) if not being hold back by
standard library design and average implementation..."
 
 Since Walter is very proud of D's strings, I wonder if this'll get any
attention.  They use 64 bit gdc for their speed test.  I guess they're using D1
even though they link to a D2 page...


It looks like the implementations are different (more then just by 
language).  Also I wonder how much of the time is spent in the writefln.

-Joel
May 01 2008
prev sibling next sibling parent reply BCS <BCS pathlink.com> writes:
Jason House wrote:

 Poking around the U++ web site, I spotted this page:
 http://www.ultimatepp.org/www$uppweb$vsd$en-us.html
 
 It says "C++ is still well ahead of D (by 70%) if not being hold back by
standard library design and average implementation..."
 
 Since Walter is very proud of D's strings, I wonder if this'll get any
attention.  They use 64 bit gdc for their speed test.  I guess they're using D1
even though they link to a D2 page...


by junking most of the IO and using a table for the  char type check I 
speed up the program by 15% (the older program runs in 115% the time of 
the new)


import std.file;
import std.stdio;
import std.date;

int main (char[][] args)
{
	int w_total;
	int l_total;
	int c_total;
	int[char[]] dictionary;

	foreach(arg; args[1..$])
	{
		d_time start = getUTCtime();

		char[] input;
		int w_cnt, l_cnt, c_cnt;
		int inword;
		int wstart;

		input = cast(char[])std.file.read(arg);

		foreach(int j, char c; input)
		{
			if (c == '\n'){ ++l_cnt; goto skip; }

			if (num[c])
			{
			}
			else if (alph[c])
			{
				if (!inword)
				{
					wstart = j;
					inword = 1;
					++w_cnt;
				}
			}
			else skip: if (inword)
			{	
				char[] word = input[wstart .. j];

				dictionary[word]++;
				inword = 0;
			}
			++c_cnt;
		}
		if (inword)
		{
			char[] w = input[wstart .. input.length];
			dictionary[w]++;
		}
		l_total += l_cnt;
		w_total += w_cnt;
		c_total += c_cnt;

		auto stop = getUTCtime();
		writef("%s\n", cast(float)(stop-start)/TicksPerSecond);

		// avg old runtime on my box was 114
		writef("%s\n\n", 144/cast(float)(stop-start));
	}


	writefln("%8s%8s%8s\n", l_total, w_total, c_total);

	return 0;
}

int[128] num = [
	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
	1,1,1,1,1,1,1,1,1,0,0,0,0,0,0,0,
	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
	];

int[128] alph = [
	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
	0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
	0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
	1,1,1,1,1,1,1,1,1,1,1,0,0,0,0,0,
	0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
	1,1,1,1,1,1,1,1,1,1,1,0,0,0,0,0,
	];
May 01 2008
parent Tower Ty <tytower yahoo.com.au> writes:
While you are there have a look at the simple ,may I say normal , installation
for U++ . SDL
For Linux its the usual ./configure ,and it works quickly and well 

None of D's buggering around for days!
May 01 2008
prev sibling parent reply Georg Wrede <georg nospam.org> writes:
Jason House wrote:

 Poking around the U++ web site, I spotted this page: 
 http://www.ultimatepp.org/www$uppweb$vsd$en-us.html
 
 It says "C++ is still well ahead of D (by 70%) if not being hold back
 by standard library design and average implementation..."


http://www.ultimatepp.org/www$uppweb$overview$en-us.html
says:


 Everything belongs somewhere
 
 In Ultimate++, most objects are bound to some logical scope. As a
 result, you will not see many new operators in code using Ultimate++
 and almost no delete operators outside the implementation of
 containers.
 
 That of course does not mean you are not allowed to use pointers, but
 it is good practice to use pointers just to point to things, never to
 manage heap resources. This also avoids all confusion regarding
 ownership of the underlying object, time of its deletion etc. If you
 need to manage data sets of variable size or polymorphic type, you
 should prefer using one of Ultimate++ containers.
 
 Speaking about it, there are no shared smart pointers (like
 boost::shared_ptr) in Ultimate++ used to manage heap resources at
 interface level. They are not needed and considered bad practice.


And here comes the point:


 In C++, this approach proves to be equally good or better than

 are able to provide automatic management of heap resources, U++
 approach provides very deterministic automatic management of all
 resources.


What should I tell people who quote the last paragraph?
May 02 2008
next sibling parent reply Walter Bright <newshound1 digitalmars.com> writes:
Georg Wrede wrote:

 In C++, this approach proves to be equally good or better than

 are able to provide automatic management of heap resources, U++
 approach provides very deterministic automatic management of all
 resources.


 
 What should I tell people who quote the last paragraph?


Eh, what do I do if I need an object to survive past the end of its scope?
May 02 2008
next sibling parent "Nick Sabalausky" <a a.a> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:fvg4no$30jr$1 digitalmars.com...

 Georg Wrede wrote:

 In C++, this approach proves to be equally good or better than

 are able to provide automatic management of heap resources, U++
 approach provides very deterministic automatic management of all
 resources.


 What should I tell people who quote the last paragraph?


 Eh, what do I do if I need an object to survive past the end of its scope?


Somehow prevent the scope from ending or bind the objects to a broader 
scope, maybe? It sounds like an interesting concept. I've kicked that idea 
around in my head a few times, but never explored it. Not really sure how 
feasable it would be. It would certainly be nice if there were some way to 
make it work. Couldn't really have generator functions...unless there was 
some way to transfer the new object's scope to the calling function. And 
maybe I'm just spouting gibberish ;). I'm curious now how they've gone about 
all of that and how much success they've had.
May 02 2008
prev sibling parent Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Walter Bright wrote:

 Georg Wrede wrote:

 In C++, this approach proves to be equally good or better than

 are able to provide automatic management of heap resources, U++
 approach provides very deterministic automatic management of all
 resources.


 What should I tell people who quote the last paragraph?


 
 Eh, what do I do if I need an object to survive past the end of its scope?


This is exactly what the U++ guys have solved in a really nice fashion, you
return by value and 
the heap resources are transferred back (picked) without any allocate, copy,
free "cycle".

I realize I could me misunderstanding you, but this really solves 99% of the
cases I've ever 
faced...
May 03 2008
prev sibling parent reply Brad Roberts <braddr puremagic.com> writes:
Georg Wrede wrote:

 Jason House wrote:

 Poking around the U++ web site, I spotted this page:
 http://www.ultimatepp.org/www$uppweb$vsd$en-us.html

 It says "C++ is still well ahead of D (by 70%) if not being hold back
 by standard library design and average implementation..."


 
 http://www.ultimatepp.org/www$uppweb$overview$en-us.html
 says:
 

 Everything belongs somewhere

 In Ultimate++, most objects are bound to some logical scope. As a
 result, you will not see many new operators in code using Ultimate++
 and almost no delete operators outside the implementation of
 containers.

 That of course does not mean you are not allowed to use pointers, but
 it is good practice to use pointers just to point to things, never to
 manage heap resources. This also avoids all confusion regarding
 ownership of the underlying object, time of its deletion etc. If you
 need to manage data sets of variable size or polymorphic type, you
 should prefer using one of Ultimate++ containers.

 Speaking about it, there are no shared smart pointers (like
 boost::shared_ptr) in Ultimate++ used to manage heap resources at
 interface level. They are not needed and considered bad practice.




That's certainly _a_ philosophy.  If it happens to work well enough for
your app, then it's a very valid way of doing things.  But often that's
much more easily said than done.


 And here comes the point:
 

 In C++, this approach proves to be equally good or better than

 are able to provide automatic management of heap resources, U++
 approach provides very deterministic automatic management of all
 resources.


 
 What should I tell people who quote the last paragraph?


I'd challenge the original premise.  The assumption is that every
application can be managed by static allocations on the stack and that
it's sufficiently easy to do so that no other technique need be used.
If that's true, then ok, every other technique is useless and almost
certainly slower.  I have a very hard time believing that.

Next, if you can't use pure scope based allocations, then there are
different tradeoffs between RAII, refcounting, and various garbage
collection schemes.  The exact runtime performances vary depending on
usage and exact implementation.  It's impossible to make absolute X is
better than Y withouut loads of qualifications (that make them
non-absolute :).

Later,
Brad
May 02 2008
parent janderson <askme me.com> writes:
Brad Roberts wrote:

 Georg Wrede wrote:

 Jason House wrote:

 Poking around the U++ web site, I spotted this page:
 http://www.ultimatepp.org/www$uppweb$vsd$en-us.html

 It says "C++ is still well ahead of D (by 70%) if not being hold back
 by standard library design and average implementation..."


 http://www.ultimatepp.org/www$uppweb$overview$en-us.html
 says:


 Everything belongs somewhere

 In Ultimate++, most objects are bound to some logical scope. As a
 result, you will not see many new operators in code using Ultimate++
 and almost no delete operators outside the implementation of
 containers.

 That of course does not mean you are not allowed to use pointers, but
 it is good practice to use pointers just to point to things, never to
 manage heap resources. This also avoids all confusion regarding
 ownership of the underlying object, time of its deletion etc. If you
 need to manage data sets of variable size or polymorphic type, you
 should prefer using one of Ultimate++ containers.

 Speaking about it, there are no shared smart pointers (like
 boost::shared_ptr) in Ultimate++ used to manage heap resources at
 interface level. They are not needed and considered bad practice.




 
 That's certainly _a_ philosophy.  If it happens to work well enough for
 your app, then it's a very valid way of doing things.  But often that's
 much more easily said than done.
 

 And here comes the point:


 In C++, this approach proves to be equally good or better than

 are able to provide automatic management of heap resources, U++
 approach provides very deterministic automatic management of all
 resources.


 What should I tell people who quote the last paragraph?


 
 I'd challenge the original premise.  The assumption is that every
 application can be managed by static allocations on the stack and that
 it's sufficiently easy to do so that no other technique need be used.
 If that's true, then ok, every other technique is useless and almost
 certainly slower.  I have a very hard time believing that.
 
 Next, if you can't use pure scope based allocations, then there are
 different tradeoffs between RAII, refcounting, and various garbage
 collection schemes.  The exact runtime performances vary depending on
 usage and exact implementation.  It's impossible to make absolute X is
 better than Y withouut loads of qualifications (that make them
 non-absolute :).
 
 Later,
 Brad



I agree.  I would like to see how U++ performs when programs get larger 
and program size starts becoming a bottleneck.

-Joel
May 02 2008