Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #112461 > unrolled thread

[BBC] Programmers who use spaces 'paid more'

Back to article view | Back to comp.lang.c

Contents

  [BBC] Programmers who use spaces 'paid more' "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-18 21:45 +0800
    Re: [BBC] Programmers who use spaces 'paid more' Per Sandberg <per.s.sandberg@bahnhof.se> - 2017-06-18 22:13 +0200
      Re: [BBC] Programmers who use spaces 'paid more' "J. Clarke" <j.clarke.873638@gmail.com> - 2017-06-18 19:03 -0400
        Re: [BBC] Programmers who use spaces 'paid more' Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2017-06-18 20:22 -0400
        Re: [BBC] Programmers who use spaces 'paid more' "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-06-19 07:50 +0200
          Re: [BBC] Programmers who use spaces 'paid more' "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-19 22:28 +0800
        Re: [BBC] Programmers who use spaces 'paid more' gordonb.nakyl@burditt.org (Gordon Burditt) - 2017-06-19 03:24 -0500
          Re: [BBC] Programmers who use spaces 'paid more' "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-06-19 18:42 +0200
        Re: [BBC] Programmers who use spaces 'paid more' Snit <usenet@gallopinginsanity.com> - 2017-06-19 20:00 -0700
      Re: [BBC] Programmers who use spaces 'paid more' "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-19 18:46 +0800
    Re: [BBC] Programmers who use spaces 'paid more' "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-06-18 18:19 -0700
      Re: [BBC] Programmers who use spaces 'paid more' "J. Clarke" <j.clarke.873638@gmail.com> - 2017-06-18 22:23 -0400
        Re: [BBC] Programmers who use spaces 'paid more' "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-06-19 12:42 -0700
          Re: [BBC] Programmers who use spaces 'paid more' "J. Clarke" <j.clarke.873638@gmail.com> - 2017-06-19 22:19 -0400
            Re: [BBC] Programmers who use spaces 'paid more' "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-06-20 11:44 -0700
      Re: [BBC] Programmers who use spaces 'paid more' "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-19 18:47 +0800
        Re: [BBC] Programmers who use spaces 'paid more' nospam@please.invalid (AnthonyL) - 2017-06-19 11:24 +0000
          Re: [BBC] Programmers who use spaces 'paid more' "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-19 20:26 +0800
    Re: [BBC] Programmers who use spaces 'paid more' JJ <jj4public@vfemail.net> - 2017-06-19 20:53 +0700
      Re: [BBC] Programmers who use spaces 'paid more' "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-19 22:27 +0800
      Re: [BBC] Programmers who use spaces 'paid more' Anton Shepelev <anton.txt@gmail.com> - 2017-06-21 00:51 +0300
        Re: [BBC] Programmers who use spaces 'paid more' asetofsymbols@gmail.com - 2017-06-21 04:43 -0700
          Re: [BBC] Programmers who use spaces 'paid more' "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-21 05:12 -0700
    Re: [BBC] Programmers who use spaces 'paid more' Simon Wright <simon@pushface.org> - 2017-06-21 13:27 +0100
      Re: [BBC] Programmers who use spaces 'paid more' "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-21 05:39 -0700
        Re: [BBC] Programmers who use spaces 'paid more' bartc <bc@freeuk.com> - 2017-06-21 14:12 +0100
        Re: [BBC] Programmers who use spaces 'paid more' "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-21 06:51 -0700
          Re: [BBC] Programmers who use spaces 'paid more' GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-21 17:39 +0200
            Re: [BBC] Programmers who use spaces 'paid more' "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-21 08:46 -0700
              Re: [BBC] Programmers who use spaces 'paid more' GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-21 17:46 +0200
                Re: [BBC] Programmers who use spaces 'paid more' "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-21 08:59 -0700
                  Re: [BBC] Programmers who use spaces 'paid more' GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-21 18:11 +0200
            Re: [BBC] Programmers who use spaces 'paid more' scott@slp53.sl.home (Scott Lurndal) - 2017-06-21 15:50 +0000
              Re: [BBC] Programmers who use spaces 'paid more' GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-21 17:53 +0200
                Re: [BBC] Programmers who use spaces 'paid more' "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-21 09:01 -0700
                  Re: [BBC] Programmers who use spaces 'paid more' GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-21 18:16 +0200
                    Re: [BBC] Programmers who use spaces 'paid more' "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-21 09:28 -0700
                Re: [BBC] Programmers who use spaces 'paid more' scott@slp53.sl.home (Scott Lurndal) - 2017-06-21 16:37 +0000
              Re: [BBC] Programmers who use spaces 'paid more' bartc <bc@freeuk.com> - 2017-06-21 17:40 +0100
                Re: [BBC] Programmers who use spaces 'paid more' "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-21 09:48 -0700
                  Re: [BBC] Programmers who use spaces 'paid more' bartc <bc@freeuk.com> - 2017-06-21 18:05 +0100
                    Re: [BBC] Programmers who use spaces 'paid more' "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-21 11:01 -0700
                      Re: [BBC] Programmers who use spaces 'paid more' bartc <bc@freeuk.com> - 2017-06-21 19:46 +0100
                        Re: [BBC] Programmers who use spaces 'paid more' David Kleinecke <dkleinecke@gmail.com> - 2017-06-21 12:21 -0700
                          Re: [BBC] Programmers who use spaces 'paid more' GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-21 21:31 +0200
    Re: [BBC] Programmers who use spaces 'paid more' "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-06-21 18:48 +0200
      Re: [BBC] Programmers who use spaces 'paid more' "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-06-22 00:52 +0800

