From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII Path: g2news2.google.com!postnews.google.com!k30g2000yqf.googlegroups.com!not-for-mail From: frankenstein Newsgroups: comp.lang.scheme,comp.lang.ada,comp.lang.functional,comp.lang.c++,comp.programming Subject: Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3? Date: Sun, 2 Aug 2009 03:07:16 -0700 (PDT) Organization: http://groups.google.com Message-ID: References: <2009a75f-63e7-485e-9d9f-955e456578ed@v37g2000prg.googlegroups.com> <7xskgbtcyr.fsf@ruckus.brouhaha.com> NNTP-Posting-Host: 80.109.108.253 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1249207636 26597 127.0.0.1 (2 Aug 2009 10:07:16 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sun, 2 Aug 2009 10:07:16 +0000 (UTC) Complaints-To: groups-abuse@google.com Injection-Info: k30g2000yqf.googlegroups.com; posting-host=80.109.108.253; posting-account=dhvWPAoAAADlsA6TMEkmupyFjVl54yNM User-Agent: G2/1.0 X-HTTP-UserAgent: Opera/9.50 (Macintosh; Intel Mac OS X; U; en),gzip(gfe),gzip(gfe) Xref: g2news2.google.com comp.lang.scheme:6288 comp.lang.ada:7522 comp.lang.functional:2597 comp.lang.c++:48976 comp.programming:12262 Date: 2009-08-02T03:07:16-07:00 List-Id: On Aug 1, 10:56=A0pm, Paul Rubin wrote: > frankenstein writes: > > Fact #1: We must forget about the language shootout page because it is > > and always has been a kinda like of Micky Mouse benchmark (any idot > > who thought he might make up for an excellent programmer posted crappy > > code and once posted it is forever in google's history and a lot of > > other idiots will use the result from the benchmark). RIP language > > shotout page. > > The shootout is reasonably informative when it's about languages that > have many active practitioners. =A0If someone posts crappy slow code > that makes the language look bad for a while, someone else can come > along and post faster code. =A0So there is ongoing competition between > GHC, Ocaml, C++ and so forth. =A0It's only for the languages with fewer > practitioners (these can still be perfectly good languages) that the > early crappy submissions don't get improved regularly. The shootout is completely useless when it comes to real life. I have to deal with large data sets and simulations. My problem is that most of my simulations are stuck in reading in the data. Data from global chemistry transport models and satellite date make quickly up for 500 GB for a year worth of data and observations. Even only processing day after day most of the 12 hours the simulation takes is spent in reading in the data. Fortran by nature is fast even when using object oriented programming. However, I am now changing my code to Bigloo. I have no actual figures if my simulations (basically eigenvalues and inverse and inversion from data and observations; i am using my binding to clapack for this) will be as fast as the ones written in Fortran. However, I made the observation that my class for reading the data from the global chemistry transport model is faster than the origial code which comes shipped with the model for reading in the binary files created by the model. I guess the reason being this: they read in record after record without ever jumping to the match. My class (based on (ieee-string- >float and mmap)) jumps around, e.g. the fortran program (with -O3 option) and ifort compiler would take 6 seconds for reading in an array whereas my bigloo code takes 4 seconds. Disclaimer: (ieee-string- >float) as it now stands has a bug in Bigloo and I was forced to use a software conversion (code for converting 4-bytes to float posted long time ago here on comp.lang.scheme by Oleg) which puts the figures to 8 seconds. However, I am quite sure Bigloo developers will resolve the bug. So my benchmark of seconds is based on a wrong conversion (it will always give 0.0 instead of the actual value). I also made the observations that during the read process my Bigloo program and Fortran consumes the same amount of real memory. I am not expecting that bigloo will be more memory efficient but I hope the grabage collector will serve me well. allocating deallocatin (since Fortran 90 standard) is very efficient in Fortran. Frau Holle