www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Core vs Library

reply Walter Bright <newshound1 digitalmars.com> writes:
http://reddit.com/info/6foi8/comments/
Apr 14 2008
next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:ftv48m$21m5$1 digitalmars.com...

 http://reddit.com/info/6foi8/comments/


1: Yes, in .Net languages the core types are aliases to structs in System, 
not the other way around.

2: The article seems self-contradictory.  First you say that an int as a 
struct is slow, possibly ugly, can't be optimized, etc. etc.  But then you 
turn around and say that modern compilers can make a user-defined complex 
type efficient.  Which is it?  It doesn't feel like the article comes to any 
kind of conclusion.  Is it that fundamental types like int and float should 
be builtin, while anything higher-level including complex can be done 
satisfactorily as a library?
Apr 14 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:

 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:ftv48m$21m5$1 digitalmars.com...

 http://reddit.com/info/6foi8/comments/


 
 1: Yes, in .Net languages the core types are aliases to structs in System, 
 not the other way around.




after all, divides aren't done by a subroutine somewhere, they're done 
by a hardware instruction.

If you don't agree, show me how System.Int32 can be implemented without 
referring to a core int type.



 2: The article seems self-contradictory.  First you say that an int as a 
 struct is slow, possibly ugly, can't be optimized, etc. etc.  But then you 
 turn around and say that modern compilers can make a user-defined complex 
 type efficient.  Which is it?  It doesn't feel like the article comes to any 
 kind of conclusion.  Is it that fundamental types like int and float should 
 be builtin, while anything higher-level including complex can be done 
 satisfactorily as a library?


The struct can be optimized if it is based upon *core* types that can be 
optimized.
Apr 14 2008
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Walter Bright" <newshound1 digitalmars.com> wrote in message 
news:fu0bb5$1sa1$1 digitalmars.com...


 1: Yes, in .Net languages the core types are aliases to structs in 
 System, not the other way around.




 after all, divides aren't done by a subroutine somewhere, they're done by 
 a hardware instruction.

 If you don't agree, show me how System.Int32 can be implemented without 
 referring to a core int type.





it'd yield System.Int32.  System.Int32 is a value type, one of the builtin 
types in the .net runtime.  Being a value type, it is allocated on the 
stack, passed by copy, all the things you'd expect.


it's emitting CLR, not x86.  If it emits a "div" instruction with two values 
of type System.Int32 as its parameters, the JIT compiler then has the 
opportunity to optimize that down to a single x86 "idiv" instruction rather 
than making a subroutine call.  However, System.Int32s, being object types, 
can still participate in object-like behavior - they can have methods and 
such.

Remember that codegen in .net languages is a 2-step process, and as such, 
the high-level language compiler is not really the one that has to deal with 
low-level representation, even of basic types like int.


 The struct can be optimized if it is based upon *core* types that can be 
 optimized.


OK.
Apr 14 2008
next sibling parent Walter Bright <newshound1 digitalmars.com> writes:
Jarrett Billingsley wrote:




 it'd yield System.Int32.  System.Int32 is a value type, one of the builtin 
 types in the .net runtime.  Being a value type, it is allocated on the 
 stack, passed by copy, all the things you'd expect.
 

 it's emitting CLR, not x86.  If it emits a "div" instruction with two values 
 of type System.Int32 as its parameters, the JIT compiler then has the 
 opportunity to optimize that down to a single x86 "idiv" instruction rather 
 than making a subroutine call.  However, System.Int32s, being object types, 
 can still participate in object-like behavior - they can have methods and 
 such.


The CLR has a special 'int32' data type. See the spec for it:
http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-335.pdf
section 8.2.2



 Remember that codegen in .net languages is a 2-step process, and as such, 
 the high-level language compiler is not really the one that has to deal with 
 low-level representation, even of basic types like int.


It still recognizes it as a special, core type.


types. See 8.2.4.
Apr 14 2008
prev sibling next sibling parent "Koroskin Denis" <2korden gmail.com> writes:
It looks like Int32 defined as follows:
(output from Reflector)

public struct Int32 : IComparable, IFormattable, IConvertible,  =

IComparable<int>, IEquatable<int>
{
     internal int32 m_value; // here it is!

     public const int MaxValue =3D 0x7fffffff;
     public const int MinValue =3D -2147483648;
     public int CompareTo(object value);
     public int CompareTo(int value);
     public override bool Equals(object obj);
     public bool Equals(int obj);
     public override int GetHashCode();
     public override string ToString();
     public string ToString(string format);
     public string ToString(IFormatProvider provider);
     public string ToString(string format, IFormatProvider provider);
     public static int Parse(string s);
     public static int Parse(string s, NumberStyles style);
     public static int Parse(string s, IFormatProvider provider);
     public static int Parse(string s, NumberStyles style, IFormatProvid=
er  =

provider);
     public static bool TryParse(string s, out int result);
     public static bool TryParse(string s, NumberStyles style,  =

IFormatProvider provider, out int result);
     public TypeCode GetTypeCode();
     bool IConvertible.ToBoolean(IFormatProvider provider);
     char IConvertible.ToChar(IFormatProvider provider);
     sbyte IConvertible.ToSByte(IFormatProvider provider);
     byte IConvertible.ToByte(IFormatProvider provider);
     short IConvertible.ToInt16(IFormatProvider provider);
     ushort IConvertible.ToUInt16(IFormatProvider provider);
     int IConvertible.ToInt32(IFormatProvider provider);
     uint IConvertible.ToUInt32(IFormatProvider provider);
     long IConvertible.ToInt64(IFormatProvider provider);
     ulong IConvertible.ToUInt64(IFormatProvider provider);
     float IConvertible.ToSingle(IFormatProvider provider);
     double IConvertible.ToDouble(IFormatProvider provider);
     decimal IConvertible.ToDecimal(IFormatProvider provider);
     DateTime IConvertible.ToDateTime(IFormatProvider provider);
     object IConvertible.ToType(Type type, IFormatProvider provider);
}


