Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?
in [ADA]
|
From: J-P. Rosen on 23 Mar 2010 13:12 balson a écrit : > IOW, stay away from the likes of Java, C#, Pascal. Unless you have a > very specific reason for going in that direction. Your performance will > suffer. > I don't see why you put Pascal in the same basket. Pascal is not part of the benchmark, therefore there is no evidence for what you say, and Pascal does not require an interpreter or semi-interpreter. -- --------------------------------------------------------- J-P. Rosen (rosen(a)adalog.fr) Visit Adalog's web site at http://www.adalog.fr
From: Patrick Scheible on 23 Mar 2010 13:31 balson <labrat(a)cherrystonesoftware.com> writes: > > Where's performance on this list? Do you not care how fast the > applications run? Look at the following white paper to see if > performance should or shoild not be high on your list if you are > considering changing development languages: > > http://www.cherrystonesoftware.com/doc/AlgorithmicPerformance.pdf > > What this WP documents is we took 5 basic very common computer science > algorithms and wrote them in different languages: C/C++, Java and C# and > then benchmarked them against each other. If performance is of any > concern to you, you'd stiff with C/C++. > > IOW, stay away from the likes of Java, C#, Pascal. Unless you have a > very specific reason for going in that direction. Your performance will > suffer. [snip] I looked at the paper on the web page you point at. Why do you not distinguish between C and C++? They are significantly different languages. If you use C++, performance will probably suffer compared to C. Why are you making statements about Pascal's performance? While Pascal has some annoying limitations for the programmer, it is very fast. If you tested it, where's the results? If you didn't test it, why are you making disparaging comments about it? Performance only sometimes comes from better performance on the same code. Most of the time, performance gains come from writing a better algorithm. Programmers are better off chosing a language well-suited to the problem. Then if performance isn't good, figure out where it's slow and improve that part of the code. -- Patrick
From: Jim Balson on 23 Mar 2010 13:41 J-P. Rosen wrote: > balson a écrit : >> IOW, stay away from the likes of Java, C#, Pascal. Unless you have a >> very specific reason for going in that direction. Your performance will >> suffer. >> > I don't see why you put Pascal in the same basket. Pascal is not part of > the benchmark, therefore there is no evidence for what you say, and > Pascal does not require an interpreter or semi-interpreter. > I included Pascal because once you get up into languages that do bounds checking, performance will degrade. Pascal is one of those languages that does bounds checking. It comes down to this: a) Either the programmer writes code to not exceed array bounds, or b) Use a language that does it for you. The choice of (a) will cost you a little bit of time developing. The choice of (b) is going to cost you in performance when done. If we were to add another language to our benchmarks, Pascal would be the logical choice. And we may do it at some point in the future. We're certainly going to add many more algorithms to the testing as time permits. Jim
From: Georg Bauhaus on 23 Mar 2010 13:52 Maciej Sobczak schrieb: > On 23 Mar, 14:24, Georg Bauhaus <rm.dash-bauh...(a)futureapps.de> wrote: > >> Note: Cherrystonesoftware markets a product that is not available >> with Java, C#, or other languages. > > Are they supposed to make products for those platforms that they > consider inferior? Why? If only it was stated like this. Anyway, the test cases are interesting for other reasons: Yes, the language implementation matters. E.g., does your JIT compile to MMX or SQRT hardware instructions when running the prime number algorithm? Can you share data efficiently across multiple processors in non-augmented C99 or in Ada? When deciding for/against a programming language, based on likely application performance, it seems equally important to look at some more things. One example is memory management in muticore programs. It seems like malloc() is beginning to show its sequential heritage, with memory management becoming a messy resource conflict, making multithreaded programs slow. This is when VMs using JIT compilers (or programs employing a non-language allocation library...) stand a chance of being faster: they may have built in memory management for multiple processors. Languages like C don't---Cherrystone offers one example. Another benchmarks currently shows rather inconclusive, but instructive results. The same program is run on a single core and on a multicore CPU http://shootout.alioth.debian.org/u64/performance.php?test=chameneosredux http://shootout.alioth.debian.org/u64q/performance.php?test=chameneosredux Thus, I think, language choice may well depend on considering more than massive close-to-the-register CPU operation efficiency. Even when it destroys one's presumptions (that C++, Ada, Eiffel, Modula-3, Fortran, etc. somehow must always be fastest).
From: Pascal Obry on 23 Mar 2010 13:54
Jim, > I included Pascal because once you get up into languages that do bounds > checking, performance will degrade. Pascal is one of those languages > that does bounds checking. It comes down to this: > > a) Either the programmer writes code to not exceed array bounds, or > b) Use a language that does it for you. > > The choice of (a) will cost you a little bit of time developing. > The choice of (b) is going to cost you in performance when done. > > If we were to add another language to our benchmarks, Pascal would be > the logical choice. And we may do it at some point in the future. We're > certainly going to add many more algorithms to the testing as time permits. I dont' know for Pascal, Ada does bound checking too. Nevertheless, in some cases the checks can be removed automatically, for example: type Tab is array (1 .. 10) of Integer; T : Tab; for K in T'Range loop T (K) := end loop; Here "T (K)" won't trigger a runtime check as the compile can see at compile time that K is always in the proper range. But anyway this is not even an issue. For performance you can always remove the checks using the right compiler option. Then you have the best of both worlds. During development the checks are really helpful, in production you remove them. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net - http://v2p.fr.eu.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver keys.gnupg.net --recv-key F949BD3B |