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 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-05 21:57 +0100 |
| Message-ID | <o24k96$uqo$1@dont-email.me> |
| In reply to | #98015 |
On 05/12/16 16:38, Rick C. Hodgin wrote: > 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: <snip> >>> >>> 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. > As I have already said, I am a fan of Heathfield's law - readability trumps speed in any fair fight. There is no argument there. My point is that you can't be as dismissive of efficiency (which is not just about speed, and does not necessarily come at the expense of readability or code clarity). Speed /is/ important. Compactness of object code /is/ important. Reducing run-time data sizes /is/ important. These are rarely the /most/ important factors when designing structures or writing code, but they are important nonetheless. > 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. As a language, C is quite weak in features (it is a small language, and a small standard library) - but it has little overhead or "hidden costs" and makes it relatively easy to write efficient code. > >> 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. For comparison, gcc supports at least the following targets in mainline: arm64, alpha, amd64, arm, avr, blackfin, h8330, hppa, ix86, ia64, iq2000, lm32, m32c, m32r, m68k, microblaze, mips, nds, nvptx, powerpc, rs6000, s390, sparc, sparc64, c6x, tile, visium, xtensa These range from 8-bit devices (the smallest target I have used with gcc had no ram at all, and 2KB flash) to 64-bit systems that run mainframes or supercomputers. Some cost a fraction of a dollar for a chip, some cost $10K upwards for the processor chip alone. And that is just /one/ C compiler. It only supports the most common and "normal" processor targets. Do you really think CAlive's targets are similar to C? (This is not a condemnation of CAlive - there is no need for a language to target such a range of architectures. For most processors in current use, C is the /only/ viable programming language other than assembler. But you should be clear about what you are saying here.) > >> 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. > Then don't make claims about C and its usages, or modern programming, unless you /do/ understand about embedded development - it is far too big a fraction of modern C programming to be dismissed. You cannot simply say "on modern processors, speed is not important". For every PC processor made on which efficiency is not important (in your opinion), there are hundreds of processors made for which efficiency is crucial. For every system running a program where it is fine to use an "int" to store a small number, there are hundreds for which an uint8_t would be used because saving that space makes a difference. Again, it's fine to say that CAlive is not for such systems - but don't say that it will be useful for everything but efficiency is not important because hardware is fast enough. >>> 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. My email program can be too slow (especially when re-organising the viewing or searching in mail boxes of thousands of emails). Spreadsheet programs are too slow for some of the tougher calculations I have tried to run, and certainly far too slow for graphs. Web browsers can be too slow for some heavy websites. The list goes on - and I have an expensive modern multi-core cpu with a ridiculous size of memory. Then of course there are other types of work where computers are never as fast as you want (at least, not for computers you can afford!), such as CAD design software, 3D rendering, simulations, etc. And the real big one for most computer users - computer games. Whenever you have bought a machine the price of a small car, that can run the latest games at reasonable speed - a newer and even greater game comes out and reduces your frame rate to 15 fps. (I am not a big gamer, but many people are - it is the driving force behind high-end desktop processors.) Remember Wirth's law: Software gets slower more quickly than hardware gets faster. > > 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. > How would you use C /efficiently/ to read in a text file, and produce a case-insensitive sorted list of the 20 most common words? You would certainly not do so making efficient use of programmer time - precisely because C lacks the capabilities and features you need for such tasks. Third-party libraries (like Jacob's CCL) can help a bit, but compared to writing the code in Python or another high-level language, the amount of effort to do this in C is ridiculous. What about run-time efficiency? For a reasonable size of input, the Python code will run faster if it is well written - unless you have put a huge effort into making specially fast C code. This is precisely because all the work done by the Python code will be in the Python libraries, written in C with a huge effort put into running efficiently - so that the Python user gets it for free. >> 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. No one has suggested writing C in an unreadable fashion - Heathfield's law applies to most code. It is rare indeed that it is worth sacrificing readability for a small saving in time. (That doesn't stop some people trying, of course.) > > 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. That is precisely why in most cases, I would recommend higher level languages (such as Python - since that's one I am familiar with) rather than C, when developer efficiency is more important than run-time efficiency. > > 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. > String storage mechanisms should be hidden from the programmer using the string, and thus irrelevant to him. The person implementing the string storage code can write difficult or complicated (but not unreadable!) code if necessary in order to get efficient strings.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-05 13:01 -0800 |
| Message-ID | <b8fa75a5-1f53-4471-a029-a6b28c8b237e@googlegroups.com> |
| In reply to | #98072 |
On Monday, December 5, 2016 at 3:57:33 PM UTC-5, David Brown wrote: > [snip] I'm perfectly content to agree to disagree where applicable, and walk in agreement where applicable. My goals are to teach other people those things which I believe are proper. If there are areas where you disagree, then teach away as well. :-) Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-05 21:22 +0000 |
| Message-ID | <o24lne$50c$1@dont-email.me> |
| In reply to | #98072 |
On 05/12/2016 20:57, David Brown wrote: > For comparison, gcc supports at least the following targets in mainline: > > arm64, alpha, amd64, arm, avr, blackfin, h8330, hppa, ix86, ia64, > iq2000, lm32, m32c, m32r, m68k, microblaze, mips, nds, nvptx, powerpc, > rs6000 (Isn't that one a car?) > (This is not a condemnation of CAlive - there is no need for a language > to target such a range of architectures. For most processors in current > use, C is the /only/ viable programming language other than assembler. You've illustrated why C can be a good intermediate language. Although, in the absence of any other contender, it could have been much better. It means that 'CAlive' only needs to target C then it can also run on many of those targets, the ones powerful enough anyway. >> 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. > My email program can be too slow (especially when re-organising the > viewing or searching in mail boxes of thousands of emails). Spreadsheet > programs are too slow for some of the tougher calculations I have tried > to run, and certainly far too slow for graphs. Web browsers can be too > slow for some heavy websites. The list goes on - and I have an > expensive modern multi-core cpu with a ridiculous size of memory. It's the software not the hardware. On Windows, you can right-click a file then count slowly to ten before is displays a pop-up with all the options. And it hasn't done any actual work yet! But I don't really think language is the issue here; even scripting languages spend most of their time executing compiled code. It's mostly layers of complexity, size, bloat and inefficiency. > Then of course there are other types of work where computers are never > as fast as you want (at least, not for computers you can afford!), such > as CAD design software, 3D rendering, simulations, etc. I had a CAD product in the 1980s that ran on a Z80 machine! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-06 10:25 +1300 |
| Message-ID | <eam4b5FkmtmU7@mid.individual.net> |
| In reply to | #98083 |
On 12/ 6/16 10:22 AM, BartC wrote: > On 05/12/2016 20:57, David Brown wrote: > >> Then of course there are other types of work where computers are never >> as fast as you want (at least, not for computers you can afford!), such >> as CAD design software, 3D rendering, simulations, etc. > > I had a CAD product in the 1980s that ran on a Z80 machine! But could it auto-route a 64 bit bus on an eight layer board with buried vias? :) -- Ian
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-05 21:36 +0000 |
| Message-ID | <o24mhq$8b5$1@dont-email.me> |
| In reply to | #98085 |
On 05/12/2016 21:25, Ian Collins wrote: > On 12/ 6/16 10:22 AM, BartC wrote: >> On 05/12/2016 20:57, David Brown wrote: >> >>> Then of course there are other types of work where computers are never >>> as fast as you want (at least, not for computers you can afford!), such >>> as CAD design software, 3D rendering, simulations, etc. >> >> I had a CAD product in the 1980s that ran on a Z80 machine! > > But could it auto-route a 64 bit bus on an eight layer board with buried > vias? It wasn't that kind of CAD (more general purpose drafting), but I did use it to draw some of my schematics. Prototypes were hand-wired, but for production boards we paid a guy to do it! I think he did it by hand (double-sided boards). Very good work actually (later we switched to someone much cheaper, and he was hopeless). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-05 22:33 +0100 |
| Message-ID | <o24mcc$7g5$1@dont-email.me> |
| In reply to | #98072 |
Le 05/12/2016 à 21:57, David Brown a écrit : > Do you really think CAlive's targets are similar to C? CAlive is dead. It has never existed, he has no working proto, no nothing. There isn't a single link to some code in a google search. Just Hodgin spreading his vaporware! Why you take seriously this guy?
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-12-05 17:03 -0500 |
| Message-ID | <op.yr0p8urkw6u7nr@rickhodgin.boycesystems.local> |
| In reply to | #98089 |
On Monday, December 5, 2016 at 4:33:25 PM UTC-5, jacobnavia wrote:
> Le 05/12/2016 à 21:57, David Brown a écrit :
> > Do you really think CAlive's targets are similar to C?
>CAlive is dead. It has never existed, he has no working proto, no
> nothing. There isn't a single link to some code in a google search. Just
> Hodgin spreading his vaporware!
I'm working on the full project, Jacob. Currently I am working on the
assembler, and here in the past week or two I've been designing an L1
cache algorithm for my CPU:
https://raw.githubusercontent.com/RickCHodgin/libsf/master/arxoda/arxoda-documentation/images/cache_4read_4write.png
> Why you take seriously this guy?
You will see my product over time, Jacob ... Lord willing (James 4:15).
It's much more comprehensive than just a C-like compiler. I'm working
to create a complete hardware and software stack. Right now I'm
looking at building the graphics card for my CPU. I plan to implement
a 1024 x 768 fixed graphics signal that uses a 640x480 window in the
upper-left which operates on an 8x12 pixel font, creating an 80x40 text
area which my kernel will use. The surrounding right-side and bottom
border areas will be pixel-based using a 256-color palette, allowing
my CPU to have diagnostic information displayed around the edge:
https://s4.postimg.org/4mwle5t4t/svga.png
https://en.wikipedia.org/wiki/Video_Graphics_Array
http://lateblt.tripod.com/bit74.txt
I invite you to come help me develop this project. It is an offering
given over to Jesus Christ because it was He who first gave me these
abilities.
The project could benefit greatly from your high knowledge and
experience, Jacob.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-04 08:57 -0800 |
| Message-ID | <d163a370-acac-4ab9-8900-1048ebaeb539@googlegroups.com> |
| In reply to | #97979 |
On Sunday, December 4, 2016 at 9:34:17 AM UTC-6, David Brown wrote:
> 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").
I think it would also be desirable to allow for functions that accept
strings to be able to accept structures which include a pointer to
string data along with a length, and also to be able to support string
buffers which can report both the length of a string stored therein and
the amount of space available to expand it. The most commonly-quoted
disadvantage of length-prefixed strings compared with zero-terminated
strings is that there's no way to pass a pointer to a substring without
making a copy of it, while zero-terminated strings make it easy to pass
a pointer to all but the first N characters of a string. If functions
that accept strings start with a call to extract the address of the
character data along with the length and buffer size, then one could
easily use code like:
mkmidstring(&my_substring, my_string, 160,80);
putstring(&my_substring);
to produce a substring object pointing to bytes 160-239 of my_string and
pass that to putstr without having to copy the bytes in question, and
without having to use a "special" putstring function (examining the first
byte at the passed-in address would indicate that it was receiving a
substring object rather than a direct pointer to string data).
[toc] | [prev] | [next] | [standalone]
| From | Robert Spanjaard <spamtrap@arumes.com> |
|---|---|
| Date | 2016-12-04 20:19 +0100 |
| Message-ID | <o21q7d$uoi$1@gioia.aioe.org> |
| In reply to | #97979 |
On 04-12-16 16:33, David Brown wrote: > > 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. That depends on what type of data you're going to count. For normal text (books, papers, etc), 16 bit seems to be a sensible length. I never encountered a single paragraph longer than 65535 characters, while paragraphs longer than 255 characters are quite common (seems to be between 15 and 20% based on a quick scan of a couple of random books). In those cases, Jacob's original approach produces the smallest amount of counting data with about 80% 1-byte values and 20% 2-byte values. -- Robert Spanjaard
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-04 20:24 +0100 |
| Message-ID | <o21qfp$uq6$1@dont-email.me> |
| In reply to | #97990 |
On 04/12/16 20:19, Robert Spanjaard wrote: > On 04-12-16 16:33, David Brown wrote: >> > 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. > > That depends on what type of data you're going to count. For normal text > (books, papers, etc), 16 bit seems to be a sensible length. I never > encountered a single paragraph longer than 65535 characters, while > paragraphs longer than 255 characters are quite common (seems to be between > 15 and 20% based on a quick scan of a couple of random books). In those > cases, Jacob's original approach produces the smallest amount of > counting data with about 80% 1-byte values and 20% 2-byte values. > Yes, but supporting three different sizes (8-bit, 16-bit and 32-bit) makes access to all three sizes a little more complicated and less efficient. And an extra couple of bytes on a string in the 255 - 65535 range is a minor cost in space. Also, you need some bits to encode the choice of size - for 8/32, one bit is sufficient and your real sizes are 7-bit and 31-bit. For 8/16/32, you need two bits and your sizes are 6-bit, 14-bit and 30-bit. (More complicated schemes are, of course, perfectly possible - at the cost of more run-time in figuring out the true length of the string.) Still, it all depends on what sort of strings Jacob wants.
[toc] | [prev] | [next] | [standalone]
| From | Robert Spanjaard <spamtrap@arumes.com> |
|---|---|
| Date | 2016-12-04 20:37 +0100 |
| Message-ID | <o21r92$10kd$1@gioia.aioe.org> |
| In reply to | #97992 |
On 04-12-16 20:24, David Brown wrote: >>> I think there is little to be gained by supporting 16-bit length fields. >> >> That depends on what type of data you're going to count. For normal text >> (books, papers, etc), 16 bit seems to be a sensible length. I never >> encountered a single paragraph longer than 65535 characters, while >> paragraphs longer than 255 characters are quite common (seems to be between >> 15 and 20% based on a quick scan of a couple of random books). In those >> cases, Jacob's original approach produces the smallest amount of >> counting data with about 80% 1-byte values and 20% 2-byte values. >> > > Yes, but supporting three different sizes (8-bit, 16-bit and 32-bit) > makes access to all three sizes a little more complicated and less > efficient. And an extra couple of bytes on a string in the 255 - 65535 > range is a minor cost in space. Also, you need some bits to encode the > choice of size - for 8/32, one bit is sufficient and your real sizes are > 7-bit and 31-bit. For 8/16/32, you need two bits and your sizes are > 6-bit, 14-bit and 30-bit. (More complicated schemes are, of course, > perfectly possible - at the cost of more run-time in figuring out the > true length of the string.) Again, for normal text files, supporting 32 bit doesn't make sense. > Still, it all depends on what sort of strings Jacob wants. That's what I said at the start of my reply, and everything I said afterwards is based on the 'normal text'-type of string. -- Robert Spanjaard
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-04 21:04 +0100 |
| Message-ID | <o21sq1$7rd$1@dont-email.me> |
| In reply to | #97993 |
On 04/12/16 20:37, Robert Spanjaard wrote: > On 04-12-16 20:24, David Brown wrote: >>>> I think there is little to be gained by supporting 16-bit length >>>> fields. >>> >>> That depends on what type of data you're going to count. For normal text >>> (books, papers, etc), 16 bit seems to be a sensible length. I never >>> encountered a single paragraph longer than 65535 characters, while >>> paragraphs longer than 255 characters are quite common (seems to be >>> between >>> 15 and 20% based on a quick scan of a couple of random books). In those >>> cases, Jacob's original approach produces the smallest amount of >>> counting data with about 80% 1-byte values and 20% 2-byte values. >>> >> >> Yes, but supporting three different sizes (8-bit, 16-bit and 32-bit) >> makes access to all three sizes a little more complicated and less >> efficient. And an extra couple of bytes on a string in the 255 - 65535 >> range is a minor cost in space. Also, you need some bits to encode the >> choice of size - for 8/32, one bit is sufficient and your real sizes are >> 7-bit and 31-bit. For 8/16/32, you need two bits and your sizes are >> 6-bit, 14-bit and 30-bit. (More complicated schemes are, of course, >> perfectly possible - at the cost of more run-time in figuring out the >> true length of the string.) > > Again, for normal text files, supporting 32 bit doesn't make sense. Even then, it depends on what you are doing. If you are writing a "less" or "grep" utility, then storing everything as a single big string makes sense - and you'd need more than 16-bit. If you are writing a word processor, you might want chains of paragraphs for which 16-bit is more than enough. I don't think there is really such a thing as "normal text files", and certainly not a "normal" way to treat them. > >> Still, it all depends on what sort of strings Jacob wants. > > That's what I said at the start of my reply, and everything I said > afterwards is based on the 'normal text'-type of string. > Fair enough.
[toc] | [prev] | [next] | [standalone]
| From | Robert Spanjaard <spamtrap@arumes.com> |
|---|---|
| Date | 2016-12-04 21:22 +0100 |
| Message-ID | <o21ttc$15ck$1@gioia.aioe.org> |
| In reply to | #97994 |
On 04-12-16 21:04, David Brown wrote: >>> Yes, but supporting three different sizes (8-bit, 16-bit and 32-bit) >>> makes access to all three sizes a little more complicated and less >>> efficient. And an extra couple of bytes on a string in the 255 - 65535 >>> range is a minor cost in space. Also, you need some bits to encode the >>> choice of size - for 8/32, one bit is sufficient and your real sizes are >>> 7-bit and 31-bit. For 8/16/32, you need two bits and your sizes are >>> 6-bit, 14-bit and 30-bit. (More complicated schemes are, of course, >>> perfectly possible - at the cost of more run-time in figuring out the >>> true length of the string.) >> >> Again, for normal text files, supporting 32 bit doesn't make sense. > > Even then, it depends on what you are doing. If you are writing a > "less" or "grep" utility, then storing everything as a single big string > makes sense - and you'd need more than 16-bit. For single-string applications like grep or less trying to save a byte or two in the counting data doesn't make much sense. :) -- Robert Spanjaard
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-04 22:37 +0000 |
| Message-ID | <o225od$8n4$1@dont-email.me> |
| In reply to | #97996 |
On 04/12/2016 20:22, Robert Spanjaard wrote:
> On 04-12-16 21:04, David Brown wrote:
>>>> Yes, but supporting three different sizes (8-bit, 16-bit and 32-bit)
>>>> makes access to all three sizes a little more complicated and less
>>>> efficient. And an extra couple of bytes on a string in the 255 - 65535
>>>> range is a minor cost in space. Also, you need some bits to encode the
>>>> choice of size - for 8/32, one bit is sufficient and your real sizes
>>>> are
>>>> 7-bit and 31-bit. For 8/16/32, you need two bits and your sizes are
>>>> 6-bit, 14-bit and 30-bit. (More complicated schemes are, of course,
>>>> perfectly possible - at the cost of more run-time in figuring out the
>>>> true length of the string.)
>>>
>>> Again, for normal text files, supporting 32 bit doesn't make sense.
>>
>> Even then, it depends on what you are doing. If you are writing a
>> "less" or "grep" utility, then storing everything as a single big string
>> makes sense - and you'd need more than 16-bit.
>
> For single-string applications like grep or less trying to save a byte or
> two in the counting data doesn't make much sense. :)
I don't know that the OP had it mind for counted strings; whether as a
library idea or to be added to the language.
But suppose you had a layout like this:
struct {
char barcode[16];
char descr[32]
char categorycode[6];
char suppliercode[4];
char info [14];
char tariff[12];
} ...
If you wanted counted strings for these fields, you don't really want a
32- or 64-bit count as part of the space available for the string
(especially for those 6- and 4-char fields!).
Even the zero terminator is unwelcome, as it means, if you need a string
that can be up to 4 characters long, that you need to set aside 5 bytes.
That can upset the alignment of neighbouring numeric fields and lead to
padding bytes, wasting even more space.
(The way I do this in some apps makes available all the characters in
the field with a couple of techniques, one of which uses a count.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Thompson <dave.thompson2@verizon.net> |
|---|---|
| Date | 2016-12-10 22:42 -0500 |
| Message-ID | <dlip4c992bgea5s9otl1gh843hbjinr26b@4ax.com> |
| In reply to | #97996 |
On Sun, 4 Dec 2016 21:22:04 +0100, Robert Spanjaard <spamtrap@arumes.com> wrote: > On 04-12-16 21:04, David Brown wrote: <snip> > >> Again, for normal text files, supporting 32 bit doesn't make sense. > > > > Even then, it depends on what you are doing. If you are writing a > > "less" or "grep" utility, then storing everything as a single big string > > makes sense - and you'd need more than 16-bit. > > For single-string applications like grep or less trying to save a byte or > two in the counting data doesn't make much sense. :) grep by default looks at one _line_ (except for GNU with -z) although it sometimes needs to store more (with -B). less needs to store the entire stream (at least if unseekable) but also access any line randomly (or near enough), so a single huge string wouldn't be suitable.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-10 23:17 -0800 |
| Message-ID | <0931e338-1597-4a9d-9c1d-725d06af4eaf@googlegroups.com> |
| In reply to | #98755 |
On Sunday, December 11, 2016 at 3:42:24 AM UTC, David Thompson wrote: > On Sun, 4 Dec 2016 21:22:04 +0100, Robert Spanjaard > <spamtrap@arumes.com> wrote: > > > On 04-12-16 21:04, David Brown wrote: > <snip> > > >> Again, for normal text files, supporting 32 bit doesn't make sense. > > > > > > Even then, it depends on what you are doing. If you are writing a > > > "less" or "grep" utility, then storing everything as a single big string > > > makes sense - and you'd need more than 16-bit. > > > > For single-string applications like grep or less trying to save a byte or > > two in the counting data doesn't make much sense. :) > > grep by default looks at one _line_ (except for GNU with -z) although > it sometimes needs to store more (with -B). > > less needs to store the entire stream (at least if unseekable) but > also access any line randomly (or near enough), so a single huge > string wouldn't be suitable. > Paris japonica has a genome of 150 billion base pairs. So a long string.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-11 11:48 +0000 |
| Message-ID | <87mvg2znxb.fsf@bsb.me.uk> |
| In reply to | #98756 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: <snipped: discussion of plausible string lengths and how to encode them> > Paris japonica has a genome of 150 billion base pairs. So a long > string. What's the reason to concatenate the chromosomes? To the uninitiated, a genome is, in abstract, several strings rather than one. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-11 04:40 -0800 |
| Message-ID | <f83ed86c-2858-4f50-a02a-bcb356348cda@googlegroups.com> |
| In reply to | #98783 |
On Sunday, December 11, 2016 at 11:48:54 AM UTC, Ben Bacarisse wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > <snipped: discussion of plausible string lengths and how to encode them> > > > Paris japonica has a genome of 150 billion base pairs. So a long > > string. > > What's the reason to concatenate the chromosomes? To the uninitiated, a > genome is, in abstract, several strings rather than one. > It is, and usually data will be presented as you say. But during evolution, chromosomal rearrangement is quite common (by which I mean that out of a population of a million plants, it might occur once in a million years, and the offspring survive). So we could easily find that a relative has one fewer chromosomes, and in fact what has happened is that one of our chromosomes has split in half and then attached itself. So there's a need to be able to join and split the strings. The another problem is that sequencing technology often won't give you the highly reptitive areas at the ends of the chromosomes. You get a sort of giant jigsaw, with all of the protein-coding genes (as far as we understand) retrievable by piecing short reads together. That gives you thousands of short sequences (contigs), which you might want to arrange in a putative order by using a related organism as a "scaffold". Data could well go through a stage where everything is one string. It's surprisingly difficult to karyotype organisms, that is determine the number of chromosomes. The count for humans was wrong for many years. Whilst you can sequence the DNA relatively easily now, it's a lot harder to manipulate it physically.
[toc] | [prev] | [next] | [standalone]
| From | Robert Spanjaard <spamtrap@arumes.com> |
|---|---|
| Date | 2016-12-11 10:56 +0100 |
| Message-ID | <o2j7s4$r8c$1@gioia.aioe.org> |
| In reply to | #98755 |
On 11-12-16 04:42, David Thompson wrote: >> For single-string applications like grep or less trying to save a byte or >> two in the counting data doesn't make much sense. :) > > grep by default looks at one _line_ (except for GNU with -z) although > it sometimes needs to store more (with -B). > > less needs to store the entire stream (at least if unseekable) but > also access any line randomly (or near enough), so a single huge > string wouldn't be suitable. I suspected that, but that was beside the main point (of counting the string length on a single big string), so didn't feel the need to bring it up. In general I think most shell-programs will work on as little data at a time as possible. It reduces memory requirements (which was a big issue in early Unix and Linux days) and increases performance when pipelining. When a process reads the entire text as a single big string, the pipepile will halt on that process until it has received all the data. That's not supposed to happen. -- Robert Spanjaard
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-05 15:47 -0600 |
| Message-ID | <2nnb4c9oepasd6vesaktt446ob0mal8ott@4ax.com> |
| In reply to | #97990 |
On Sun, 4 Dec 2016 20:19:09 +0100, Robert Spanjaard <spamtrap@arumes.com> wrote: >On 04-12-16 16:33, David Brown wrote: >> > 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. > >That depends on what type of data you're going to count. For normal text >(books, papers, etc), 16 bit seems to be a sensible length. I never >encountered a single paragraph longer than 65535 characters, Penelope in Ulysses? (Joyce).
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web