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...

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

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,
	];

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!

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
> garbage collected languages like Java or C#. While those languages
> 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?

Georg Wrede wrote:
>> In C++, this approach proves to be equally good or better than
>> garbage collected languages like Java or C#. While those languages
>> 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?

"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 garbage collected languages like Java or C#. While those languages 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.

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 garbage collected languages like Java or C#. While those languages 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

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
>>> garbage collected languages like Java or C#. While those languages
>>> 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

Walter Bright wrote:
> Georg Wrede wrote:
>>> In C++, this approach proves to be equally good or better than
>>> garbage collected languages like Java or C#. While those languages
>>> 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...