Page 3 of 3 — ← Prev page 1 2 [3]

#112807

On 21/06/2017 17:48, Rick C. Hodgin wrote:
> On Wednesday, June 21, 2017 at 12:40:57 PM UTC-4, Bart wrote:
>> Full compilation with Tiny C took about 7% longer with the spaces (an
>> extra 0.25 seconds).
> 
> I believe TinyC is able to compile the Linux kernel.  Can you try
> to see how it goes with tabs and 8-spaces-per-tab?

I'm on Windows.

But I expect, on something that complicated, that spaces vs. tabs would 
be insignificant, because it will spend its time:

* Running configure (a scripted language which calls other utilities 
that use scripts)

* Running make, another scripted language

* Opening and reopening thousands of smallish files

* Doing processing other than the lowest level of tokenising, such as 
#if processing, parsing, code generation etc

* Writing those results to a file.

But here's the loop in my preprocessor that deals with leading white 
space (ie. white space following a new line, as that is different):

     while (1)
         switch (*++lxsptr) {
         case ' ':
         case tab:
             break;
         }

How long does it take to scan data in memory like that? Especially if 
it's just been loaded (or has recently been compiled) so is already cached.

You can work out how many tens of MB per second it can work at, and 
apply that to the number of extra MB that spaces would have.

