Loading ...
Sorry, an error occurred while loading the content.

RE: {Disarmed} [GP] javascript Re: Discipulus GP Software Recommendations?

Expand Messages
  • Lucas, Simon M
    An alternative approach to achieving the same effect is to use Java Applets instead of JavaScript - Java is much faster than JavaScript, but is installed in
    Message 1 of 23 , May 28, 2007
    • 0 Attachment
      An alternative approach to achieving the same effect

      is to use Java Applets instead of JavaScript - Java is much

      faster than JavaScript, but is installed in fewer browsers.



      Does anyone have any speed / installation-base comparisons

      for the two approaches? Would be interesting to know.



      Best wishes,



      Simon





      From: genetic_programming@yahoogroups.com
      [mailto:genetic_programming@yahoogroups.com] On Behalf Of satya_it10
      Sent: 27 May 2007 07:44
      To: genetic_programming@yahoogroups.com
      Subject: {Disarmed} [GP] javascript Re: Discipulus GP Software
      Recommendations?



      --- In genetic_programming@yahoogroups.com
      <mailto:genetic_programming%40yahoogroups.com> , "jmerelo666"
      <jmerelo@...> wrote:
      >
      > --- In genetic_programming@yahoogroups.com
      <mailto:genetic_programming%40yahoogroups.com> , Lee Spector <lspector@>
      > wrote:
      > >
      > >
      > > A late reply, but for those interested in GP using JavaScript
      I'll be
      > > presenting a paper at GECCO 2007, for which Jon Klein was the
      lead
      > > researcher, called "Unwitting Distributed Genetic Programming
      via
      > > Asynchronous JavaScript and XML". I'll include the abstract
      below.
      > >
      > > -Lee
      > >
      > > thanks u sir ,

      > > \begin{abstract}
      > > The success of a genetic programming system in solving a problem
      is
      > > often a function of the available computational resources. For
      many
      > > problems, the larger the population size and the longer the
      genetic
      > > programming run the more likely the system is to find a
      solution. In
      > > order to increase the probability of success on difficult
      problems,
      > > designers and users of genetic programming systems often desire
      > > access to distributed computation, either locally or across the
      > > internet, to evaluate fitness cases more quickly. Most systems

      thank u sir,please send me some matlab coding for GA
      > > internet-scale distributed computation require a user's
      explicit
      > > participation and the installation of client side software. We
      > > present a proof-of-concept system for distributed computation
      of
      > > genetic programming via asynchronous javascript and XML (AJAX)
      > > techniques which requires no explicit user interaction and no
      > > installation of client side software. Clients automatically
      and
      > > possibly even unknowingly participate in a distributed genetic
      > > programming system simply by visiting a webpage, thereby
      allowing for
      > > the solution of genetic programming problems without running a
      single
      > > local fitness evaluation. The system can be easily introduced
      into
      > > existing webpages to exploit unused client-side computation for
      the
      > > solution of genetic programming and other problems.
      > > \end{abstract}
      > >
      > >
      > >
      > In fact, we'll be publishing a paper on the same subject in one of
      the
      > GECCO workshops (it didn't make it into GECCO proper). A previous
      > version has also been uploaded to ArXiV:
      > http://arxiv.org/abs/cs.DC/0701115
      > Here goes the abstract:
      > The challenge of ad-hoc computing is to find the way of taking
      > advantage of spare cycles in an efficient way that takes into
      account
      > all capabilities of the devices and interconnections available to
      > them. In this paper we explore distributed evolutionary computation
      > based on the Ruby on Rails framework, which overlays a
      > Model-View-Controller on evolutionary computation. It allows
      anybody
      > with a web browser (that is, mostly everybody connected to the
      > Internet) to participate in an evolutionary computation experiment.
      > Using a straightforward farming model, we consider different
      factors,
      > such as the size of the population used. We are mostly interested
      in
      > how they impact on performance, but also the scaling behavior when
      a
      > non-trivial number of computers is applied to the problem.
      Experiments
      > show the impact of different packet sizes on performance, as well
      as a
      > quite limited scaling behavior, due to the characteristics of the
      > server. Several solutions for that problem are proposed.
      > --
      > I would be very interested in having an advance copy of your paper.
      > Can you please email it to me? If you had some time to discuss it,
      > previous or during the conference, I'd also be grateful
      >
      > Cheers
      >
      > JJ
      >





      [Non-text portions of this message have been removed]
    • jmerelo666
      ... In fact, it s not installed by default. And it s not as stealthy. And I m not so sure it would be faster. For simple computations, it would probably be
      Message 2 of 23 , May 28, 2007
      • 0 Attachment
        --- In genetic_programming@yahoogroups.com, "Lucas, Simon M" <sml@...>
        wrote:
        >
        >
        >
        > An alternative approach to achieving the same effect
        >
        > is to use Java Applets instead of JavaScript - Java is much
        >
        > faster than JavaScript, but is installed in fewer browsers.

        In fact, it's not installed by default. And it's not as stealthy. And
        I'm not so sure it would be faster. For simple computations, it would
        probably be more or less the same; take into account that JVMs are not
        specially efficient always.

        > Does anyone have any speed / installation-base comparisons
        >
        > for the two approaches? Would be interesting to know.

        I've done some benchmarks with standalone JavaScript (yep, there's
        such a thing) and it's quite fast, and whatever makes it slower in the
        browser will also make the applet slower. Besides, the whole point is
        to be steatch, and achieve a massive number of customers by using
        something everybody has.

        JJ
      • jmerelo666
        ... I meant _stealthy_ here, not steatch . JJ
        Message 3 of 23 , May 28, 2007
        • 0 Attachment
          --- In genetic_programming@yahoogroups.com, "jmerelo666" <jmerelo@...>
          wrote:

          > browser will also make the applet slower. Besides, the whole point is
          > to be steatch, and achieve a massive number of customers by using

          I meant _stealthy_ here, not "steatch".

          JJ
        • Lucas, Simon M
          Hi JJ, regarding speed - I would expect the difference to be significant - I think client-side JavaScript is interpreted, while Java (even in applets) is
          Message 4 of 23 , May 29, 2007
          • 0 Attachment
            Hi JJ,



            regarding speed - I would expect the difference to be significant -

            I think client-side JavaScript is interpreted, while Java (even in
            applets) is compiled (JIT) -

            - I've benchmarked Java applets doing matrix multiplication and
            they're

            nearly as fast as the equivalent C / C++ program.



            Java applets can be just as stealthy, if that's what you want.



            would be interested to see the JavaScript speed figures.



            cheers,



            Simon



            ps. I didn't realise this, but it seems that server side JavaScript is
            sometimes compiled:



            http://www.jaws.umn.edu/javascript_1.1/intro.htm









            From: genetic_programming@yahoogroups.com
            [mailto:genetic_programming@yahoogroups.com] On Behalf Of jmerelo666
            Sent: 28 May 2007 15:40
            To: genetic_programming@yahoogroups.com
            Subject: {Disarmed} [GP] javascript Re: Discipulus GP Software
            Recommendations?



            --- In genetic_programming@yahoogroups.com
            <mailto:genetic_programming%40yahoogroups.com> , "Lucas, Simon M"
            <sml@...>
            wrote:
            >
            >
            >
            > An alternative approach to achieving the same effect
            >
            > is to use Java Applets instead of JavaScript - Java is much
            >
            > faster than JavaScript, but is installed in fewer browsers.

            In fact, it's not installed by default. And it's not as stealthy. And
            I'm not so sure it would be faster. For simple computations, it would
            probably be more or less the same; take into account that JVMs are not
            specially efficient always.

            > Does anyone have any speed / installation-base comparisons
            >
            > for the two approaches? Would be interesting to know.

            I've done some benchmarks with standalone JavaScript (yep, there's
            such a thing) and it's quite fast, and whatever makes it slower in the
            browser will also make the applet slower. Besides, the whole point is
            to be steatch, and achieve a massive number of customers by using
            something everybody has.

            JJ





            [Non-text portions of this message have been removed]
          • Langdon W B
            The mozilla standalone JavaScript in C (Spidermonkey, JSref) is decribed at http://www.mozilla.org/js/spidermonkey/ They also have an implementation in Java
            Message 5 of 23 , May 29, 2007
            • 0 Attachment
              The mozilla standalone JavaScript in C (Spidermonkey, JSref)
              is decribed at
              http://www.mozilla.org/js/spidermonkey/
              They also have an implementation in Java (Rhino)

              Bill

              W. B. Langdon,
              Mathematical Sciences,
              University of Essex
              Wivenhoe Park,
              Colchester CO4 3SQ, UK
              http://www.essex.ac.uk/maths/staff/langdon/
              Spam blocking gmail
              Foundations of Genetic Programming
              http://www.cs.ucl.ac.uk/staff/W.Langdon/FOGP
              GECCO 2007 http://www.cs.ucl.ac.uk/external/W.Langdon/gecco
              GP EM http://www.springer.com/10710
              GP Bibliography http://www.cs.bham.ac.uk/~wbl/biblio/

              > Hi JJ,
              >
              >
              >
              > regarding speed - I would expect the difference to be significant -
              >
              > I think client-side JavaScript is interpreted, while Java (even in
              > applets) is compiled (JIT) -
              >
              > - I've benchmarked Java applets doing matrix multiplication and
              > they're
              >
              > nearly as fast as the equivalent C / C++ program.
              >
              >
              >
              > Java applets can be just as stealthy, if that's what you want.
              >
              >
              >
              > would be interested to see the JavaScript speed figures.
              >
              >
              >
              > cheers,
              >
              >
              >
              > Simon
              >
              >
              >
              > ps. I didn't realise this, but it seems that server side JavaScript is
              > sometimes compiled:
              >
              >
              >
              > http://www.jaws.umn.edu/javascript_1.1/intro.htm
              >
              >
              >
              >
              >
              >
              >
              >
              >
              > From: genetic_programming@yahoogroups.com
              > [mailto:genetic_programming@yahoogroups.com] On Behalf Of jmerelo666
              > Sent: 28 May 2007 15:40
              > To: genetic_programming@yahoogroups.com
              > Subject: {Disarmed} [GP] javascript Re: Discipulus GP Software
              > Recommendations?
              >
              >
              >
              > --- In genetic_programming@yahoogroups.com
              > <mailto:genetic_programming%40yahoogroups.com> , "Lucas, Simon M"
              > <sml@...>
              > wrote:
              > >
              > >
              > >
              > > An alternative approach to achieving the same effect
              > >
              > > is to use Java Applets instead of JavaScript - Java is much
              > >
              > > faster than JavaScript, but is installed in fewer browsers.
              >
              > In fact, it's not installed by default. And it's not as stealthy. And
              > I'm not so sure it would be faster. For simple computations, it would
              > probably be more or less the same; take into account that JVMs are not
              > specially efficient always.
              >
              > > Does anyone have any speed / installation-base comparisons
              > >
              > > for the two approaches? Would be interesting to know.
              >
              > I've done some benchmarks with standalone JavaScript (yep, there's
              > such a thing) and it's quite fast, and whatever makes it slower in the
              > browser will also make the applet slower. Besides, the whole point is
              > to be steatch, and achieve a massive number of customers by using
              > something everybody has.
              >
              > JJ
              >
              >
              >
              >
              >
            • jmerelo666
              Hi, ... Interpreted JS is not to slow, and, in fact, I would expect some kind of pre-compliation to a bytecode (similar to Java) actually happening in most
              Message 6 of 23 , May 29, 2007
              • 0 Attachment
                Hi,

                > I think client-side JavaScript is interpreted, while Java (even in
                > applets) is compiled (JIT) -
                >
                > - I've benchmarked Java applets doing matrix multiplication and
                > they're
                >
                > nearly as fast as the equivalent C / C++ program.

                Interpreted JS is not to slow, and, in fact, I would expect some kind
                of pre-compliation to a bytecode (similar to Java) actually happening
                in most browsers. JIT is a bytecode that runs within a virtual machine
                that runs within the browser. Of course, that does not mean that JS
                can be faster, but I wouldn't it expect to be orders of magnitude
                slower. Factoring in stuff like development time, JS could even be
                better.

                > Java applets can be just as stealthy, if that's what you want.

                Um, not really. Some (modern) browswers will warn you before
                downloading and running an applet or ActiveX control; in Windows, the
                Java logo will show up in the apps dock. They will also complain if
                the JVM is not installed, and offer to install it. In any case, it
                will be quite clear something is going on. Same goes for Flash
                ActionScript stuff (and I don't have speed figures here, but they
                might also be faster -or not- than JS)

                > would be interested to see the JavaScript speed figures.

                For standalone Javascript, they are right there on my paper. They are
                comparable to other interpreted languages (like Perl).

                JJ
              • Maarten
                Ah, verbal language shoot-out! ... Not entirely true on the definition of JIT compilers. Java first compiles to bytecode, then the JIT will on the fly compile
                Message 7 of 23 , May 29, 2007
                • 0 Attachment
                  Ah, verbal language shoot-out!

                  > Interpreted JS is not to slow, and, in fact, I
                  > would expect some kind of pre-compliation to a
                  > bytecode (similar to Java) actually happening
                  > in most browsers. JIT is a bytecode that runs
                  > within a virtual machine that runs within the
                  > browser. Of course, that does not mean that JS
                  > can be faster, but I wouldn't it expect to be
                  > orders of magnitude slower. Factoring in stuff
                  > like development time, JS could even be better.

                  Not entirely true on the definition of JIT
                  compilers. Java first compiles to bytecode, then
                  the JIT will on the fly compile it to assembler
                  for the platform the JVM is running on. This is
                  very different from running just a bytecode VM as
                  is done in JS. In early days Java ran purely
                  interpreted bytecode, and Java was sloooow.
                  Java's JIT compilation has come a long way, and
                  current Java is indeed very fst.

                  JIT-compiled JS does not exist, and will not exist
                  in the foreseeable future. Even if it gets a
                  Jit-compiler, it will be massively slower than
                  Java. Reason for this is that although both java
                  and JS are strongly typed, JS does duck-typing
                  purely at runtime. I.e., for every method call,
                  it needs to be checked that the underlying object
                  has a method of the specified name. Typically
                  this is done through a hashtable lookup instead
                  of a virtual table dispatch. So, *every* method
                  call involves a hash-lookup. JS is therefore
                  very, very slow. It has this in common with perl,
                  python and ruby.

                  Java is partly compile time typed. Where it is
                  runtime typed (most noteably in the Collections
                  library), it uses casting (a single Runtime
                  check) and virtual table dispatch henceforth.
                  Virtual table dispatch is not more expensive than
                  following a function pointer in C. Compile time
                  typing + use of primitive types + casting logic +
                  virtual table dispatch means that the JIT
                  compiler can make rather strong assumptions on
                  the Java bytecode, and hence compile it to
                  fast/compact code.

                  It might be fun to look at the language shootout
                  at http://shootout.alioth.debian.org/

                  Current status

                  1.0 C gcc
                  1.9 Java JDK-server
                  42 JavaScript SpiderMonkey

                  Giving Java the edge with a factor 20. So yes,
                  it's an order of magnitude.

                  -Maarten-

                  > > Java applets can be just as stealthy, if
                  > > that's what you want.
                  >
                  > Um, not really. Some (modern) browswers will
                  > warn you before downloading and running an
                  > applet or ActiveX control; in Windows, the Java
                  > logo will show up in the apps dock. They will
                  > also complain if the JVM is not installed, and
                  > offer to install it. In any case, it will be
                  > quite clear something is going on. Same goes
                  > for Flash ActionScript stuff (and I don't have
                  > speed figures here, but they might also be
                  > faster -or not- than JS)
                  >
                  > > would be interested to see the JavaScript
                  > > speed figures.
                  >
                  > For standalone Javascript, they are right there
                  > on my paper. They are comparable to other
                  > interpreted languages (like Perl).
                  >
                  > JJ
                • dgoe@itwebs.com
                  I new to this and have been trying to find some source code or genetic programming pseudocode. Just want better understand how to construct the GP program. Any
                  Message 8 of 23 , May 29, 2007
                  • 0 Attachment
                    I new to this and have been trying to find some
                    source code or genetic programming pseudocode.
                    Just want better understand how to construct the GP program.
                    Any links would be appreciated.
                    D.G.

                    ----------------------------------------------------
                    From : jmerelo666 <jmerelo@...>
                    To : genetic_programming@yahoogroups.com
                    Subject : {Disarmed} [GP] javascript Re: Discipulus GP Software
                    Recommendations?
                    Date : Tue, 29 May 2007 12:06:39 -0000
                    > Hi,
                    >
                    > > I think client-side JavaScript is interpreted, while Java (even in
                    > > applets) is compiled (JIT) -
                    > >
                    > > - I've benchmarked Java applets doing matrix multiplication
                    and
                    > > they're
                    > >
                    > > nearly as fast as the equivalent C / C++ program.
                    >
                    > Interpreted JS is not to slow, and, in fact, I would expect some kind
                    > of pre-compliation to a bytecode (similar to Java) actually happening
                    > in most browsers. JIT is a bytecode that runs within a virtual machine
                    > that runs within the browser. Of course, that does not mean that JS
                    > can be faster, but I wouldn't it expect to be orders of magnitude
                    > slower. Factoring in stuff like development time, JS could even be
                    > better.
                    >
                    > > Java applets can be just as stealthy, if that's what you want.
                    >
                    > Um, not really. Some (modern) browswers will warn you before
                    > downloading and running an applet or ActiveX control; in Windows, the
                    > Java logo will show up in the apps dock. They will also complain if
                    > the JVM is not installed, and offer to install it. In any case, it
                    > will be quite clear something is going on. Same goes for Flash
                    > ActionScript stuff (and I don't have speed figures here, but they
                    > might also be faster -or not- than JS)
                    >
                    > > would be interested to see the JavaScript speed figures.
                    >
                    > For standalone Javascript, they are right there on my paper. They are
                    > comparable to other interpreted languages (like Perl).
                    >
                    > JJ
                  • Jurosz Michal
                    Hi, see http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=javascript&lang2=java and
                    Message 9 of 23 , May 29, 2007
                    • 0 Attachment
                      Hi, see

                      http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=javascript&lang2=java

                      and

                      http://shootout.alioth.debian.org/sandbox/benchmark.php?test=all&lang=javascript&lang2=javaclient

                      but I don't know if it helps.

                      * JavaScript is a dynamic and weakly typed.

                      * JIT is amazingly resource-heavy ...
                      http://www.sidhe.org/~dan/blog/archives/000405.html

                      * ...

                      --
                      S pozdravem Michal Jurosz
                      http://pr.perl6.cz/parrot-lgp
                      Linear genetic programming for Parrot VM
                    • Marcus G. Daniels
                      ... Firefox s Spidermonkey does have bytecode representation, but it doesn t have just in time compiler (JIT) as a Java virtual machine will in most cases.
                      Message 10 of 23 , May 29, 2007
                      • 0 Attachment
                        jmerelo666 wrote:
                        >
                        > Interpreted JS is not to slow, and, in fact, I would expect some kind
                        > of pre-compliation to a bytecode (similar to Java) actually happening
                        > in most browsers.
                        >
                        Firefox's Spidermonkey does have bytecode representation, but it doesn't
                        have just in time compiler (JIT) as a Java virtual machine will in most
                        cases.
                        That's what Tamarin is supposed to add to Firefox.

                        Another platform to think about is Silverlight (and Mono's Moonlight).
                        There the bytecode will be JIT'ed CIL with extensions for dynamic languages.
                        http://blogs.msdn.com/hugunin/archive/2007/04/30/a-dynamic-language-runtime-dlr.aspx
                      • Sean Luke
                        It has been my experience (in various optimized code I write) that compared to Java, and ignoring startup time: - Well-optimized scheme is about 5 times slower
                        Message 11 of 23 , May 29, 2007
                        • 0 Attachment
                          It has been my experience (in various optimized code I write) that
                          compared to Java, and ignoring startup time:

                          - Well-optimized scheme is about 5 times slower at best. Actually
                          I've found hand-hacked Kawa to be fastest for stuff I do (about 2x
                          slower) as it has options to add explicit typing.

                          - Python is almost exactly 10 times slower, except when I customize
                          it for certain applications by dropping down to C (or when Numerical
                          Python is (rarely) helpful). psyco only helps a little bit.

                          - Ruby is 30 about times slower

                          - JavaScript (SpiderMonkey) is often over 50 times slower

                          I still use dynamic languages for lots of stuff. They're extremely
                          convenient tools for the right purposes. But if efficiency is your
                          primary goal (as is often the case in GP evaluations), you might wish
                          to look elsewhere.

                          Sean
                        • Jurosz Michal
                          I still believe in Parrot VM (register-based virtual machine) http://www.parrotcode.org/ http://en.wikipedia.org/wiki/Parrot_virtual_machine It is not
                          Message 12 of 23 , May 30, 2007
                          • 0 Attachment
                            I still believe in Parrot VM (register-based virtual machine)
                            http://www.parrotcode.org/
                            http://en.wikipedia.org/wiki/Parrot_virtual_machine

                            It is not optimized well yet.

                            Some old benchmarks (Parrot 0.4.6, August 9, 2006):
                            http://shootout.alioth.debian.org/sandbox/benchmark.php?test=all&lang=parrot&lang2=java

                            parrot-lgp (linear genetic programming implementation for Parrot virtual
                            machine) is optimized for fun (-Ofun) now :-).

                            http://pr.perl6.cz/parrot-lgp


                            Some interesting notes about Parrot VM:
                            * Loadable opcode libraries
                            http://www.sidhe.org/~dan/blog/archives/000409.html
                            * All those opcodes
                            http://www.sidhe.org/~dan/blog/archives/000404.html
                            * Fast interpretation
                            http://www.sidhe.org/~dan/blog/archives/000405.html
                            * another Perl 6 and Parrot links
                            http://perl6.cz/wiki/Perl_6_and_Parrot_links

                            --
                            S pozdravem Michal Jurosz
                          • Marcus G. Daniels
                            Here s a new document on the Tamarin instruction set... http://www.adobe.com/devnet/actionscript/articles/avm2overview.pdf
                            Message 13 of 23 , May 30, 2007
                            • 0 Attachment
                              Here's a new document on the Tamarin instruction set...

                              http://www.adobe.com/devnet/actionscript/articles/avm2overview.pdf
                            • satya_it10
                              ... plz send me some matlab coding regarding to constrained optimisation using ga satyaveer singh india
                              Message 14 of 23 , May 31, 2007
                              • 0 Attachment
                                --- In genetic_programming@yahoogroups.com, "Marcus G. Daniels"
                                <mgd@...> wrote:
                                >
                                > Here's a new document on the Tamarin instruction set...
                                >
                                > http://www.adobe.com/devnet/actionscript/articles/avm2overview.pdf
                                >plz help me in constrained optimisation using ga
                                plz send me some matlab coding regarding to constrained optimisation
                                using ga






                                satyaveer singh
                                india
                              Your message has been successfully submitted and would be delivered to recipients shortly.