On Tue, 15 Apr 2008 00:46:50 +0400, Jarrett Billingsley  =

<kb3ctd2 yahoo.com> wrote:


 "Walter Bright" <newshound1 digitalmars.com> wrote in message
 news:fu0bb5$1sa1$1 digitalmars.com...


 1: Yes, in .Net languages the core types are aliases to structs in
 System, not the other way around.









 after all, divides aren't done by a subroutine somewhere, they're don=




e  =


 by
 a hardware instruction.

 If you don't agree, show me how System.Int32 can be implemented witho=




ut

 referring to a core int type.







 'int'
 and 'System.Int32' are one and the same.  If you could do "typeof(5)" =


in  =



 it'd yield System.Int32.  System.Int32 is a value type, one of the  =



 builtin
 types in the .net runtime.  Being a value type, it is allocated on the=



 stack, passed by copy, all the things you'd expect.




 =


 code,
 it's emitting CLR, not x86.  If it emits a "div" instruction with two =


 =


 values
 of type System.Int32 as its parameters, the JIT compiler then has the
 opportunity to optimize that down to a single x86 "idiv" instruction  =



 rather
 than making a subroutine call.  However, System.Int32s, being object  =



 types,
 can still participate in object-like behavior - they can have methods =


and

 such.

 Remember that codegen in .net languages is a 2-step process, and as su=


ch,

 the high-level language compiler is not really the one that has to dea=


l  =


 with
 low-level representation, even of basic types like int.


 The struct can be optimized if it is based upon *core* types that can=




 be

 optimized.


 OK.




-- =

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Apr 17 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Jarrett Billingsley wrote:

  However, System.Int32s, being object types, 
 can still participate in object-like behavior - they can have methods and 
 such.
 


Being "object-like", and having methods and such, does not make a type a 
library type (in the sense of Core vs. Library).


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Apr 25 2008
prev sibling next sibling parent davidl <davidl 126.com> writes:
Jarrett Billingsley Wrote:


 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:ftv48m$21m5$1 digitalmars.com...

 http://reddit.com/info/6foi8/comments/


 
 1: Yes, in .Net languages the core types are aliases to structs in System, 
 not the other way around.
 
 2: The article seems self-contradictory.  First you say that an int as a 
 struct is slow, possibly ugly, can't be optimized, etc. etc.  But then you 
 turn around and say that modern compilers can make a user-defined complex 
 type efficient.  Which is it?  It doesn't feel like the article comes to any 
 kind of conclusion.  Is it that fundamental types like int and float should 
 be builtin, while anything higher-level including complex can be done 
 satisfactorily as a library? 
 
 


the link time code generation is powerful.  It can optimize it very well as
fast as built-in. I guess it's what that article means.
Apr 14 2008
prev sibling next sibling parent Don <nospam nospam.com> writes:
Jarrett Billingsley Wrote:


 "Walter Bright" <newshound1 digitalmars.com> wrote in message 
 news:ftv48m$21m5$1 digitalmars.com...

 http://reddit.com/info/6foi8/comments/


 
 1: Yes, in .Net languages the core types are aliases to structs in System, 
 not the other way around.
 
 2: The article seems self-contradictory.  First you say that an int as a 
 struct is slow, possibly ugly, can't be optimized, etc. etc.  But then you 
 turn around and say that modern compilers can make a user-defined complex 
 type efficient.  Which is it?  It doesn't feel like the article comes to any 
 kind of conclusion.  Is it that fundamental types like int and float should 
 be builtin, while anything higher-level including complex can be done 
 satisfactorily as a library? 


I got the message that there's a 'sweet spot' in how much the language does vs
how much the library does. With advances in compiler technology, the sweet spot
is gradually moving towards library implementation, but it's unlikely that it
will *ever* move to 100% library, and it's certainly not there now. Currently
the sweet spot is roughly at complex numbers.

-don.
Apr 15 2008
prev sibling parent renoX <renosky free.fr> writes:
Walter Bright a écrit :

 http://reddit.com/info/6foi8/comments/


I've seen on lambda the ultimate some research paper where they tried to 
put optimisation as a part of the standard library..

So maybe the core vs library will change in the future if these research 
  works out (unlikely but not impossible).

Regards,
renoX
May 24 2008