Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #97957 > unrolled thread
| Started by | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2016-12-03 23:58 +0100 |
| Last post | 2016-12-10 11:08 -0800 |
| Articles | 20 on this page of 111 — 24 participants |
Back to article view | Back to comp.lang.c
Counted strings jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-03 23:58 +0100
Re: Counted strings supercat@casperkitty.com - 2016-12-03 15:40 -0800
Counted stringsl Thiago Adams <thiago.adams@gmail.com> - 2016-12-03 15:40 -0800
Re: Counted strings BartC <bc@freeuk.com> - 2016-12-04 00:20 +0000
Re: Counted strings Richard Damon <Richard@Damon-Family.org> - 2016-12-03 21:26 -0500
Re: Counted strings jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-04 18:11 +0100
Re: Counted strings Mark Storkamp <mstorkamp@yahoo.com> - 2016-12-04 19:25 -0600
Re: Counted strings Keith Thompson <kst-u@mib.org> - 2016-12-03 18:57 -0800
Re: Counted strings David Brown <david.brown@hesbynett.no> - 2016-12-04 16:33 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-04 07:52 -0800
Re: Counted strings David Brown <david.brown@hesbynett.no> - 2016-12-04 17:10 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-04 10:14 -0800
Re: Counted strings David Brown <david.brown@hesbynett.no> - 2016-12-04 20:20 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-04 16:49 -0800
Re: Counted strings David Brown <david.brown@hesbynett.no> - 2016-12-05 10:40 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-05 05:51 -0800
Re: Counted strings David Brown <david.brown@hesbynett.no> - 2016-12-05 16:10 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-05 07:38 -0800
Re: Counted strings Melzzzzz <mel@zzzzz.com> - 2016-12-05 16:56 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-05 08:04 -0800
Re: Counted strings Melzzzzz <mel@zzzzz.com> - 2016-12-05 17:16 +0100
Re: Counted strings Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 16:12 -0500
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-05 13:24 -0800
Re: Counted strings David Brown <david.brown@hesbynett.no> - 2016-12-06 10:53 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-06 03:52 -0800
Re: Counted strings David Brown <david.brown@hesbynett.no> - 2016-12-06 13:32 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-06 04:48 -0800
Re: Counted strings Robert Spanjaard <spamtrap@arumes.com> - 2016-12-06 13:42 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-06 05:16 -0800
Re: Counted strings Robert Spanjaard <spamtrap@arumes.com> - 2016-12-06 14:39 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-06 05:24 -0800
Re: Counted strings fir <profesor.fir@gmail.com> - 2016-12-06 05:41 -0800
Re: Counted strings fir <profesor.fir@gmail.com> - 2016-12-06 05:47 -0800
Re: Counted strings Robert Spanjaard <spamtrap@arumes.com> - 2016-12-06 14:48 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-06 05:54 -0800
Re: Counted strings fir <profesor.fir@gmail.com> - 2016-12-06 06:21 -0800
Re: Counted strings fir <profesor.fir@gmail.com> - 2016-12-06 06:24 -0800
Re: Counted strings Robert Spanjaard <spamtrap@arumes.com> - 2016-12-06 18:06 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-06 10:19 -0800
Re: Counted strings Robert Spanjaard <spamtrap@arumes.com> - 2016-12-06 19:45 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-06 11:10 -0800
Re: Counted strings fir <profesor.fir@gmail.com> - 2016-12-06 12:58 -0800
Re: Counted strings fir <profesor.fir@gmail.com> - 2016-12-06 14:08 -0800
Re: Counted strings Keith Thompson <kst-u@mib.org> - 2016-12-06 11:25 -0800
Re: Counted strings fir <profesor.fir@gmail.com> - 2016-12-06 05:28 -0800
Re: Counted strings David Brown <david.brown@hesbynett.no> - 2016-12-06 16:21 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-06 07:29 -0800
Re: Counted strings fir <profesor.fir@gmail.com> - 2016-12-06 07:39 -0800
Re: Counted strings fir <profesor.fir@gmail.com> - 2016-12-06 08:32 -0800
Re: Counted strings fir <profesor.fir@gmail.com> - 2016-12-06 08:32 -0800
Re: Counted strings BartC <bc@freeuk.com> - 2016-12-05 16:28 +0000
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-05 08:34 -0800
Re: Counted strings BartC <bc@freeuk.com> - 2016-12-05 18:27 +0000
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-05 10:36 -0800
Re: Counted strings Ian Collins <ian-news@hotmail.com> - 2016-12-06 08:19 +1300
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-05 11:22 -0800
Re: Counted strings Ian Collins <ian-news@hotmail.com> - 2016-12-06 08:26 +1300
Re: Counted strings BartC <bc@freeuk.com> - 2016-12-05 19:36 +0000
Re: Counted strings Ian Collins <ian-news@hotmail.com> - 2016-12-06 08:41 +1300
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-05 11:48 -0800
Re: Counted strings Thiago Adams <thiago.adams@gmail.com> - 2016-12-05 11:59 -0800
Re: Counted strings jameskuyper@verizon.net - 2016-12-05 12:12 -0800
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-05 12:18 -0800
Re: Counted strings jameskuyper@verizon.net - 2016-12-05 13:17 -0800
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-05 13:29 -0800
Re: Counted strings jameskuyper@verizon.net - 2016-12-05 15:37 -0800
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-05 15:43 -0800
Re: Counted strings David Brown <david.brown@hesbynett.no> - 2016-12-06 13:40 +0100
Re: Counted strings "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-06 12:00 -0500
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-06 10:09 -0800
Re: Counted strings Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 13:33 -0500
Re: Counted strings David Brown <david.brown@hesbynett.no> - 2016-12-06 21:24 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-06 12:56 -0800
Re: Counted strings Keith Thompson <kst-u@mib.org> - 2016-12-05 12:22 -0800
Re: Counted strings supercat@casperkitty.com - 2016-12-05 08:36 -0800
Re: Counted strings BartC <bc@freeuk.com> - 2016-12-05 17:31 +0000
Re: Counted strings David Brown <david.brown@hesbynett.no> - 2016-12-05 22:07 +0100
Re: Counted strings Ian Collins <ian-news@hotmail.com> - 2016-12-06 10:14 +1300
Re: Counted strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-05 22:11 +0000
Re: Counted strings BartC <bc@freeuk.com> - 2016-12-06 02:13 +0000
Re: Counted strings David Brown <david.brown@hesbynett.no> - 2016-12-05 21:57 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-05 13:01 -0800
Re: Counted strings BartC <bc@freeuk.com> - 2016-12-05 21:22 +0000
Re: Counted strings Ian Collins <ian-news@hotmail.com> - 2016-12-06 10:25 +1300
Re: Counted strings BartC <bc@freeuk.com> - 2016-12-05 21:36 +0000
Re: Counted strings jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-05 22:33 +0100
Re: Counted strings "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-05 17:03 -0500
Re: Counted strings supercat@casperkitty.com - 2016-12-04 08:57 -0800
Re: Counted strings Robert Spanjaard <spamtrap@arumes.com> - 2016-12-04 20:19 +0100
Re: Counted strings David Brown <david.brown@hesbynett.no> - 2016-12-04 20:24 +0100
Re: Counted strings Robert Spanjaard <spamtrap@arumes.com> - 2016-12-04 20:37 +0100
Re: Counted strings David Brown <david.brown@hesbynett.no> - 2016-12-04 21:04 +0100
Re: Counted strings Robert Spanjaard <spamtrap@arumes.com> - 2016-12-04 21:22 +0100
Re: Counted strings BartC <bc@freeuk.com> - 2016-12-04 22:37 +0000
Re: Counted strings David Thompson <dave.thompson2@verizon.net> - 2016-12-10 22:42 -0500
Re: Counted strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-10 23:17 -0800
Re: Counted strings Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 11:48 +0000
Re: Counted strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-11 04:40 -0800
Re: Counted strings Robert Spanjaard <spamtrap@arumes.com> - 2016-12-11 10:56 +0100
Re: Counted strings Robert Wessel <robertwessel2@yahoo.com> - 2016-12-05 15:47 -0600
Re: Counted strings Gareth Owen <gwowen@gmail.com> - 2016-12-05 22:01 +0000
Re: Counted strings Robert Wessel <robertwessel2@yahoo.com> - 2016-12-05 22:28 -0600
Re: Counted strings "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-12-05 20:18 -0800
Re: Counted strings Robert Spanjaard <spamtrap@arumes.com> - 2016-12-06 11:05 +0100
Re: Counted strings luser droog <luser.droog@gmail.com> - 2016-12-04 13:13 -0800
Re: Counted strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-05 09:30 -0800
Re: Counted strings Keith Thompson <kst-u@mib.org> - 2016-12-05 09:41 -0800
Re: Counted strings Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-06 11:19 -0800
Re: Counted strings Keith Thompson <kst-u@mib.org> - 2016-12-06 11:44 -0800
Re: Counted strings Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 10:29 -0800
Re: Counted strings supercat@casperkitty.com - 2016-12-10 11:08 -0800
Page 1 of 6 [1] 2 3 4 5 6 Next page →
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-03 23:58 +0100 |
| Subject | Counted strings |
| Message-ID | <o1viji$9d6$1@dont-email.me> |
Instead of prefixing a string with its count, we could do a variable
length encoding, like in utf8.
Strings of length 0 to 254 would be prefixed by a byte containing the
length. If the value of that byte is 255 (0xff, all ones) it means that
the length is encoded in the next two bytes.
Those two bytes encode lengths from 255 to 65535-2, --> 65533. The
length is given by
l == index - 1,
i.e. if we read 576 from those two bytes, the real length of the
following data bytes is 575.
Why? Because we need OBVIOUSLY a continuous function and we have used
the value 255 as an escape character, limiting the full range.
Accounting for that make us substract one.
If the length is all ones, however, it means that the length is stored
in the four next characters, a string longer than 65533. Similar
equation at this step: we need
l == index - 3 and we stop at 4GB - 4 with the useful lengths that this
schema can accomodate. Obviously this can be continued to 64 bits, for
strings longer than 4GB - 4.
I think it is useful since 254 chars is quite a lot (twitter has less)
of strings where the extra overhead of this schema is zero, since the
terminating zero also occupies a character. Many strings used by
programs would fall into this category.
For a bit bigger strings/buffers, the wasted space is at most 255 to 3,
a bit more than 1% at its worst: a string of length 255 needs 1 byte
0xff and then the number '255' written over two bytes, so the overhead
is 3.
The overhead drops significantly with all the longer strings (at 512,
say, the overhead is 512 to 3, much less than 1%. The overhead is
negligible with strings of length 65533 to 3. Still the zero terminated
strings are more efficient (space wise) but make operations like
determine the length of the string incredibly expensive.
The only problem of this schema is the relative complexity of the length
determining procedure.
Other variations would be to make subtypes:
String8 would be:
typedef struct {
unsigned char len;
unsigned char data[];
} StringL8;
typedef struct {
unsigned char len[2];
unsigned char data[];
} StringL16;
typedef struct {
unsigned char len[4];
unsigned char data[];
} StringL32;
... etc. A program could then limit all strings to String16, for
instance, accepting a larger overhead for small strings. This is to be
weighted against the reduction in complexity and expensive copy
operations to convert from one to another. Yes, with such a decision
there would be no strings larger than 65535 but maybe the program
doesn't have those, and if they are ever needed they would be treated
specially.
Now, in this schema we have logical length, i.e. characters (glyphs)
identical to byte length. But if we go for utf8 strings, we should store
two numbers in the length field:
1) The length in bytes
2) The length in characters
Again, a similar scheme could be devised: The logical character count
would have the same length as the byte length: 1, 2, 4, etc.
A length in one byte would be followed by a logical count in one byte, a
byte length in 2 would be followed by 2 bytes of logical length, etc.
What are your ideas about counted strings?
How could it be done?
[toc] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-03 15:40 -0800 |
| Message-ID | <98bfd39e-46e7-48db-834b-7d3df7e40af2@googlegroups.com> |
| In reply to | #97957 |
On Saturday, December 3, 2016 at 4:58:20 PM UTC-6, jacobnavia wrote:
> Instead of prefixing a string with its count, we could do a variable
> length encoding, like in utf8.
>
> Strings of length 0 to 254 would be prefixed by a byte containing the
> length. If the value of that byte is 255 (0xff, all ones) it means that
> the length is encoded in the next two bytes.
I'd be inclined to use a scheme where the botom two bits of the first byte
select among:
- String of length 0-63 (two lower bits 00)
- Empty buffer of length 1-63 (two lower bits 01)
- Partially-full buffer of length 1-63 (two lower bits 10)
- Something bigger (two lower bits 11)
- A special string-descriptor object (00000001 or 00000010)
For the "something bigger" case, the byte would be shifted right and the
next byte would be scaled up 64x and added to it, whereupon the the first
four choices would then apply. If the two lower bits were still 11 (i.e.
the bottom four bits were all set) the next byte would be scaled up 4096x
and added.
For the partially-full buffer case, the last byte of the buffer would
indicate that the string was 1-255 bytes shorter than the buffer (using
values 0-254), or that the preceding four bytes indicate how much shorter
the string is than the buffer.
Using that approach, an empty string buffer could be initialized by merely
encoding the length at the start; after that, string-handling routines could
then perform automatic bounds-checking to ensure that strings could not
overrun their bounds.
For the string-header case, I would use one of the special values to
indicate a header of the form:
struct string_descriptor {
unsigned char descriptor_flag, descriptor_type;
unsigned char *dat;
size_t length;
size_t size;
}
If string routines start by building descriptors for passed-in strings,
code which needs to pass a fragment of a string could build a descriptor
for that fragment and pass that, and have code which expects the above
style of string treat it like any other.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2016-12-03 15:40 -0800 |
| Subject | Counted stringsl |
| Message-ID | <a8c4fee5-1b75-41e7-996d-8a71e8903905@googlegroups.com> |
| In reply to | #97957 |
The counter can be before the start of the string.. Then you have a compatible pointer with normal C string. COM BSTR is like that. I think in C some constructs have pairs but they can be arranged differently and there is no standard type. There is one exception that Is time_t plus nanoseconds? Added with c11 threads. To standardized some pair type I think first we need a reason, or in other words some algorithms added that require these types. My last weak use of strings was a fixed buffer and its size. I have more uses for a string builder than pair string-size. The string builder has size and capacity.Capacity is how long is the memory allocated. I have normal c string without need for size as well.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-04 00:20 +0000 |
| Message-ID | <o1vnds$rag$1@dont-email.me> |
| In reply to | #97957 |
On 03/12/2016 22:58, jacobnavia wrote: > Instead of prefixing a string with its count, we could do a variable > length encoding, like in utf8. > I think it is useful since 254 chars is quite a lot (twitter has less) > of strings where the extra overhead of this schema is zero, since the > terminating zero also occupies a character. Many strings used by > programs would fall into this category. I sometimes use an interesting scheme which has zero overhead, for counted strings within a field of 2 to 256 characters. Useful for small fields within a struct. However determining the actual length (or storing it) is a bit fiddly; I used this by converting to and from a normal counted string representation if I wanted to read or write the field; an extra overtime in time. > What are your ideas about counted strings? I use them quite a bit in one of my libraries, but the overheads are big compared with what you're talking about, and that's using a 32-bit length! Currently it's a 32-byte struct, shared with other kinds of objects, but it also needs to worry about sharing/ref counting, slicing, and managing allocation when the string can grow. However, a simple version can just be (length, pointer). So 8, 12 or 16 bytes, PLUS the string. (Unless you can encode short strings of 0 to 7 characters 'inline' in place of the pointer.) Note if space for this struct and/or string is allocated on the heap, that will have its own overheads. The big thing about counted strings is that there is a count, so it should be immediately accessible! Not requiring some algorithm. I don't worry too much about strings bigger than 4GB; if there is even one string that big, then it will probably be the only one! (You might not be able fit two into into memory.) Big strings are specialised I think and could use a dedicated library (that perhaps can map an entire disk file into a big string). But the VAST majority of normal strings I use (in my interpreters) are tiny. ---------------------- Zero space overhead, fixed-length counted string field. Maximum length of field is M characters: Counted is encoded within the last two chars of the fixed string; X,Y are character codes: 0,N Length is N 0,0 Length is 0 (special case of 0,N) X,0 Length is M-1 X,Y Length is M Only works up for M in 2..256, and the string can't contain zero bytes. String is not usually zero-terminated. Should work for UTF8 but the count is then the number of bytes. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2016-12-03 21:26 -0500 |
| Message-ID | <99L0A.181722$oF2.148573@fx37.iad> |
| In reply to | #97957 |
On 12/3/16 5:58 PM, jacobnavia wrote:
> Instead of prefixing a string with its count, we could do a variable
> length encoding, like in utf8.
>
> Strings of length 0 to 254 would be prefixed by a byte containing the
> length. If the value of that byte is 255 (0xff, all ones) it means that
> the length is encoded in the next two bytes.
>
> Those two bytes encode lengths from 255 to 65535-2, --> 65533. The
> length is given by
>
> l == index - 1,
>
> i.e. if we read 576 from those two bytes, the real length of the
> following data bytes is 575.
>
> Why? Because we need OBVIOUSLY a continuous function and we have used
> the value 255 as an escape character, limiting the full range.
> Accounting for that make us substract one.
>
> If the length is all ones, however, it means that the length is stored
> in the four next characters, a string longer than 65533. Similar
> equation at this step: we need
>
> l == index - 3 and we stop at 4GB - 4 with the useful lengths that this
> schema can accomodate. Obviously this can be continued to 64 bits, for
> strings longer than 4GB - 4.
>
> I think it is useful since 254 chars is quite a lot (twitter has less)
> of strings where the extra overhead of this schema is zero, since the
> terminating zero also occupies a character. Many strings used by
> programs would fall into this category.
>
> For a bit bigger strings/buffers, the wasted space is at most 255 to 3,
> a bit more than 1% at its worst: a string of length 255 needs 1 byte
> 0xff and then the number '255' written over two bytes, so the overhead
> is 3.
>
> The overhead drops significantly with all the longer strings (at 512,
> say, the overhead is 512 to 3, much less than 1%. The overhead is
> negligible with strings of length 65533 to 3. Still the zero terminated
> strings are more efficient (space wise) but make operations like
> determine the length of the string incredibly expensive.
>
> The only problem of this schema is the relative complexity of the length
> determining procedure.
>
> Other variations would be to make subtypes:
>
> String8 would be:
> typedef struct {
> unsigned char len;
> unsigned char data[];
> } StringL8;
>
> typedef struct {
> unsigned char len[2];
> unsigned char data[];
> } StringL16;
>
> typedef struct {
> unsigned char len[4];
> unsigned char data[];
> } StringL32;
>
> ... etc. A program could then limit all strings to String16, for
> instance, accepting a larger overhead for small strings. This is to be
> weighted against the reduction in complexity and expensive copy
> operations to convert from one to another. Yes, with such a decision
> there would be no strings larger than 65535 but maybe the program
> doesn't have those, and if they are ever needed they would be treated
> specially.
>
> Now, in this schema we have logical length, i.e. characters (glyphs)
> identical to byte length. But if we go for utf8 strings, we should store
> two numbers in the length field:
>
> 1) The length in bytes
> 2) The length in characters
>
> Again, a similar scheme could be devised: The logical character count
> would have the same length as the byte length: 1, 2, 4, etc.
>
> A length in one byte would be followed by a logical count in one byte, a
> byte length in 2 would be followed by 2 bytes of logical length, etc.
>
> What are your ideas about counted strings?
>
> How could it be done?
I think your steps are off a bit.
If in 1 byte we store the values 0-254 and reserve the value 255 for a
bigger number, then in 3 bytes (the first being all 1s) you could encode
65535 different number and reserve again, the all 1s code for bigger,
that would handle 255+0 -> 255+65534 = 65789, then the next step would
be a 7 byte number to slightly above 2^32. This encoding says numbers
generally take twice the number of bytes, minus 1, to represent.
An alternate encode that might also work is rather than reserve the top
VALUE, reserve the top BIT. thus 0-127 are single byte numbers. If the
top bit is set, then you take the bottom 7 bits of that word, and
concatenate them with the bottom 7 bits of the next word (with the top
bit indicating to continue the process). This encoding makes the number
128-254 bigger, but all larger number are smaller, significantly so for
much larger numbers.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-04 18:11 +0100 |
| Message-ID | <o21ilq$v6s$1@dont-email.me> |
| In reply to | #97969 |
Le 04/12/2016 à 03:26, Richard Damon a écrit : > If in 1 byte we store the values 0-254 and reserve the value 255 for a > bigger number, then in 3 bytes (the first being all 1s) you could encode > 65535 different number and reserve again, the all 1s code for bigger, > that would handle 255+0 -> 255+65534 = 65789, then the next step would > be a 7 byte number to slightly above 2^32. This encoding says numbers > generally take twice the number of bytes, minus 1, to represent. Of course... I was thinking of writing 255 as the first length in the extended 2 byte format. Of course I should write 1 and add 254 to it, so I would have more coding space as you point out. Thanks!
[toc] | [prev] | [next] | [standalone]
| From | Mark Storkamp <mstorkamp@yahoo.com> |
|---|---|
| Date | 2016-12-04 19:25 -0600 |
| Message-ID | <mstorkamp-0D71F9.19251804122016@88-209-239-213.giganet.hu> |
| In reply to | #97969 |
In article <99L0A.181722$oF2.148573@fx37.iad>, Richard Damon <Richard@Damon-Family.org> wrote: > An alternate encode that might also work is rather than reserve the top > VALUE, reserve the top BIT. thus 0-127 are single byte numbers. If the > top bit is set, then you take the bottom 7 bits of that word, and > concatenate them with the bottom 7 bits of the next word (with the top > bit indicating to continue the process). This encoding makes the number > 128-254 bigger, but all larger number are smaller, significantly so for > much larger numbers. That's precisely how it's done in MIDI files. That would be my choice. Why reinvent the wheel.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-03 18:57 -0800 |
| Message-ID | <lnzikc4d0o.fsf@kst-u.example.com> |
| In reply to | #97957 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Instead of prefixing a string with its count, we could do a variable
> length encoding, like in utf8.
>
> Strings of length 0 to 254 would be prefixed by a byte containing the
> length. If the value of that byte is 255 (0xff, all ones) it means that
> the length is encoded in the next two bytes.
>
> Those two bytes encode lengths from 255 to 65535-2, --> 65533. The
> length is given by
>
> l == index - 1,
>
> i.e. if we read 576 from those two bytes, the real length of the
> following data bytes is 575.
[...]
Another possibility is to start the array with a single UTF-8
encoded code point representing the length in bytes. With standard
UTF-8 encoding this gives you lengths up to 2**21-1 in 4 bytes.
Extrapolating the scheme gives you up to 2**42-1 encoded in 8 bytes.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-04 16:33 +0100 |
| Message-ID | <o21cu9$b7k$1@dont-email.me> |
| In reply to | #97957 |
On 03/12/16 23:58, jacobnavia wrote:
> Instead of prefixing a string with its count, we could do a variable
> length encoding, like in utf8.
>
> Strings of length 0 to 254 would be prefixed by a byte containing the
> length. If the value of that byte is 255 (0xff, all ones) it means that
> the length is encoded in the next two bytes.
>
> Those two bytes encode lengths from 255 to 65535-2, --> 65533. The
> length is given by
>
> l == index - 1,
>
> i.e. if we read 576 from those two bytes, the real length of the
> following data bytes is 575.
>
> Why? Because we need OBVIOUSLY a continuous function and we have used
> the value 255 as an escape character, limiting the full range.
> Accounting for that make us substract one.
>
> If the length is all ones, however, it means that the length is stored
> in the four next characters, a string longer than 65533. Similar
> equation at this step: we need
>
> l == index - 3 and we stop at 4GB - 4 with the useful lengths that this
> schema can accomodate. Obviously this can be continued to 64 bits, for
> strings longer than 4GB - 4.
>
> I think it is useful since 254 chars is quite a lot (twitter has less)
> of strings where the extra overhead of this schema is zero, since the
> terminating zero also occupies a character. Many strings used by
> programs would fall into this category.
>
> For a bit bigger strings/buffers, the wasted space is at most 255 to 3,
> a bit more than 1% at its worst: a string of length 255 needs 1 byte
> 0xff and then the number '255' written over two bytes, so the overhead
> is 3.
>
> The overhead drops significantly with all the longer strings (at 512,
> say, the overhead is 512 to 3, much less than 1%. The overhead is
> negligible with strings of length 65533 to 3. Still the zero terminated
> strings are more efficient (space wise) but make operations like
> determine the length of the string incredibly expensive.
>
> The only problem of this schema is the relative complexity of the length
> determining procedure.
>
> Other variations would be to make subtypes:
>
> String8 would be:
> typedef struct {
> unsigned char len;
> unsigned char data[];
> } StringL8;
>
> typedef struct {
> unsigned char len[2];
> unsigned char data[];
> } StringL16;
>
> typedef struct {
> unsigned char len[4];
> unsigned char data[];
> } StringL32;
>
> ... etc. A program could then limit all strings to String16, for
> instance, accepting a larger overhead for small strings. This is to be
> weighted against the reduction in complexity and expensive copy
> operations to convert from one to another. Yes, with such a decision
> there would be no strings larger than 65535 but maybe the program
> doesn't have those, and if they are ever needed they would be treated
> specially.
>
> Now, in this schema we have logical length, i.e. characters (glyphs)
> identical to byte length. But if we go for utf8 strings, we should store
> two numbers in the length field:
>
> 1) The length in bytes
> 2) The length in characters
>
> Again, a similar scheme could be devised: The logical character count
> would have the same length as the byte length: 1, 2, 4, etc.
>
> A length in one byte would be followed by a logical count in one byte, a
> byte length in 2 would be followed by 2 bytes of logical length, etc.
>
> What are your ideas about counted strings?
>
> How could it be done?
I would be inclined to simplify to only two possible choices - an 7-bit
length that covers most small strings, and a 31-bit length that covers
any string (data that is more than 2GB is size is not a "string").
You could use the LSB of the first byte of the string to determine if
the rest of the byte gives the 7-bit length, or if the rest of the first
4 bytes gives the 31-bit length. Distinguishing between the two is just
a bit test, and decoding the length is a simple shift instruction
(especially if you have a little-endian platform with 32-bit unsigned
ints and misaligned load support).
I think there is little to be gained by supporting 16-bit length fields.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-04 07:52 -0800 |
| Message-ID | <0f63984b-8f6f-412c-87e6-f5dd9502ceb2@googlegroups.com> |
| In reply to | #97979 |
I recommend passing a pointer to a structure which contains the data member along with its length as an unsigned quantity (typically a 32- bit length for 32-bit pointers, 64-bit for 64-but pointers). Computers are not getting less capable, but more capable. We should shift our focus away frim cimpacteness for reasons of constrained resources, and into areas of greater usability by people.Best Structures with both pointer and length can be reallocated, moved, etc., at any time with every prior reference still able to access them at their new location. Think "people needs," not "machine needs." Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-04 17:10 +0100 |
| Message-ID | <o21f3n$j0m$1@dont-email.me> |
| In reply to | #97981 |
On 04/12/16 16:52, Rick C. Hodgin wrote: > I recommend passing a pointer to a structure which contains the data > member along with its length as an unsigned quantity (typically a 32- > bit length for 32-bit pointers, 64-bit for 64-but pointers). > > Computers are not getting less capable, but more capable. We should > shift our focus away frim cimpacteness for reasons of constrained > resources, and into areas of greater usability by people.Best > > Structures with both pointer and length can be reallocated, moved, etc., > at any time with every prior reference still able to access them at > their new location. > > Think "people needs," not "machine needs." > I agree with you to some extent. But compact representations have their advantages too - as well as being efficient when you have large numbers of them, the improvements in cache hits can make them a good deal faster than less compact but easier formats. When dealing with formats that are used directly by application programmers, then keeping things simple (even if it is less efficient) is often a good idea. But with lower-level formats that will be hidden within the toolchain and/or system libraries, it's fine to be complicated if it leads to greater efficiency. Remember, on a modern cpu it can be worth executing some 200+ instructions to decode a compressed format if it saves a single read from DDR memory. Data is often stored on disk, and even in ram, in compressed formats because that makes the whole process faster, despite the decoding. And of course, the huge majority of processors /are/ in resource constrained systems. Some tools and languages are targeted only at "big" systems, but that is not the case for C (it currently is the case for Jacob's C compiler - but maybe he will branch out). The ideal format for a string depends greatly on what you actually want to do with it. There is no single correct answer here.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-04 10:14 -0800 |
| Message-ID | <c9776b38-16b6-41be-aa8a-44607fcbb211@googlegroups.com> |
| In reply to | #97982 |
Optimization is important. I view it secondary to people needs though, on all but the most niche needs (wherever performance or power savings are paramount). Decoded data must be written to some destination (typically memory). Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-04 20:20 +0100 |
| Message-ID | <o21q7l$tua$1@dont-email.me> |
| In reply to | #97988 |
On 04/12/16 19:14, Rick C. Hodgin wrote: > Optimization is important. I view it secondary to people needs though, > on all but the most niche needs (wherever performance or power savings > are paramount). Agreed, as a general point. But the balance between ease of development and run-time efficiency varies according to the number of people that will use some code, or the number of times the code will run. Thus in low-level library code, it is worth spending extra effort to improve code efficiency - while for application code it is usually developer efficiency that is more important. (And thus the low-level code needs to be designed in a way to make the application programmer's life as easy as possible.) > > Decoded data must be written to some destination (typically memory). > That is sometimes true, but not always. And if it is repeatedly written to the same bit of memory, it never leaves the caches and is therefore very efficient. Anyway, the point has been made - it's all a matter of balance depending on where this code is actually going to be used. (Have you changed newsreaders? Your posts now seem to be without any context or attributions, which is not a good thing.)
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-04 16:49 -0800 |
| Message-ID | <1e048fa0-7c91-430e-8332-f07e2495812d@googlegroups.com> |
| In reply to | #97991 |
David Brown wrote: > (Have you changed newsreaders? Your posts now seem to be without > any context or attributions, which is not a good thing.) It's a new Kindle Fire HD. It's a little weird. An Android device, but not Googleish, more Amazonish. I keep making mistakes, forgetting to do things or not do things required / not required on my other devices. I'll get it sorted out soon. Please bear with me until then. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-05 10:40 +0100 |
| Message-ID | <o23cj0$9l8$1@dont-email.me> |
| In reply to | #98001 |
On 05/12/16 01:49, Rick C. Hodgin wrote: > David Brown wrote: >> (Have you changed newsreaders? Your posts now seem to be without >> any context or attributions, which is not a good thing.) > > It's a new Kindle Fire HD. It's a little weird. An Android device, > but not Googleish, more Amazonish. I keep making mistakes, forgetting > to do things or not do things required / not required on my other > devices. > > I'll get it sorted out soon. Please bear with me until then. > No problem. And you included the context and attributions here, so I guess that means you have it sorted out already. I just wanted to make you aware of the issue, in case you hadn't noticed yourself - I know you like to get these things right.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-05 05:51 -0800 |
| Message-ID | <2cdca7c0-657d-4d61-8457-94ef01f3f4cf@googlegroups.com> |
| In reply to | #98004 |
On Monday, December 5, 2016 at 4:40:07 AM UTC-5, David Brown wrote: > On 05/12/16 01:49, Rick C. Hodgin wrote: > > David Brown wrote: > >> (Have you changed newsreaders? Your posts now seem to be without > >> any context or attributions, which is not a good thing.) > > > > It's a new Kindle Fire HD. It's a little weird. An Android device, > > but not Googleish, more Amazonish. I keep making mistakes, forgetting > > to do things or not do things required / not required on my other > > devices. > > > > I'll get it sorted out soon. Please bear with me until then. > > No problem. And you included the context and attributions here, so I > guess that means you have it sorted out already. I just wanted to make > you aware of the issue, in case you hadn't noticed yourself - I know you > like to get these things right. Well truth be told, it doesn't bother me too much to not see attribution. Only in certain cases where the context is confusing. And to be honest, with some of these threads even with attribution it's still confusing because there are so many levels. It would be nice to have a reader which color coded replies. Nonetheless, I do like to honor the requests of other people who do prefer to see attribution, and generally try to do so. I have been having difficulty using the interface of the Kindle Fire HD. It's good in most areas, but in some it seems odd. Also, another reason I didn't give attribution was because I wasn't generally replying to your reply point-by-point, but was making more of a general philosophy statement. I still stand by the idea that optimization is important, but secondary, and that storage issues are in 2016 absolutely and completely trivial in all cases save those few niche cases where there is an issue of performance affecting real usability. How fast do most operations need to be? I find very few things today that are actual issues of usable performance on my computer. The only one I can think of off the top of my head is compilation time, but now that I'm designing and writing my compiler, I can see why it takes so long and I'm actually beginning to be amazed how fast it compiles. In those few cases where performance is affected notably, it might be worth taking the extra time to make the code a little more obscure to gain the performance benefits. But in all other cases, the needs of ease of development and maintenance far and away exceed the need for optimization. And, of course, all of the above must preclude sloppiness. Things should still always be done in proper accord even if the CPU is so fast and power efficient that it wouldn't matter how inefficient the code is because it goes still so fast ... things still have a proper form they should exist in, and be pursued in those regards. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-05 16:10 +0100 |
| Message-ID | <o23vu2$eaq$1@dont-email.me> |
| In reply to | #98006 |
On 05/12/16 14:51, Rick C. Hodgin wrote: > On Monday, December 5, 2016 at 4:40:07 AM UTC-5, David Brown wrote: >> On 05/12/16 01:49, Rick C. Hodgin wrote: >>> David Brown wrote: >>>> (Have you changed newsreaders? Your posts now seem to be without >>>> any context or attributions, which is not a good thing.) >>> >>> It's a new Kindle Fire HD. It's a little weird. An Android device, >>> but not Googleish, more Amazonish. I keep making mistakes, forgetting >>> to do things or not do things required / not required on my other >>> devices. >>> >>> I'll get it sorted out soon. Please bear with me until then. >> >> No problem. And you included the context and attributions here, so I >> guess that means you have it sorted out already. I just wanted to make >> you aware of the issue, in case you hadn't noticed yourself - I know you >> like to get these things right. > > Well truth be told, it doesn't bother me too much to not see attribution. > Only in certain cases where the context is confusing. And to be honest, > with some of these threads even with attribution it's still confusing > because there are so many levels. It would be nice to have a reader > which color coded replies. Nonetheless, I do like to honor the requests > of other people who do prefer to see attribution, and generally try to > do so. I have been having difficulty using the interface of the Kindle > Fire HD. It's good in most areas, but in some it seems odd. The contexts are there to make it easier for people to see exactly what you are replying to, with the attributions to tell who said what (as well as for basic good manners). Some people use a threaded newsreader with a tree view of the threads - other people like to read them in strict chronological order without a tree. As one of the former users, I find context quotations helpful but can cope without them if necessary - but for people who sort chronologically, they are absolutely essential. > > Also, another reason I didn't give attribution was because I wasn't > generally replying to your reply point-by-point, but was making more of > a general philosophy statement. Fair point. > > I still stand by the idea that optimization is important, but secondary, I am a fan of Heathfield's Law: "It is easier to make a readable program correct, than to make a correct program readable. It is easier to make a correct program fast, than to make a fast program correct." But just as premature optimisation is bad, so is premature pessimisation - efficiency must have its due weighting when designing data structures and code. > and that storage issues are in 2016 absolutely and completely trivial in > all cases save those few niche cases where there is an issue of > performance affecting real usability. That is, as I said before, wrong - at least in the C world, where storage issues and performance issues are often vital. For some types of programming, such as the targets for CAlive, you can always throw a bigger disk or more cpu power at the problem. But for embedded systems - which are the main target of a great deal of C programming - saving a few KB of space may mean buying a cheaper microcontroller and huge cost savings. > How fast do most operations need > to be? I find very few things today that are actual issues of usable > performance on my computer. The only one I can think of off the top of > my head is compilation time, but now that I'm designing and writing my > compiler, I can see why it takes so long and I'm actually beginning to > be amazed how fast it compiles. In the PC world, there are many types of application where speed makes a noticeable effect - but also many where everything is "fast enough" already. And the places where C is often used are at the lower levels and the shared library code, where speed /is/ important. After all, if you don't need efficient code, why bother with C in the first place? Use a higher level language that gives you a lot more functionality for less development time - at the cost of run-time efficiency. > > In those few cases where performance is affected notably, it might be > worth taking the extra time to make the code a little more obscure to > gain the performance benefits. But in all other cases, the needs of > ease of development and maintenance far and away exceed the need for > optimization. > > And, of course, all of the above must preclude sloppiness. Things > should still always be done in proper accord even if the CPU is so fast > and power efficient that it wouldn't matter how inefficient the code is > because it goes still so fast ... things still have a proper form they > should exist in, and be pursued in those regards. > > Best regards, > Rick C. Hodgin >
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-05 07:38 -0800 |
| Message-ID | <7520b145-f095-473c-a117-d89ef8feb590@googlegroups.com> |
| In reply to | #98011 |
On Monday, December 5, 2016 at 10:10:17 AM UTC-5, David Brown wrote: > On 05/12/16 14:51, Rick C. Hodgin wrote: > > On Monday, December 5, 2016 at 4:40:07 AM UTC-5, David Brown wrote: > >> On 05/12/16 01:49, Rick C. Hodgin wrote: > >>> David Brown wrote: > >>>> (Have you changed newsreaders? Your posts now seem to be without > >>>> any context or attributions, which is not a good thing.) > >>> > >>> It's a new Kindle Fire HD. It's a little weird. An Android device, > >>> but not Googleish, more Amazonish. I keep making mistakes, forgetting > >>> to do things or not do things required / not required on my other > >>> devices. > >>> > >>> I'll get it sorted out soon. Please bear with me until then. > >> > >> No problem. And you included the context and attributions here, so I > >> guess that means you have it sorted out already. I just wanted to make > >> you aware of the issue, in case you hadn't noticed yourself - I know you > >> like to get these things right. > > > > Well truth be told, it doesn't bother me too much to not see attribution. > > Only in certain cases where the context is confusing. And to be honest, > > with some of these threads even with attribution it's still confusing > > because there are so many levels. It would be nice to have a reader > > which color coded replies. Nonetheless, I do like to honor the requests > > of other people who do prefer to see attribution, and generally try to > > do so. I have been having difficulty using the interface of the Kindle > > Fire HD. It's good in most areas, but in some it seems odd. > > The contexts are there to make it easier for people to see exactly what > you are replying to, with the attributions to tell who said what (as > well as for basic good manners). Some people use a threaded newsreader > with a tree view of the threads - other people like to read them in > strict chronological order without a tree. As one of the former users, > I find context quotations helpful but can cope without them if necessary > - but for people who sort chronologically, they are absolutely essential. > > > > > Also, another reason I didn't give attribution was because I wasn't > > generally replying to your reply point-by-point, but was making more of > > a general philosophy statement. > > Fair point. > > > > > I still stand by the idea that optimization is important, but secondary, > > and that storage issues are in 2016 absolutely and completely trivial in > > all cases save those few niche cases where there is an issue of > > performance affecting real usability. > > That is, as I said before, wrong - at least in the C world, where > storage issues and performance issues are often vital. I disagree. I've written hundreds of thousands of lines of C code, and I gauge readability and usability a 10:1 concern ahead of per- formance in all but the most niche cases. In those cases where there is some specific need for smaller data or greater performance, it's worth the extra effort required. But in all other cases it's not. C is already much faster than other languages. It's why I use it. It also has the ability to do most things that other languages can't do well. > For some types > of programming, such as the targets for CAlive, you can always throw a > bigger disk or more cpu power at the problem. CAlive's targets aren't that much different than C's. For CAlive, the compiler and IDE will be larger. I intend to provide a lot of support and functionality to help developers, but for generated code, my goals are to be very similar to that of C, save some differences like auto- upsizing during calculations with only the final result being truncated into the target size so as to not lose anything in the intermediate calculations. > But for embedded systems > - which are the main target of a great deal of C programming - saving a > few KB of space may mean buying a cheaper microcontroller and huge cost > savings. I am not an embedded developer. And where I have done embedded development in the past, the apps were pretty trivial and it almost would've been easier to write it in assembly. > > How fast do most operations need > > to be? I find very few things today that are actual issues of usable > > performance on my computer. The only one I can think of off the top of > > my head is compilation time, but now that I'm designing and writing my > > compiler, I can see why it takes so long and I'm actually beginning to > > be amazed how fast it compiles. > > In the PC world, there are many types of application where speed makes a > noticeable effect - but also many where everything is "fast enough" > already. I know of none. Every app I use today is not only usable, but fast, and typically much faster than I can navigate through the UI, which makes me the slowest component of it. Email programs, word processors, spreadsheets, web browsers, and most of the tools I use for development. Only compilation is slow (on the order of less than 10 seconds per full compile, and typically less than 5 seconds on debug builds). That pause is very annoying actually because it's the thing that delays me in the midst of my thought processes. I honestly can't think of another application I use in Linux or on Windows where I think it is slow. I will note that sometimes on Windows the installers are slow. And launch time is slow. But once things are loaded, they are typically fast. I don't see what you see, David. So, we live in different machine use worlds. I see every computer since about the year 2000 as being more than fast enough. > And the places where C is often used are at the lower levels > and the shared library code, where speed /is/ important. After all, if > you don't need efficient code, why bother with C in the first place? Capability. In C you can do anything, and it is inherently efficient because it operates very closely to your source code form. > Use a higher level language that gives you a lot more functionality for > less development time - at the cost of run-time efficiency. > > > In those few cases where performance is affected notably, it might be > > worth taking the extra time to make the code a little more obscure to > > gain the performance benefits. But in all other cases, the needs of > > ease of development and maintenance far and away exceed the need for > > optimization. > > > > And, of course, all of the above must preclude sloppiness. Things > > should still always be done in proper accord even if the CPU is so fast > > and power efficient that it wouldn't matter how inefficient the code is > > because it goes still so fast ... things still have a proper form they > > should exist in, and be pursued in those regards. My view is simple: C is efficient as it is. Writing code in a readable fashion in C is more desirable than dipping into more confusing syntaxes to squeeze out a few more milliseconds of compute savings ... except for where it truly makes a difference. I would also extend that constraint to a timeframe, such that if you have a mature algorithm, one that's not requiring a lot of maintenance over time, then you could re-write it to be more optimized if you wanted because it's not requiring a lot of fixes, meaning it won't require a lot of time to go back over it multiple times, but only when you need it to be to fix an issue. In such a case, the very sporadic occasional glance at the code that takes an extra hour or two to understand its design is worth the gains seen in performance, whereas if you're going in periodically to fix or expand the original algorithm, those extra few hours of developer time add up and it is in no way worth it ... in my opinion. ----- Inefficiency in software design is actually the better solution in most cases because it provides for greater efficiency in the human part of the equation ... in going into code, understanding, debugging, fixing or extending, and then completing the various tasks we face as software developers. The inefficiencies must be "smart inefficiencies" in that you must have a fairly comprehensive view of the machine to be able to make smart determinations on what is a proper inefficiency. String storage mechanisms is one of those areas in my opinion. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-12-05 16:56 +0100 |
| Message-ID | <20161205165601.0e6ec5e0@maxa-pc> |
| In reply to | #98015 |
On Mon, 5 Dec 2016 07:38:21 -0800 (PST) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> wrote: > On Monday, December 5, 2016 at 10:10:17 AM UTC-5, David Brown wrote: > > > In the PC world, there are many types of application where speed > > makes a noticeable effect - but also many where everything is "fast > > enough" already. > > I know of none. Every app I use today is not only usable, but fast, > and typically much faster than I can navigate through the UI, which > makes me the slowest component of it. > > Email programs, word processors, spreadsheets, web browsers, and most > of the tools I use for development. Well, today, I had heavy lag because of badly written javascript (or so) on some banking page... also LibreOffice tend to open big document long time. Also text editor gedit is slow opening big texts. Game Stellaris has heavy lag at end of game. And I have 3.6GHz CPU with 32GB of RAM... mails are small so not a big problem. But usenet readers can show. etc... > > Only compilation is slow (on the order of less than 10 seconds per > full compile, and typically less than 5 seconds on debug builds). > That pause is very annoying actually because it's the thing that > delays me in the midst of my thought processes. How often you compile? > > I honestly can't think of another application I use in Linux or on > Windows where I think it is slow. I will note that sometimes on > Windows the installers are slow. And launch time is slow. But once > things are loaded, they are typically fast. Today, almost everything is slow and bloated.... eg KDE indexer is tremendously slow and hogs system... on Windows, I have it in VM it runs constantly something. Whenever I fire up VM it writes several gigabytes of data to disk... > > I don't see what you see, David. So, we live in different machine use > worlds. I see every computer since about the year 2000 as being more > than fast enough. Bullshit. Try to surf on flash heavy pages on some laptop 10 years ago... > > > And the places where C is often used are at the lower levels > > and the shared library code, where speed /is/ important. After > > all, if you don't need efficient code, why bother with C in the > > first place? C does not guarantees efficient code. Take for example Qt and GTK+. Qt5(C++) is much more lightweight then GTK3(C). > > Capability. In C you can do anything, and it is inherently efficient > because it operates very closely to your source code form. How so? My first version of assembler nbody benchmark was slower then Java ;) > > > Use a higher level language that gives you a lot more functionality > > for less development time - at the cost of run-time efficiency. > > > > > In those few cases where performance is affected notably, it > > > might be worth taking the extra time to make the code a little > > > more obscure to gain the performance benefits. But in all other > > > cases, the needs of ease of development and maintenance far and > > > away exceed the need for optimization. > > > > > > And, of course, all of the above must preclude sloppiness. Things > > > should still always be done in proper accord even if the CPU is > > > so fast and power efficient that it wouldn't matter how > > > inefficient the code is because it goes still so fast ... things > > > still have a proper form they should exist in, and be pursued in > > > those regards. > > My view is simple: C is efficient as it is. Writing code in a > readable fashion in C is more desirable than dipping into more > confusing syntaxes to squeeze out a few more milliseconds of compute > savings ... except for where it truly makes a difference. What you mean by this: care to show example? -- press any key to continue or any other to quit
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-05 08:04 -0800 |
| Message-ID | <34b924dc-16d4-472d-bbf1-be5982ef1a83@googlegroups.com> |
| In reply to | #98018 |
On Monday, December 5, 2016 at 10:56:11 AM UTC-5, Melzzzzz wrote: > [snip] If you would like to communicate with me, refrain from using profanity in your posts. Your choice. And if you'd like me to reply to this post I've snipped, repost it without profanity. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
Page 1 of 6 [1] 2 3 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web