Bill Baxter wrote:
> 
> I wonder if there might be some benefits to separating phobos and tango both out into a core lib containing only the barest essentials required to run D code (e.g. object and gc and not much else), and everything else.  Seems like it would be helpful in your case, at least.  It would seem somehow reassuring to me to be able to clearly see what's essential and what's optional.  But in the end the linker should discard whatever you don't use, so, from a practical standpoint, it's not so necessary.

Tango is already designed this way.  The compiler runtime and garbage collector are each separate libraries with no compile-time dependencies on one another or on any standard library code.  See:

http://www.dsource.org/projects/tango/wiki/TopicAdvancedConfiguration


Sean

Frits van Bommel Wrote:

> Dan wrote:
> > 
> > Oh my...
> > 
> > I went through tango.core.Array and tango.math.Math and personally found several rather junior mistakes like:
> > 
> > int abs(int x){
> >   return x > 0? x : -x;
> >  // should be: return x &= 0x7FFF_FFFF;
> > }
> 
> ...
> 
> That's *so* wrong...
> You may want to save yourself some embarrassment by checking code before
> you post it here:

Bah... you know what I meant.  Unpredicted branches on an x86 cost roughly 6 cycles, not including the neg; we assume for both cases that we're inlining the function (no call overhead)

What I intended to show was that you could do it better with a touch of bit math.

I think the right way is actually to use something like asm's:

rol EAX, 1; // 1000_0001 becomes 0000_0011
shr EAX, 1; // 0000_0011 becomes 0000_0001

Of course, I can't test this.  I'm at work, not at home with my development box. I may have also used the wrong right shift instruction, or used the rotate that goes through the sign bit in EFLAGS.

Surely one of the asm gurus has presented this already?

So I looked around a bit.

Some further reading: http://www.azillionmonkeys.com/qed/2scomp.html http://graphics.stanford.edu/~seander/bithacks.html#IntegerAbs

On Wed, 18 Apr 2007 15:09:12 -0400, Dan wrote:

> I went through tango.core.Array and tango.math.Math and personally found several rather junior mistakes like:
> 
> int abs(int x){
>   return x > 0? x : -x;
>  // should be: return x &= 0x7FFF_FFFF;
> }

I disagree strongly with your "improvement" on the grounds that it assumes a particular implementation of signed integers. The compiler knows better.

If I was to suggest any change it would be

  return x >= 0 ? x : -x;

because that way if zero is supplied, it won't try to evaluate -zero.

-- 
Derek Parnell
Melbourne, Australia
"Justice for David Hicks!"
skype: derek.j.parnell

Derek Parnell wrote:
>   return x >= 0 ? x : -x;

Or, if we're going to get that picky, and you want to prefer +0 over -0, then you can also eliminate the equality test.

  return x < 0 ? -x : x;

I agree with you.. portability is preferred here, considering the non-existent performance difference.

I'd even go as far as saying that using bit twiddling in this specific case is the "junior mistake".

Why?  Because it assumes that the compiler isn't already taking care of this for you.

In C++, my gcc4 already optimizes both -x and x *= -1 into optimal code, similar to the bit-twiddling Dan suggested.  I have to assume we can get the same under D, whether it exists today or not.

--Steve

Alexander Panek wrote:
> Dan wrote:
>> Alexander Panek Wrote:
> the knowledge in detail alone that makes a good EE, it's the knowledge of what tools and environments are available that makes a good engineer, in general. Apart from that.. I think programmers, and engineers in general are the laziest people you can find, when it comes to solutions, but that doesn't make them bad engineers.
> 
> Kind regards,
> Alex

Agreed, the best engineers are the laziest ones.  They normally write the most productive code.

-Joel

janderson wrote:
> Alexander Panek wrote:
>> Dan wrote:
>>> Alexander Panek Wrote:
>> the knowledge in detail alone that makes a good EE, it's the knowledge of what tools and environments are available that makes a good engineer, in general. Apart from that.. I think programmers, and engineers in general are the laziest people you can find, when it comes to solutions, but that doesn't make them bad engineers.
>>
>> Kind regards,
>> Alex
> 
> Agreed, the best engineers are the laziest ones.  They normally write the most productive code.
> 
> -Joel

http://www.lazyway.net/sample_chapter_page1.html

BA

