From: Andreas Ericsson <email@example.com> To: Pierre Habouzit <firstname.lastname@example.org>, Andreas Ericsson <email@example.com>, Walter Bright <firstname.lastname@example.org>, email@example.com Subject: Re: [RFC] Convert builin-mailinfo.c to use The Better String Library. Date: Sun, 09 Sep 2007 03:36:25 +0200 [thread overview] Message-ID: <46E34E19.firstname.lastname@example.org> (raw) In-Reply-To: <20070909003718.GE13385@artemis.corp> Pierre Habouzit wrote: > On Sat, Sep 08, 2007 at 11:50:34PM +0000, Andreas Ericsson wrote: > >>>> You can tell C compilers to >>>> check all array accesses, but that is a performance issue. >>> Runtime checking of arrays in D is a performance issue too, so it is >>> selectable via a command line switch. >> Same as in C then. > > HAHAHAHAHAHA. Please, who do you try to convince here ? Except in the > local scope, there is few differences between a foo* and a foo in C. > "Runtime checking of arrays is a performance issue." It's true whether it's done manually by the coder or by the compiler. The difference is that in C, you get to choose where it should be done. >>> But more importantly, >>> 2) For dynamically sized arrays, the dimension of the array is carried >>> with the array, so loops automatically loop the correct number of times. >>> No runtime check is necessary, and it's easier for the code reviewer to >>> visually check the code for correctness. >> But this introduces handy but, strictly speaking, unnecessary overhead >> as well, meaning, in short; 'D is slower than C, but easier to write >> code in'. > > That's BS. See the strbuf API I've been pushing recently ? It has > simplified git's code a lot, because each time git had to deal with a > growing string, it had to deal with at least three variables: the buffer > pointer, the current occupied length, and its allocated size. That was > three thing to have variable names for, and to pass to functions. > Yup. I applaud your efforts, but it does come with a slight overhead, except where it replaces faulty code. In practice, it's probably better to use the api for all the string-handling, as none of it is performance- critical. > Now instead, it's just one struct. D gives that gratis. There is no > performance loss because you _need_ to do the same. How do you deal with > dynamic arrays if you dont't store their lenght and size somewhere ? Or > are you the kind of programmer that write: > > /* 640kb should be enough for everyone… */ > some_type *array = malloc(640 << 10); > No, but it would depend on what I am to do with it. > >> So in essence, it's a bit like Python, but a teensy bit faster and a >> lot easier to shoot yourself in the foot with. > >> What was the niche you were going for when you thought up D? It can't >> have been systems programming, because *any* extra baggage is baggage >> one would like to get rid of. If it was application programming I fail >> to see how one more language would help, as there will be portability >> problems galore and it's still considerably slower to develop in than >> fe Python, while at the same time being considerably easier to mess up >> in. > > Right now I'm just laughing. There is for sure overheads in some > places of D, but the example you take, and what you try to attack in D > is definitely not where you lose any kind of performance. You could have > attacked the GC instead (which is after all an easy classical target). > I was asking what role D was designed to fill. I didn't mean it as an attack, but re-reading what I wrote earlier I see it came off a bit harsh. > Just to evaluate the silliness of your arguments: > * http://www.digitalmars.com/d/comparison.html so that you can tell > what the D features really are, You may notice that the feature-list is being provided by the creators and marketeers of the D language. Walter Bright certainly seems like a nice enough person, but it's possible it's a tad biased. > * http://shootout.alioth.debian.org/gp4/benchmark.php?test=all&lang=all > so that you can know what the D performance really is about. Of > course those are only micro benchmarks, but well, python is "just" > 15 times slower than D, and D seems to be 10% slower. I get it to 7.7xC and 1.2xC, respectively, but whatever. It still means performance-critical apps will be written in C, while insert-script-language-of-choice will still be used for prototyping and not-so performance-critical apps. > Well then I'm > okay with D, I'm ready to buy 10% faster CPUs and avoid a lot of > painful debugging time. In my world, 10% faster hardware is cheaper > by many orders of magnitude than skilled programmers, but YMMV. > I'm curious as to how many fewer bugs D developers write compared to C programmers. I guess it's hard to do a fair test given the comparatively shallow pool of D gurus around, but it'd still be interesting to see a practical test. 20% increase in runtime is certainly acceptable for never having to see a bug again, but is it acceptable for 10% fewer bugs? Or 20% fewer? -- Andreas Ericsson email@example.com OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231
next prev parent reply other threads:[~2007-09-09 1:39 UTC|newest] Thread overview: 102+ messages / expand[flat|nested] mbox.gz Atom feed top 2007-09-04 20:50 Lukas Sandström 2007-09-04 21:38 ` Alex Riesen 2007-09-04 23:01 ` Pierre Habouzit 2007-09-05 14:54 ` Kristian Høgsberg 2007-09-05 17:29 ` Matthieu Moy 2007-09-06 2:30 ` Miles Bader 2007-09-06 4:48 ` Dmitry Kakurin 2007-09-06 4:59 ` Shawn O. Pearce 2007-09-06 9:12 ` Andreas Ericsson 2007-09-06 9:35 ` Junio C Hamano 2007-09-06 10:21 ` Andreas Ericsson 2007-09-06 9:52 ` David Kastrup 2007-09-06 5:03 ` Miles Bader 2007-09-06 12:08 ` Johannes Schindelin 2007-09-06 17:50 ` Linus Torvalds 2007-09-07 0:21 ` Dmitry Kakurin 2007-09-07 0:38 ` Linus Torvalds 2007-09-07 1:08 ` Dmitry Kakurin 2007-09-07 1:27 ` Linus Torvalds 2007-09-07 3:09 ` Dmitry Kakurin 2007-09-07 5:48 ` David Symonds 2007-09-07 6:15 ` Theodore Tso 2007-09-20 14:06 ` Steven Burns 2007-09-20 14:56 ` Andreas Ericsson 2007-09-07 6:31 ` Andreas Ericsson 2007-09-07 22:17 ` Dmitry Kakurin 2007-09-07 22:28 ` David Kastrup 2007-09-08 0:37 ` Dmitry Kakurin 2007-09-08 6:25 ` David Kastrup 2007-09-09 0:29 ` Andreas Ericsson 2007-09-07 6:52 ` David Kastrup 2007-09-07 10:28 ` Johannes Schindelin 2007-09-07 10:26 ` Johannes Schindelin 2007-09-07 6:50 ` David Kastrup 2007-09-07 1:12 ` Linus Torvalds 2007-09-07 1:40 ` alan 2007-09-07 5:09 ` Walter Bright 2007-09-07 7:40 ` David Kastrup 2007-09-07 8:15 ` Walter Bright 2007-09-07 8:26 ` David Kastrup 2007-09-07 9:14 ` Walter Bright 2007-09-07 9:31 ` David Kastrup 2007-09-07 20:22 ` Walter Bright 2007-09-07 20:27 ` David Kastrup 2007-09-07 23:16 ` Walter Bright 2007-09-08 23:50 ` Andreas Ericsson 2007-09-09 0:37 ` Pierre Habouzit 2007-09-09 1:36 ` Andreas Ericsson [this message] 2007-09-07 11:36 ` Wincent Colaiuta 2007-09-07 9:41 ` Pierre Habouzit 2007-09-07 19:03 ` Walter Bright 2007-09-07 19:31 ` David Kastrup 2007-09-07 20:49 ` Walter Bright 2007-09-07 19:41 ` Pierre Habouzit 2007-09-07 19:51 ` David Kastrup 2007-09-07 19:59 ` Pierre Habouzit 2007-09-07 20:40 ` Walter Bright 2007-09-07 20:56 ` Pierre Habouzit 2007-09-07 22:54 ` Walter Bright 2007-09-08 0:56 ` John 'Z-Bo' Zabroski 2007-09-08 6:36 ` David Kastrup 2007-09-19 19:56 ` Steven Burns 2007-09-07 3:06 ` Wincent Colaiuta 2007-09-07 4:06 ` Paul Wankadia 2007-09-07 4:30 ` Nicolas Pitre 2007-09-07 9:19 ` Wincent Colaiuta 2007-09-07 6:25 ` Andreas Ericsson 2007-09-07 10:56 ` Johannes Schindelin 2007-09-07 11:54 ` Andreas Ericsson 2007-09-07 12:33 ` Wincent Colaiuta 2007-09-07 12:55 ` Karl Hasselström 2007-09-07 13:58 ` Andreas Ericsson 2007-09-07 14:13 ` Wincent Colaiuta 2007-09-09 0:09 ` Andreas Ericsson 2007-09-07 16:09 ` David Kastrup 2007-09-07 11:30 ` Wincent Colaiuta 2007-09-07 8:36 ` Walter Bright 2007-09-07 9:41 ` Andreas Ericsson 2007-09-07 19:23 ` Walter Bright 2007-09-07 19:40 ` David Kastrup 2007-09-09 0:25 ` Andreas Ericsson 2009-09-17 16:23 ` Bernd Jendrissek 2007-09-07 11:52 ` Wincent Colaiuta 2007-09-07 19:25 ` Walter Bright 2007-09-22 16:52 ` Steven Burns 2007-09-07 6:47 ` David Kastrup 2007-09-07 7:41 ` Andy Parkins 2007-09-07 8:08 ` David Kastrup 2007-09-07 10:21 ` Johannes Schindelin 2007-09-08 0:32 ` Dmitry Kakurin 2007-09-08 6:24 ` David Kastrup 2007-09-08 23:25 ` Alex Riesen 2007-09-24 13:41 ` figo 2007-09-24 13:57 ` David Kastrup 2007-09-25 19:19 ` Steven Burns 2007-09-25 19:55 ` David Kastrup 2012-05-22 18:30 ` Syed M Raihan 2010-06-10 19:12 ` Ian Molton 2010-06-11 12:23 ` Jakub Narebski 2010-06-11 13:33 ` Dario Rodriguez 2007-09-05 15:27 ` Kristian Høgsberg 2007-09-07 10:47 ` Lukas Sandström
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=46E34E19.firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).