Prev: Pathfinding algorithm bugged?
Next: Counting lines of code produced as a metric of programmer quality
From: Pascal Obry on 23 Mar 2010 16:39 Patrick, > It's been said that this approach is like having lifeboats on an ocean > liner while it is in sea trials, and then taking them out when it > starts to carry passengers. Well don't get me wrong. I did not say that one MUST remove checks for production but that one CAN do that. In some cases, HPC come to mind, this can save quite some cycles. If the simulation is not critical (no life depend on it) then why not? At least this is a possibility, let's exploit it where and when it makes sense. 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
From: Mensanator on 23 Mar 2010 18:02 On Mar 23, 2:33 pm, Adam Beneschan <a...(a)irvine.com> wrote: > On Mar 23, 10:41 am, Jim Balson <lab...(a)cherrystonesoftware.com> > wrote: > > > > > > > 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. > > Aside from the fact that (as Pascal Obry pointed out) compilers for > languages that do these checks for you usually provide a way to > suppress those checks, (a) is a little bit naïve. Or maybe a lot > naïve---I don't know. But it's like saying > > (c) The programmer writes code that just works perfectly all the time. > I asked a programmer once (after his program crashed immediately after he compiled it): "Didn't you run this?" His reply: "Why should I run it? I know how it works, I wrote it."
From: John Slimick on 23 Mar 2010 18:27 On 2010-03-23, Patrick Scheible <kkt(a)zipcon.net> wrote: > balson <labrat(a)cherrystonesoftware.com> writes: Small reminder: Pascal did not always compile. The implementation of Pascal on the 6502 chip was done with an interpreter. Despite Microsoft's claim to have invented such things, UCSD created the very successful P-Code for the 6502 that allowed Pascal to run on an 8-bit micro. (P-Code was somehow involved with the rather mis-named Western Digital Pascal Blazer.) john slimick slimick(a)pitt.edu
From: Martin Krischik on 24 Mar 2010 02:24 Am 23.03.2010, 21:33 Uhr, schrieb Patrick Scheible <kkt(a)zipcon.net>: > Pascal Obry <pascal(a)obry.net> writes: >> 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. > > It's been said that this approach is like having lifeboats on an ocean > liner while it is in sea trials, and then taking them out when it > starts to carry passengers. Right on. I was very disappointed then I read the details of Java's assert statement - if you just double click an executable jar file the assets are removed by the class loader :-( . Regards Martin -- Martin Krischik
From: Martin Krischik on 24 Mar 2010 02:33
Am 23.03.2010, 16:05 Uhr, schrieb Maciej Sobczak <see.my.homepage(a)gmail.com>: > 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? Self fulfilling prophecy? Consider something inferior and then rigged the test condition to prove the point? Reminds me of Tiobe which too changes the search rules when the results start to show a trend they don't like. Martin -- Martin Krischik |