(You gave a figure of 150MB extra, but I don't know how that is derived. 
It's unlikely that a particular build will compile every source file, as 
the Linux source serves many different platforms. But even at 150MB, it 
make take one second extra.

My quick test showed 50ms extra for 17.5M extra characters, suggesting 
about 350M chars/second, and that version wasn't even optimised code.

Of course, some compilers might be a little bit slower, but I really 
don't think that scanning spaces is a bottleneck.)

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#112811

On Wednesday, June 21, 2017 at 1:05:15 PM UTC-4, Bart wrote:
> On 21/06/2017 17:48, Rick C. Hodgin wrote:
> > On Wednesday, June 21, 2017 at 12:40:57 PM UTC-4, Bart wrote:
> >> Full compilation with Tiny C took about 7% longer with the spaces (an
> >> extra 0.25 seconds).
> > 
> > I believe TinyC is able to compile the Linux kernel.  Can you try
> > to see how it goes with tabs and 8-spaces-per-tab?
> 
> I'm on Windows.
> 
> But I expect, on something that complicated, that spaces vs. tabs would 
> be insignificant, because it will spend its time:
> 
> * Running configure (a scripted language which calls other utilities 
> that use scripts)
> 
> * Running make, another scripted language
> 
> * Opening and reopening thousands of smallish files
> 
> * Doing processing other than the lowest level of tokenising, such as 
> #if processing, parsing, code generation etc
> 
> * Writing those results to a file.

Those will all process at whatever rate they do, but consider also
that every reference through the source file will now span more RAM
than before, meaning the cache is going to be more taxed.

It might not make that much different on modern architectures with
many KB of L1 cache, and often many MB of L2 and L3 cache.  It would
be interesting to see the differences though.

I've gotten the Linux kernel to compile in the past.  It was a little
finicky, but if I can do it in a short period of time I'll try it
again.

> But here's the loop in my preprocessor that deals with leading white 
> space (ie. white space following a new line, as that is different):
> 
>      while (1)
>          switch (*++lxsptr) {
>          case ' ':
>          case tab:
>              break;
>          }
> 
> How long does it take to scan data in memory like that? Especially if 
> it's just been loaded (or has recently been compiled) so is already cached.
> 
> You can work out how many tens of MB per second it can work at, and 
> apply that to the number of extra MB that spaces would have.
> 
> (You gave a figure of 150MB extra, but I don't know how that is derived. 
> It's unlikely that a particular build will compile every source file, as 
> the Linux source serves many different platforms. But even at 150MB, it 
> make take one second extra.
> 
> My quick test showed 50ms extra for 17.5M extra characters, suggesting 
> about 350M chars/second, and that version wasn't even optimised code.
> 
> Of course, some compilers might be a little bit slower, but I really 
> don't think that scanning spaces is a bottleneck.)

You may well be correct.  It may have almost no influence at all.
Even if it didn't alter performance, I'd be curious to see what
the power changes were (if any).

Thank you,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#112813

On 21/06/2017 19:01, Rick C. Hodgin wrote:
> On Wednesday, June 21, 2017 at 1:05:15 PM UTC-4, Bart wrote:
>> On 21/06/2017 17:48, Rick C. Hodgin wrote:
>>> On Wednesday, June 21, 2017 at 12:40:57 PM UTC-4, Bart wrote:
>>>> Full compilation with Tiny C took about 7% longer with the spaces (an
>>>> extra 0.25 seconds).
>>>
>>> I believe TinyC is able to compile the Linux kernel.  Can you try
>>> to see how it goes with tabs and 8-spaces-per-tab?
>>
>> I'm on Windows.
>>
>> But I expect, on something that complicated, that spaces vs. tabs would
>> be insignificant, because it will spend its time:
>>
>> * Running configure (a scripted language which calls other utilities
>> that use scripts)
>>
>> * Running make, another scripted language
>>
>> * Opening and reopening thousands of smallish files
>>
>> * Doing processing other than the lowest level of tokenising, such as
>> #if processing, parsing, code generation etc
>>
>> * Writing those results to a file.
> 
> Those will all process at whatever rate they do, but consider also
> that every reference through the source file will now span more RAM
> than before, meaning the cache is going to be more taxed.

I've measured raw throughput of C source code (ie. basic tokenising but 
excluding name lookups) at around 10M lines per second, on my machine. 
(Around 250M chars per second, of source already in memory.)

That includes scanning spaces in the source code.

But a compiler such as gcc may only operate at 10K lines per second; 
1000 times slower than basic character processing. And that's not 
including all those other things that are going on around the compiler.

I don't like the idea of unnecessary spaces either, but I think they 
have a very small impact. You can combine all the sources of a typical 
project (but not a monster like Linux), and it would likely still be 
smaller than one JPG file, certainly smaller than an uncompressed image 
file, and probably a tiny fraction (0.1% to 1%) of total RAM.

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#112814

On Wednesday, June 21, 2017 at 11:46:23 AM UTC-7, Bart wrote:
> On 21/06/2017 19:01, Rick C. Hodgin wrote:
> > On Wednesday, June 21, 2017 at 1:05:15 PM UTC-4, Bart wrote:
> >> On 21/06/2017 17:48, Rick C. Hodgin wrote:
> >>> On Wednesday, June 21, 2017 at 12:40:57 PM UTC-4, Bart wrote:
> >>>> Full compilation with Tiny C took about 7% longer with the spaces (an
> >>>> extra 0.25 seconds).
> >>>
> >>> I believe TinyC is able to compile the Linux kernel.  Can you try
> >>> to see how it goes with tabs and 8-spaces-per-tab?
> >>
> >> I'm on Windows.
> >>
> >> But I expect, on something that complicated, that spaces vs. tabs would
> >> be insignificant, because it will spend its time:
> >>
> >> * Running configure (a scripted language which calls other utilities
> >> that use scripts)
> >>
> >> * Running make, another scripted language
> >>
> >> * Opening and reopening thousands of smallish files
> >>
> >> * Doing processing other than the lowest level of tokenising, such as
> >> #if processing, parsing, code generation etc
> >>
> >> * Writing those results to a file.
> > 
> > Those will all process at whatever rate they do, but consider also
> > that every reference through the source file will now span more RAM
> > than before, meaning the cache is going to be more taxed.
> 
> I've measured raw throughput of C source code (ie. basic tokenising but 
> excluding name lookups) at around 10M lines per second, on my machine. 
> (Around 250M chars per second, of source already in memory.)
> 
> That includes scanning spaces in the source code.
> 
> But a compiler such as gcc may only operate at 10K lines per second; 
> 1000 times slower than basic character processing. And that's not 
> including all those other things that are going on around the compiler.
> 
> I don't like the idea of unnecessary spaces either, but I think they 
> have a very small impact. You can combine all the sources of a typical 
> project (but not a monster like Linux), and it would likely still be 
> smaller than one JPG file, certainly smaller than an uncompressed image 
> file, and probably a tiny fraction (0.1% to 1%) of total RAM.