Stephen Waits wrote:
> freeagle wrote:
> 
>> And majority of people will tell you that only one instance of FreeBSD is a better thing than hundreds of instances of linux
> 
> 
> Me included.  But that's OT.
> 
> The things about a "standard library".. first of all, it's "standard", second, it's singular.
> 
> I want to (eventually) use D on the PS3.  If you've got some giant standard library, then porting it to new platforms becomes burdensome. Welcome to smelly town.
> 
> In my job, we don't need tons of library support.  Basic math, basic containers, basic algorithms.  As a matter of fact, we (and about a billion other people) have been using C and C++ and the associated (relatively small other than that iostreams crap) stdlibs for a long time now.  Crypto in the standard library?  NFW!
> 
> KISS guys, KISS..  why not retarget Tango as an addition to Phobos? Something more kitchen-sink'ish?  (ala Python)
> 
> Community or not, it's Walter's language.  Luckily for us, Walter is really freakin' smart about this kind of stuff, and he'll decide, and we'll all thank him for it.
> 
> --Steve

Size of library and porting difficulty are pretty much unrelated if the library is written well.  I do believe Tango is written well.  The porting difficult comes when there are OS or machine dependant features used (system function calls, ASM use), since all of those have to be replaced.

When you start to talk about a large do-everything library, there are a couple categories of code that become very common:
- Things like crypto that only need one dep: a turing complete language.  (It can be asm optimized, but intrinsics and abstraction kill that issue.)
- Things that sit ontop of OS abstractions.  Once you write a File class that handles file level io, then you no longer need to use any OS dependant functions to handle file use.  Port one and you port them all.

Now I remember reading that Tango is interested in doing some media library stuff (SDL kinda stuff- low level graphics, sound and all) and that might be trouble to port.  Of course, I doubt much of the other stuff will depend on it, so just don't port that part of Tango if you are strapped on time.  If they decided to handle GUI at some point, it might be the same deal (espec for app GUIs where native look-and-feel matters).

I've talked with kris some about the idea of porting Tango to arm-wince-pe, a popular PDA platform.  Realize I have done this with phobos, so I have some experience in the matter.  I liked what I heard.  It is very layered.  Get the bottom layers and the rest falls into place.  Minimal OS function dependance, no ASM deps - dude that is /nice/.

Dan wrote:
> Frits van Bommel Wrote:
> 
>> Dan wrote:
>>> Oh my...
>>>
>>> I went through tango.core.Array and tango.math.Math and personally found several rather junior mistakes like:
>>>
>>> int abs(int x){
>>>   return x > 0? x : -x;
>>>  // should be: return x &= 0x7FFF_FFFF;
>>> }
>> ...
>>
>> That's *so* wrong...
>> You may want to save yourself some embarrassment by checking code before you post it here:
> 
> Bah... you know what I meant.  Unpredicted branches on an x86 cost roughly 6 cycles, not including the neg; we assume for both cases that we're inlining the function (no call overhead)
> 
> What I intended to show was that you could do it better with a touch of bit math.
> 
> I think the right way is actually to use something like asm's:
> 
> rol EAX, 1; // 1000_0001 becomes 0000_0011
> shr EAX, 1; // 0000_0011 becomes 0000_0001
> 
> Of course, I can't test this.  I'm at work, not at home with my development box. I may have also used the wrong right shift instruction, or used the rotate that goes through the sign bit in EFLAGS.
> 
> Surely one of the asm gurus has presented this already?
> 
> So I looked around a bit.
> 
> Some further reading:
> http://www.azillionmonkeys.com/qed/2scomp.html
> http://graphics.stanford.edu/~seander/bithacks.html#IntegerAbs

BTW I'm mentioned on that second page <g>.

Seriously, the emphasis to this point in Tango has been getting the interface and the implementation correct, rather than low-level optimisation (since it can be done later). There's a lot still to be done. Any contributions are very welcome.

Dan wrote:

> Likewise I fear for Tango, as it's got that OO gleam in it's eye and is implementing classes for crypto.. I mean.. crypto!?  What's next, a math class?  *shudders*

Please propose a better way to implement stateful algorithms such as block based ciphers, cryptographic hashes or compression algorithms in a way that doesn't require all the source data to be present in memory at once and that supports working on data streams.

/Oskar

Chad J wrote:
> 
> I've talked with kris some about the idea of porting Tango to arm-wince-pe, a popular PDA platform.  Realize I have done this with phobos, so I have some experience in the matter.  I liked what I heard.  It is very layered.  Get the bottom layers and the rest falls into place.  Minimal OS function dependance, no ASM deps - dude that is /nice/.

Ok.  Now that does sound nice.

Having not looked inside Tango, I appreciate your experience and insight.

However, my first problem is getting a compiler to emit PS3 code.  :)

--Steve