If I'm reading x10.runtime.17/src-x10/x10/lang/Int.x10 correctly, the
implementation of x10's Int and Long basically leverages the existing Java
int and long types. Since Java versions of "unsigned int" and "unsigned
long" do not exist, this doesn't appear to be as straightforward as my
initial reading of your email implied, though it may be possible for the C++
hosted compiler. Nor are there examples of binary & unary ops or conversions
(which were identified as a key issue in the earlier exchange) and would
need to be implemented. Is this correct?
Regards,
--Jeff
PS. 10-4 on the performance :-)
========================================================================
Jeffery A. Kuehn, Senior HPC Evaluation Researcher
Computer Science and Mathematics Division, Application Performance Tools
National Center for Computational Sciences, Scientific Computing Group
Institute for Advanced Architectures and Algorithms
Extreme Scale System Center
Oak Ridge National Laboratory
One Bethel Valley Road MS6164
Oak Ridge, TN 37831
P:865.241.6134 F:865.241.4811
========================================================================
"The most exciting phrase to hear in science, the one that heralds new
discoveries, is not 'Eureka!' (I found it!) but 'That's funny....'"
--Isaac Asimov
Igor Peshansky wrote:
> Jeff,
>
> The same mechanism is currently used to implement the types you
> call "native" (e.g., Int, Double, etc), so you should have the same
> performance as those. Take a look at, e.g., the sources for Int
> (in x10.runtime.17/src-x10/x10/lang/Int.x10).
>
> Unfortunately, the @Native mechanism I'm referring you to is not
> documented, since we only use it for our internal library
> implementation. There are many gotchas, and I don't want to give
> you the idea that it's in any way ready for general consumption.
> But it should certainly suffice to implement unsigned integer
> types, by copying Int.x10 and making the appropriate
> modifications.
>
> That said, a user-defined type which is not defined using the
> @Native/@NativeRep mechanism can be expected to have worse
> performance than an equivalent @NativeRep'ed type.
>
> Also note that the current distribution is functionality-oriented,
> and does not have the best performance. We are addressing this,
> but for the next couple of releases don't expect lightning speed.
> See the limitations section of the README.
> Igor
>
> Jeff Kuehn <ku...@ornl.gov> wrote on 01/08/2009 05:42:42 PM:
>
>> Does a library implementation or a user defined type have any explicit
> or
>> implicit negative performance implications relative to native types?
>>
>> Regards,
>> --Jeff Kuehn, ORNL
>>
>>
>> Igor Peshansky wrote:
>>> Hi, Jeff,
>>>
>>> There is no built-in support for either of those features.
>>> However, X10 1.7 has more advanced support for user-defined
>>> functionality, which allows expressing them as derived
>>> constructs.
>>>
>>> In 1.7, you can define your own unsigned integer type, and
>>> overload the arithmetic and comparison operators appropriately.
>>>
>>> As for 64-bit array indices, the 1.7 language does allow you to
>>> define a Rail with 64-bit indexing (after all, array indexing in
>>> 1.7 is just function application, and one can overload that).
>>>
>>> I realise that this is a major inconvenience, and we will
>>> certainly look into providing a more integrated solution (though
>>> no promises on the timeframe). As stated above, any solution we
>>> come up with will make these part of the libraries, rather than
>>> alter the language spec. I'll let Nate expound on the plans for
>>> adding these features to the standard libraries.
>>>
>>> Happy New Year!
>>> Igor
>>>
>>> Jeff Kuehn <ku...@ornl.gov> wrote on 01/08/2009 02:58:04 PM:
>>>
>>>> Between December 2007 and July of 2008 we carried on a series of
>>> exchanges
>>>> regarding the addition of unsigned types to the X10 language. On
>>> rereading
>>>> the exchange, it seemed that we were disposed in favour of adding
> this
>>>> feature. However, on reviewing the 1.7 specification, there does not
>>> appear
>>>> to be any reference to unsigned integers, nor does the 1.7.x version
> of
>>> the
>>>> compiler seem to support them. Will unsigned types be added to the
>>> language?
>>>> Also, in the same series of discussions, we noted a need for 64bit
> array
>>>> indices to accommodate large Rails. The discussion seemed to finalize
>
>>> with
>>>> "yes, but we need to think about how to do it right". Will 64 bit
> array
>>>> indices be added to the language?
>>>>
>>>> Best Regards,
>>>> --Jeff Kuehn, ORNL
>>>>
>>>> -------- Original Message --------
>>>> Subject: Unsigned Integer Types?
>>>> Date: Wed, 12 Dec 2007 13:48:47 -0500
>>>> From: Jeff Kuehn <ku...@ornl.gov>
>>>> Reply-To: ku...@ornl.gov
>>>> To: x10-us...@lists.sf.net
>>>>
>>>> Has any thought been directed toward the addition of 32 bit and 64
> bit
>>>> unsigned integer types? (unsigned int, unsigned long)
>>>>
>>>> Regards,
>>>> --Jeff
>>>>
>>>> --
>>>> Jeffery A. Kuehn
>>>> Senior HPC Evaluation Researcher
>>>> Future Technologies Group, Computer Science and Mathematics Division
> and
>>>> Scientific Computing Group, National Center for Computational
> Sciences
>>>> Oak Ridge National Laboratory
>>>> One Bethel Valley Road MS6173
>>>> Oak Ridge, TN 37831
>>>> P:865.241.6134 F:865.241.2650
>>>>
>>>> "The ability to advance the leading edge of technology is
>>>> constrained by the ability to prune the trailing edge."
>>>> -- Charles Dickens of Stanford University
------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
X10-users mailing list
X10-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/x10-users