In private I usually use TAB as the equivalent of '{' and UNTAB 
as the equivalent of '}' so my C code looks like Python. Since
there isn't any UNTAB character I have to simulate it with a
delete. Of course I clean things up for public presentation.

Actually upon checking I see I am using multiple TABs for long
indents and repeating them every line so I just UNTAB by typing
one less TAB. So automatic I didn't notice what I was doing. I
think I need a better editor (than gedit).

I only use TAB for indents.

[toc] | [prev] | [next] | [standalone]

#112815

On Wed, 21 Jun 2017 12:21:01 -0700 (PDT)
David Kleinecke <dkleinecke@gmail.com> wrote:


> Actually upon checking I see I am using multiple TABs for long
> indents and repeating them every line so I just UNTAB by typing
> one less TAB. So automatic I didn't notice what I was doing. I
> think I need a better editor (than gedit).

I use vi since it is POSIX compliant and it doesn't require X which is a good
solution for any system administrator.

[toc] | [prev] | [next] | [standalone]

#112803

"Mr. Man-wai Chang" <toylet.toylet@gmail.com> writes:

> Computer programmers who use spaces as part of their coding earn
> $15,370 (£12,000) more per year than those who use tabs, a survey of
> developers has revealed.
>
> Full story: <http://www.bbc.com/news/technology-40302410>

It is said that line prefixes in the form of: TAB* SPC{0,tw-1}
are the best of both world.

This is false.

First, you would need an editor to enforce it.

But it doesn't even solve the first problem of TAB, that their width
varies depending on tools and devices.

The problem is that the sequence of spaces must be of a length less than
the TAB width.  So if you start with tw₀ and have sequences of SPC of
length tw₀-1, and you read/process the file on another system using
tw₁<tw₀, then you will get wrong indentations.

Furthermore, when you allow TAB in source files, you may also use them
to align columns of code, eg. to align variable names in one column, and
types in another column.  And for those TAB in the middle of the lines,
the above rule is helpless, and again, you will get wrong indentations
in other environments, but also IN THE SAME ENVIRONMENT, where the TAB
width is kept constant, as soon as you use a different FONT, notably
when you use non-proportional fonts.

I know that it may seem heritic to use non-proportional fonts for code,
but the reality is that it can work very well, as long as you solve in
the IDE those problems of indentation, both prefix and inside a line.

And, it means the editor will have to compute the layout all the time,
from the parse tree.

Which leads me to the conclusion that the origin of a lot of problems is
the fact that we save "source" files that are used as-is both for
human presentation/edition and for machine processing (compiling).  I
would propose the alternative to save the programs eg. in the form of an
abstract syntactic tree (let's say lisp S-expressions), and each time it
is loaded in an IDE/editor, it would be unparsed into the specific
syntactic and layout/indenting preferences of the programmer; and when
saved, the programmer specific syntax would be parsed, and the
S-expression syntactic tree would be saved to the file.  Machine
processing can use directly these S-expression forms.

-- 
__Pascal J. Bourguignon
http://www.informatimago.com

[toc] | [prev] | [next] | [standalone]

#112805

On 22/6/2017 12:48 AM, Pascal J. Bourguignon wrote:
> Which leads me to the conclusion that the origin of a lot of problems is
> the fact that we save "source" files that are used as-is both for
> human presentation/edition and for machine processing (compiling).  I
> would propose the alternative to save the programs eg. in the form of an
> abstract syntactic tree (let's say lisp S-expressions), and each time it
> is loaded in an IDE/editor, it would be unparsed into the specific
> syntactic and layout/indenting preferences of the programmer; and when
> saved, the programmer specific syntax would be parsed, and the
> S-expression syntactic tree would be saved to the file.  Machine
> processing can use directly these S-expression forms.

Basically, a code beautifier. But some programming languages' CR and LF 
mean something. In the case of COBOL, the first few columns have meanings.

Which makes me believe hard, true SPACE is a simple and better solution. 
Anyway....

-- 
   @~@   Remain silent! Drink, Blink, Stretch! Live long and prosper!!
  / v \  Simplicity is Beauty!
/( _ )\ May the Force and farces be with you!
   ^ ^   (x86_64 Ubuntu 9.10)  Linux 2.6.39.3
不借貸! 不詐騙! 不援交! 不打交! 不打劫! 不自殺! 請考慮綜援 (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c

csiph-web