Print

Print


I would have a few comments on the topic, if I may.

  * Generics has nothing to do with (1).

    The code is slow with and without using generics (i.e. ArrayList or
    ArrayList<Double>). The performance gain here is not because of not
    using generics, but using native primitive arrays (double[]) to
    store the elements and saving time on the (automatic) conversion to
    wrapper types from double to Double.

    If you use generics, it is automatically handled (so you can write
    things like list.add(3.2)); if you do not use generics, you have to
    explicitly do this (e.g., list.add( new Double(3.2) )).

    Simply by using any of the containers from the Collection Framework
    and you have to deal with these "evil things", which is inefficient
    compared to arrays. On the other hand, it's more convenient to use them.

  * Generics may be indeed a bit compicated (surely how easy something
    can be with a Frequently Asked Questions of 300 pages
    <http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.pdf>?)

  * Where I'd like to see some generic is for instance something like
    Steppable<T extends SimState> to make the casting unnecessary in the
    step(T) function (ain't sure though if it's a valid concept from my
    side).

Best,
Richard

Richard O. Legendi
Software developer
Intelligent Applications and Web Services
AITIA International, Inc.
http://people.inf.elte.hu/legendi/

On 2012.02.01. 16:52, Sean Luke wrote:
> On Feb 1, 2012, at 5:06 AM, #VAISAGH VISWANATHAN THATTAMPARAMBIL# wrote:
>
>> 1.       Backward compatability: You had mentioned that backward compatability was one reason. As in the Collections Framework, is it not possible to enable generics and still compatibility? Did you mean that it would be a lot of work to maintain backward compatability while enabling generics?
>> 2.       Performance : Because of type erasure, wonít a generic and non-generic code behave in the same way?
>> 3.       Lot of work : This I canít argue with  J.
> Backward compatibility is not a good reason.  The big reasons are (1) efficiency issues and (2) it's a lot of work and (3) I don't like how Sun screwed up generics.  :-)
>
> Some discussion about #1.  Generics tend to promote extreme laziness because they operate over basic types by doing autoboxing.  As a result we see a lot of stuff like this:
>
> 	Double d = 4.0
> 	double i = d + 3;
>
> It's hard to overstate just how evil stuff like this is.  It's unbelievably slow.  This impacts ECJ more than MASON, but we still see it a lot in mistaken models.
>
> For fun, try comparing the following code:
>
> import sim.util.DoubleBag;
> import java.util.ArrayList;
>
> public class Test
>      {
>      public static void main(String[] args)
>          {
>          DoubleBag d = new DoubleBag();     // comment this out
>          //ArrayList<Double>  d = new ArrayList<Double>();  // uncomment this
>          for(int i = 0; i<  100000; i++)
>              d.add((double) i);
>          for(int i = 0; i<  100000; i++)
>              for(int j = 0; j<  100000; j++)
>                  d.set(j, d.get(j) + 1);
>          System.err.println(d.get(4));
>          }
>      }
>
> If I run with DoubleBag (an extensible array of basic doubles), this runs in 23 seconds on my machine.  If I run with ArrayList<Double>, this runs in 829 seconds.  I kid you not.
>
>
> Some discussion of #3: Generics broke arrays in a big way.  So much so that Sun had to create an Arrays class which generates arrays in a ridiculously roundabout fashion, and inside the code of that class it's filled with @SuppressWarnings tags to prevent Sun's own compiler from compiling about its own code. :-)
>
> MASON and ECJ use arrays quite extensively for speed.  All the broken screwiness involved in doing generics with arrays gives me serious pause.
>
> Are these good reasons?  I dunno.  Certainly in the future we're going to add some generics to the MASON API where they'd be useful and really reduce casting.  But internally I'll probably still stick with a generics free approach just so I don't have to waste brainpower as an old-time Java coder.
>
> Sean