Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #140005 > unrolled thread
| Started by | Bart <bc@freeuk.com> |
|---|---|
| First post | 2019-01-20 00:03 +0000 |
| Last post | 2019-01-21 00:13 -0600 |
| Articles | 20 on this page of 160 — 17 participants |
Back to article view | Back to comp.lang.c
Compiler tests Bart <bc@freeuk.com> - 2019-01-20 00:03 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-20 16:52 +1300
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-20 10:27 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-20 12:37 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 13:08 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 15:02 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-20 17:31 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 17:08 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-20 21:40 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 22:41 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 00:39 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 00:36 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-21 16:33 +1300
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 11:58 +0000
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-21 04:15 -0800
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-22 07:53 +1300
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-23 01:15 -0600
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 12:00 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-24 08:13 +1300
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-23 13:30 -0600
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 08:22 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 12:23 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 14:42 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 14:17 +0000
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-21 12:46 -0800
You guys really, really need to get a room (Was: Compiler tests) gazelle@shell.xmission.com (Kenny McCormack) - 2019-01-24 14:05 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-20 17:27 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 17:19 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 09:44 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 12:49 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 15:31 +0100
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-21 14:38 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-21 15:15 +0100
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-21 16:05 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 16:39 +0100
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-21 12:51 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 00:16 +0000
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-22 08:43 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 12:31 +0000
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-22 17:49 +0100
Re: Compiler tests jacobnavia <jacob@jacob.remcomp.fr> - 2019-01-23 11:04 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 11:18 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-21 15:35 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-21 15:49 +0000
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-21 17:42 +0100
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-23 03:18 -0600
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 11:11 +0100
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-23 12:18 -0600
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 13:56 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-22 10:55 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 12:07 +0000
Re: Compiler tests fir <profesor.fir@gmail.com> - 2019-01-22 04:29 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 12:52 +0000
Re: Compiler tests mark.bluemel@gmail.com - 2019-01-22 05:04 -0800
Re: Compiler tests fir <profesor.fir@gmail.com> - 2019-01-22 05:18 -0800
Re: Compiler tests fir <profesor.fir@gmail.com> - 2019-01-22 05:45 -0800
Re: Compiler tests fir <profesor.fir@gmail.com> - 2019-01-22 05:35 -0800
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-22 15:10 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 17:30 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-22 23:02 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-22 23:14 +0000
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-22 15:45 -0800
Re: Compiler tests Robert Wessel <robertwessel2@yahoo.com> - 2019-01-22 17:57 -0600
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-22 16:36 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 01:37 +0000
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-22 18:53 -0800
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 09:42 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 09:22 +0100
Re: Compiler tests James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-23 08:52 -0500
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 15:13 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 14:33 +0000
Re: Compiler tests James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-23 07:30 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 16:05 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 17:17 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 16:29 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 22:04 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 21:50 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 10:45 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 11:55 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 13:58 +0100
Re: Compiler tests mark.bluemel@gmail.com - 2019-01-24 05:07 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 14:10 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 14:18 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 15:51 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 15:44 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 17:32 +0000
Re: Compiler tests scott@slp53.sl.home (Scott Lurndal) - 2019-01-24 19:07 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 20:14 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 22:24 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-24 22:46 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-25 12:34 +1300
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 01:01 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-25 14:15 +1300
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 10:05 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 14:51 +0000
Re: Compiler tests Mateusz Viste <mateusz@wont.tell> - 2019-01-25 09:48 +0000
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 10:56 +0100
Re: Compiler tests Mateusz Viste <mateusz@wont.tell> - 2019-01-25 12:08 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 13:28 +0100
Re: Compiler tests Mateusz Viste <mateusz@wont.tell> - 2019-01-25 13:33 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 15:38 +0100
Re: Compiler tests Mateusz Viste <mateusz@wont.tell> - 2019-01-25 15:08 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 13:53 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 12:25 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 10:03 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 10:08 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 11:14 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 12:02 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 13:37 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 13:58 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 14:26 +0100
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 15:01 +0100
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 15:42 +0100
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-25 10:25 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 14:37 +0000
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 16:33 +0100
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-25 07:44 -0800
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 17:53 +0100
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-25 10:33 -0800
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 20:43 +0100
Re: Compiler tests Keith Thompson <kst-u@mib.org> - 2019-01-25 12:17 -0800
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 18:31 +0000
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 20:41 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 21:19 +0000
Re: Compiler tests Ian Collins <ian-news@hotmail.com> - 2019-01-26 10:24 +1300
Re: Compiler tests "Pascal J. Bourguignon" <pjb@informatimago.com> - 2019-01-25 22:27 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 22:39 +0000
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-25 18:46 +0000
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 12:43 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 14:37 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 14:19 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 15:47 +0100
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-25 07:17 -0800
Re: Compiler tests Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-02-03 07:28 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-02-03 12:35 +0100
Re: Compiler tests Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-02-03 21:47 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-02-03 22:57 +0100
Re: Compiler tests Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-01-24 06:47 -0800
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-23 20:22 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 22:12 +0100
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-23 21:54 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-24 11:41 +0100
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-24 23:17 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 11:11 +0100
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-25 12:04 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 14:05 +0100
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-25 18:40 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-25 22:36 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-25 22:15 +0000
Re: Compiler tests scott@slp53.sl.home (Scott Lurndal) - 2019-01-25 14:48 +0000
Re: Compiler tests scott@slp53.sl.home (Scott Lurndal) - 2019-01-25 14:46 +0000
Re: Compiler tests Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-01-25 17:48 +0000
Re: Compiler tests James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-01-23 08:23 -0800
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 16:41 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 16:18 +0000
Re: Compiler tests David Brown <david.brown@hesbynett.no> - 2019-01-23 17:28 +0100
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-23 20:23 +0000
Re: Compiler tests Robert Wessel <robertwessel2@yahoo.com> - 2019-01-22 17:52 -0600
Re: Compiler tests Bart <bc@freeuk.com> - 2019-01-20 20:17 +0000
Re: Compiler tests BGB <cr88192@hotmail.com> - 2019-01-21 00:13 -0600
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-21 08:22 +0100 |
| Message-ID | <q23s09$pt3$1@dont-email.me> |
| In reply to | #140041 |
On 21/01/2019 01:36, Bart wrote: > On 20/01/2019 23:39, David Brown wrote: >> On 20/01/2019 23:41, Bart wrote: > >> And to spoon-feed you the point, your absurd "test" files bear no >> relation to real source files that people want to compile. If you >> want useful results from tests, you have to test with realistic >> cases. So your stream of bytes for networking will be real test data, >> or perhaps random data, not a million zero bytes. Your graphics test >> scenes will be real pictures, not a blank window. > > I can see you've done very little performance optimisation, or you > haven't done it very well. Yes, I have done lots of performance optimisation - and done it well. Just as there is a very wide range of types of coding, so is there a very wide range of types of optimisation. > >> So if you want to test speed of compilation, use real code. > > That will depend on a million factors which all add up. Where do you > start? As soon as you isolate one small part, you find that not enough > real data exists to give meaningful timings. So you have to duplicate > input in a way that doesn't happen in real data. No, you can use larger real sources. With code for testing a compiler, if you duplicate the data you will significantly affect the results of the testing - a file with a hundred different functions can be totally different from a file with a hundred identical functions. If you were testing a compression algorithm, would you start with a 10K text file? Perhaps. Would you then combine a hundred copies of that and consider it a good test of a 1 MB text file? > > Suppose my program is a console text editor but the refresh (say on page > down) appears sluggish. > > How would you go about making it a bit faster, where would you start? > > I would do it by a test program that writes a screenful of data - any > data - then repeats that N times, say 100 times. > > I can measure how long that takes, and that gives me a figure to compare > against. Then I can proceed to find any bottlenecks, try different > approaches, to see what makes a difference. > > You, however, would say that is not real data and that no real program > would just flash 100 screenfuls of nonsense one after the other. > > So, what would YOU do? I'd find appropriate test cases for the task in hand, whatever that might be. I certainly wouldn't claim I could determine a good choice of performance testing and measurement methodology based on a single sentence of specification. > >> Now, there /are/ languages and projects for which compile speed is >> important. Most obviously, for C++ code with a lot of template >> libraries, compile speed is a big issue. Tell me, how fast does your >> compiler work for big C++ projects with lots of template libraries? >> Once you've got that working, and can show comparisons to other >> compilers using real-world source code, /then/ you'll have something >> that will be of interest. > > I don't use C++. I design languages specifically to be easy to use and > to build compilers for. And for my purposes that works admirably: You do realise that the speed of compilation is /not/ the benchmark for judging how "admirably" a compiler works? Your compiler may well be "admirable", or at least perfectly good, within its limitations and for its expected use. But your obsession with speed distracts you from other functions of a compiler.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-21 12:23 +0000 |
| Message-ID | <qRi1E.98781$UF1.49287@fx13.am4> |
| In reply to | #140045 |
On 21/01/2019 07:22, David Brown wrote: > On 21/01/2019 01:36, Bart wrote: > If you were testing a compression algorithm, would you start with a 10K > text file? Perhaps. Would you then combine a hundred copies of that > and consider it a good test of a 1 MB text file? It depends whether the aspect you're testing is sensitive to the repetitive nature of the input or not. >> I don't use C++. I design languages specifically to be easy to use and >> to build compilers for. And for my purposes that works admirably: > > You do realise that the speed of compilation is /not/ the benchmark for > judging how "admirably" a compiler works? Your compiler may well be > "admirable", or at least perfectly good, within its limitations and for > its expected use. But your obsession with speed distracts you from > other functions of a compiler. Would you buy a car that has all the attributes and extras that you want, but can't manage faster than walking pace? Would your insistence that it can at least do 30mph mean that you're obsessed with speed? That is how those other compilers seem to me. And many appear as cumbersome as driving a 40-ton lorry.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-21 14:42 +0100 |
| Message-ID | <q24i7f$t6m$1@dont-email.me> |
| In reply to | #140051 |
On 21/01/2019 13:23, Bart wrote: > On 21/01/2019 07:22, David Brown wrote: >> On 21/01/2019 01:36, Bart wrote: > >> If you were testing a compression algorithm, would you start with a >> 10K text file? Perhaps. Would you then combine a hundred copies of >> that and consider it a good test of a 1 MB text file? > > It depends whether the aspect you're testing is sensitive to the > repetitive nature of the input or not. > My example was a compression algorithm. A compression algorithm that is insensitive to the repetitive nature of the input would not be very useful. More generally, the point was to use appropriate test cases. > >>> I don't use C++. I design languages specifically to be easy to use >>> and to build compilers for. And for my purposes that works admirably: >> >> You do realise that the speed of compilation is /not/ the benchmark >> for judging how "admirably" a compiler works? Your compiler may well >> be "admirable", or at least perfectly good, within its limitations and >> for its expected use. But your obsession with speed distracts you >> from other functions of a compiler. > > Would you buy a car that has all the attributes and extras that you > want, but can't manage faster than walking pace? I'd prefer it to one that can reach 300 mph but has no breaks. > > Would your insistence that it can at least do 30mph mean that you're > obsessed with speed? > Here your analogy breaks down. Learn to use a build process that uses four cpu cores at the same time, and your compilation is now going at 120 mph. That's more than fast enough for most roads. > That is how those other compilers seem to me. And many appear as > cumbersome as driving a 40-ton lorry.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-21 14:17 +0000 |
| Message-ID | <Rvk1E.147845$XD1.2818@fx33.am4> |
| In reply to | #140059 |
On 21/01/2019 13:42, David Brown wrote: > On 21/01/2019 13:23, Bart wrote: >> Would you buy a car that has all the attributes and extras that you >> want, but can't manage faster than walking pace? > > I'd prefer it to one that can reach 300 mph but has no breaks. > >> >> Would your insistence that it can at least do 30mph mean that you're >> obsessed with speed? >> > > Here your analogy breaks down. Learn to use a build process that uses > four cpu cores at the same time, and your compilation is now going at > 120 mph. That's more than fast enough for most roads. That means your 3mph compiler now manages an effective 12mph. While there's no reason why four cores couldn't be applied to compilers like tcc (or bcc) so that /they/ are the ones managing an effective 120mph. There is still the same disparity. But multi-cores are not always easy to apply unless you are always compiling 4 large modules of comparable size. Much better to have something that runs fast even on one core. Anyway, my original post wasn't so much about speed. It was using timing as one measure of the ability to cope with extreme inputs. Another was the amount of memory used, although it only reported any failure. And yet another was the ability to finish at all. But where it worked, then yes it's nicer if you don't have to wait around too long.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-01-21 12:46 -0800 |
| Message-ID | <96e05b63-eecb-4a79-9dd9-7be81687d640@googlegroups.com> |
| In reply to | #140059 |
On Monday, 21 January 2019 13:42:15 UTC, David Brown wrote: > > > It depends whether the aspect you're testing is sensitive to the > > repetitive nature of the input or not. > > > > My example was a compression algorithm. A compression algorithm that is > insensitive to the repetitive nature of the input would not be very > useful. > Depends. If we know that data is likely to be ten identical chapters of text concatenated, then we can of course get compression to 10% plus a little bit of overall size, very easily. But real texts are seldom structured like that, and the test isn't terribly sensible except as an informal run to see if behaviour is as we expect. We need to test on text which repeat words and phrases, but not sentences or higher-level grammar structures, if we are to assess a text compressor fairly.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2019-01-24 14:05 +0000 |
| Subject | You guys really, really need to get a room (Was: Compiler tests) |
| Message-ID | <q2cgn5$vn6$1@news.xmission.com> |
| In reply to | #140034 |
In article <q230r4$ues$1@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote a bunch of psychotic crap: ... >I don't diss everything you do - ... Of course you do. I really don't think there is any need for you guys to continue to air your lover's quarrels in public. Do you? -- The key difference between faith and science is that in science, evidence that doesn't fit the theory tends to weaken the theory (that is, make it less likely to be believed), whereas in faith, contrary evidence just makes faith stronger (on the assumption that Satan is testing you - trying to make you abandon your faith).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-20 17:27 +0100 |
| Message-ID | <q227i9$r1s$1@dont-email.me> |
| In reply to | #140013 |
On 20/01/2019 14:08, Bart wrote:
> On 20/01/2019 11:37, David Brown wrote:
>> On 20/01/2019 10:27, Pascal J. Bourguignon wrote:
>
>>> Well, obviously some compilers try to optimize duplicate expressions,
>>> and get lost in the number of them. Not a realistic test, but
>>> definitely a good try-to-break-the-compiler test.
>>>
>>
>> Unfortunately for Bart, compilers are usually targeted to real code.
>> And in real code, duplicate expressions and structures /do/ turn up
>> (especially in template-based C++ coding), and optimising them is very
>> important to the efficiency of the code generation.
>
> Except that the problem timings were with /unoptimised/ compiles. With
> optimisation enabled, they were much faster.
>
Surely you don't /still/ think that optimisation is a black-or-white
issue, where compilers do things one way for "unoptimised" compiles with
/no/ "optimisations", and a different way for "optimised" compiles ?
Compilers "optimise" in many ways, regardless of the settings.
> But meaningless
>> mass copying of the same code does not turn up in real code, and
>> compiler writers don't particularly care about the results.
>>
>> This means that Bart's simplistic compiler can do a better job than
>> real compilers at this kind of meaningless artificial benchmark, and
>> he likes to trump it as "proof" that his tool is great and gcc is
>> terrible. It's a common theme for him, and it is no more useful now
>> than it was the past dozen times he presented this.
>>
>>
>> There /are/ issues with gcc compiling very large functions (in
>> particular, it takes a huge amount of memory), there are real
>> use-cases (such as for simulators), and there is work being done to
>> improve things. I don't know the current state.
>
> Here's another test where each line is in a separate function:
>
> void f1(void) {int a,b=2,c=3,d=4; a=b+c*d;}
> void f2(void) {int a,b=2,c=3,d=4; a=b+c*d;}
> void f3(void) {int a,b=2,c=3,d=4; a=b+c*d;}
> void f4(void) {int a,b=2,c=3,d=4; a=b+c*d;}
> ....
>
> And here are some quick results:
>
> 20K 100K
> Pelles C T/O ---
> lccwin 13.0 T/O seconds to compile
> dmc 0.4 OOM
> gcc 25.0 307.0
> gcc opt 39.0 ---
> tiny c 0.2 0.7
> msvc 3.0 34.0
> clang 6.3 30.0
> (bcc 0.3 1.6)
>
> They still seem to fare very differently.
Again, so what? If these tests help you improve your own tools in ways
that you want, then great. But it means nothing to anyone else.
>
> This test was useful in that it highlighted a problem with my bcc, which
> suffers from using a fixed-size hashtable for the main symbol table. The
> 1.6 figure is after tweaking the size. I will to change it to adapt as
> needed.
>
> However, bcc generates .asm, and my assembler for that has its own hard
> limit of 64K entries that can't be so easily changed, but it will have
> to in order to create an exe from this.
>
> Why does gcc's speed get slower non-linearly compared with clang? Maybe
> it could also have issues that need looking at. It seemed to spend an
> awfully long time running 'as'.
There can be many reasons for speed scaling in terms of number of lines
or number of functions. Compilers do various kinds of inter-procedural
optimisations, duplication detection and elimination (including partial
matches), re-ordering of functions to improve caching, etc. Some of
these will be applied even when you have not given command-line switches
for optimisations, others will depend on the switches.
But none of it matters in the slightest with such artificial and
unrealistic tests.
>
> (I would like to see one of your test-suites where every single test
> program is useful real-life code.)
There is nothing wrong with tests being somewhat artificial - there /is/
something wrong with them being so completely out of the ballpark that
they are from a different planet.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-20 17:19 +0000 |
| Message-ID | <y421E.109019$ns2.47564@fx26.am4> |
| In reply to | #140019 |
On 20/01/2019 16:27, David Brown wrote: > On 20/01/2019 14:08, Bart wrote: >> On 20/01/2019 11:37, David Brown wrote: >>> On 20/01/2019 10:27, Pascal J. Bourguignon wrote: >> >>>> Well, obviously some compilers try to optimize duplicate expressions, >>>> and get lost in the number of them. Not a realistic test, but >>>> definitely a good try-to-break-the-compiler test. >>>> >>> >>> Unfortunately for Bart, compilers are usually targeted to real code. >>> And in real code, duplicate expressions and structures /do/ turn up >>> (especially in template-based C++ coding), and optimising them is >>> very important to the efficiency of the code generation. >> >> Except that the problem timings were with /unoptimised/ compiles. With >> optimisation enabled, they were much faster. >> > > Surely you don't /still/ think that optimisation is a black-or-white > issue, The conjecture was that the rapid slowdown was because of looking for common sub-expressions. Since optimisation was off, that would be less likely to be the cause. Note that clang performed much better than gcc in the test, for unoptimised compiles. There might be reasons for that that are easy to fix. But the real problem might be that there is no one at gcc looking into such things. >> Pelles C T/O --- >> lccwin 13.0 T/O seconds to compile >> dmc 0.4 OOM >> gcc 25.0 307.0 >> gcc opt 39.0 --- >> tiny c 0.2 0.7 >> msvc 3.0 34.0 >> clang 6.3 30.0 >> (bcc 0.3 1.6) >> >> They still seem to fare very differently. > > Again, so what? If these tests help you improve your own tools in ways > that you want, then great. But it means nothing to anyone else. Really? Pelles C took 4000 times as long as DMC. That suggests an issue that ought to be fixed. One that /could/ come up in real programs one day. I've already mentioned about gcc's 307 seconds in another thread. I mean, just compare gcc and tcc: the latter is usually acknowledged to compile quicker and generate slower code, especially when gcc uses -O3 , but 400 times slower to compile and still end up with code as slow as tcc? (I used to have a problem with a test like this, when there were very large numbers of similar identifiers. Things got very slow. It turned out to be a poor hashing function. But I wouldn't have discovered it otherwise.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-21 09:44 +0100 |
| Message-ID | <q240pf$ips$1@dont-email.me> |
| In reply to | #140025 |
On 20/01/2019 18:19, Bart wrote: > On 20/01/2019 16:27, David Brown wrote: >> On 20/01/2019 14:08, Bart wrote: >>> On 20/01/2019 11:37, David Brown wrote: >>>> On 20/01/2019 10:27, Pascal J. Bourguignon wrote: >>> >>>>> Well, obviously some compilers try to optimize duplicate expressions, >>>>> and get lost in the number of them. Not a realistic test, but >>>>> definitely a good try-to-break-the-compiler test. >>>>> >>>> >>>> Unfortunately for Bart, compilers are usually targeted to real code. >>>> And in real code, duplicate expressions and structures /do/ turn up >>>> (especially in template-based C++ coding), and optimising them is >>>> very important to the efficiency of the code generation. >>> >>> Except that the problem timings were with /unoptimised/ compiles. >>> With optimisation enabled, they were much faster. >>> >> >> Surely you don't /still/ think that optimisation is a black-or-white >> issue, > > The conjecture was that the rapid slowdown was because of looking for > common sub-expressions. Since optimisation was off, that would be less > likely to be the cause. Optimisations are not an on/off thing. Compilers do lots of optimisations, even when you have "-O0" (or whatever). They also do lots of analysis. And some of that process may scale badly with the size of function, and the size of expressions, and may or may not be worse for repeated identical expressions. You might even find that for some tests, optimised compilation (i.e., where you have asked the compiler for greater effort) are faster because stronger analysis allows more code elimination. So gcc may well analyse for common sub-expressions even when not optimising - it certainly does /some/ analysis. The one thing I know (since I have seen bug reports about it) that affects gcc speed on large functions is register allocation. gcc will attempt to optimise the use of registers throughout the function. This certainly is an issue with large functions when optimising - I don't know if it applies for -O0 code. And it is certainly something that has been improved in later gcc versions (as always, you have omitted the gcc version in your posts). > > Note that clang performed much better than gcc in the test, for > unoptimised compiles. There might be reasons for that that are easy to > fix. But the real problem might be that there is no one at gcc looking > into such things. > >>> Pelles C T/O --- >>> lccwin 13.0 T/O seconds to compile >>> dmc 0.4 OOM >>> gcc 25.0 307.0 >>> gcc opt 39.0 --- >>> tiny c 0.2 0.7 >>> msvc 3.0 34.0 >>> clang 6.3 30.0 >>> (bcc 0.3 1.6) >>> >>> They still seem to fare very differently. >> >> Again, so what? If these tests help you improve your own tools in >> ways that you want, then great. But it means nothing to anyone else. > > Really? Pelles C took 4000 times as long as DMC. That suggests an issue > that ought to be fixed. One that /could/ come up in real programs one day. No, it suggests that Pelles C is not a good choice for compiling huge functions full of duplicate statements. It does /not/ suggest an issue that ought to be fixed unless compiling such functions is a reasonable use-case for that compiler. And do you think your test functions are typical use-cases of typical Pelles C users? Don't get me wrong here - I think it is a good thing for compilers to be able to handle large source efficiently, of whatever kind. But I don't think it is a sensible priority. To put it in very simplistic terms, it is probably easy (relatively speaking) to make a compiler that has O(n) performance in the number of lines/statements/expressions in a function. That could be done with a "direct translation" compilation, and give fast compiles for your test code. On the other hand, analysing the source to give better quality output (object code and/or warnings) might be O(n²). That would be fast enough for normal sized functions, but be miserable on your artificial test functions. But that algorithm is not an "issue that ought to be fixed" - it is a /good/ choice, giving better results for real users and real code. Optimising for an artificial benchmark would be to the detriment of the real use of the tool. Of course, it would be possible to have a hybrid compiler - switching from the O(n²) algorithm to the O(n) algorithm at a certain size of function. That would give you the best of both worlds - except that it would complicate and enlarge the compiler, meaning more development effort and a greater risk of errors. Compilers are tools for a handling certain kinds of tasks. Sometimes that is just "turn this source code into object code". Sometimes it is "give me the fastest possible code from this source code". Often it is "help me write correct code" (that is a key reason I prefer gcc). It is /never/ "compile this million line artificial function as fast as possible". So why should any compiler writer put effort into achieving this last goal? They might happen to achieve it as a side effect of other work, but it should not be a goal in itself. > > I've already mentioned about gcc's 307 seconds in another thread. > > I mean, just compare gcc and tcc: the latter is usually acknowledged to > compile quicker and generate slower code, especially when gcc uses -O3 , > but 400 times slower to compile and still end up with code as slow as tcc? > > (I used to have a problem with a test like this, when there were very > large numbers of similar identifiers. Things got very slow. It turned > out to be a poor hashing function. But I wouldn't have discovered it > otherwise.) > >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-21 12:49 +0000 |
| Message-ID | <6dj1E.122672$592.51277@fx16.am4> |
| In reply to | #140046 |
On 21/01/2019 08:44, David Brown wrote: > On 20/01/2019 18:19, Bart wrote: >> Really? Pelles C took 4000 times as long as DMC. It was 1000 times as long: 400 seconds vs. 0.4 seconds. That suggests an issue >> that ought to be fixed. One that /could/ come up in real programs one day. > > No, it suggests that Pelles C is not a good choice for compiling huge > functions full of duplicate statements. It does /not/ suggest an issue > that ought to be fixed unless compiling such functions is a reasonable > use-case for that compiler. It took 400 seconds for 20Klines, and 10 seconds for 10Klines. That DOES suggest an issue. Maybe to do with a hashtable getting very full (although 20K identifiers isn't a lot), but that's for the developers to sort out. > And do you think your test functions are > typical use-cases of typical Pelles C users? If the problem is the number of symbols, then it can well be an issue. We don't know. If it was my compiler, I would certainly want to know what is happening. > Don't get me wrong here - I think it is a good thing for compilers to be > able to handle large source efficiently, of whatever kind. But I don't > think it is a sensible priority. I wrote a year or two ago about problems with Nasm, getting exponentially slower as programs got bigger. Perhaps one minute to compiler 70Kloc, which is not a lot. It came up for me because my compiler generated one .asm file for a while program. But taking 1000 times as long to assemble the input as my compiler took to generate it was totally impractical. Something was wrong. And it still is. (I no longer use Nasm.) > To put it in very simplistic terms, it is probably easy (relatively > speaking) to make a compiler that has O(n) performance in the number of > lines/statements/expressions in a function. (Yes, that's what fir says. He can't see any reason why you can't write a 10M lines per second compiler, or why it should take more than a couple of days.) > Compilers are tools for a handling certain kinds of tasks. Sometimes > that is just "turn this source code into object code". Sometimes it is > "give me the fastest possible code from this source code". Often it is > "help me write correct code" (that is a key reason I prefer gcc). It is > /never/ "compile this million line artificial function as fast as > possible". So why should any compiler writer put effort into achieving > this last goal? The idea of the million-line function and other such tests is to highlight and detect any possible inefficiency in a compilers. Suppose gcc DID include some oversight which made it a bit slower than it could be or more memory than it really needed; wouldn't you want that fixed? If the only attitude is, 'Oh, if it's slow it's OBVIOUSLY because of the optimiser, there can be no other explanation', then that is never going to happen.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-21 15:31 +0100 |
| Message-ID | <q24l3a$g71$1@dont-email.me> |
| In reply to | #140052 |
On 21/01/2019 13:49, Bart wrote: > On 21/01/2019 08:44, David Brown wrote: >> On 20/01/2019 18:19, Bart wrote: > >>> Really? Pelles C took 4000 times as long as DMC. > > It was 1000 times as long: 400 seconds vs. 0.4 seconds. > > That suggests an issue >>> that ought to be fixed. One that /could/ come up in real programs one >>> day. >> >> No, it suggests that Pelles C is not a good choice for compiling huge >> functions full of duplicate statements. It does /not/ suggest an issue >> that ought to be fixed unless compiling such functions is a reasonable >> use-case for that compiler. > > It took 400 seconds for 20Klines, and 10 seconds for 10Klines. That DOES > suggest an issue. Maybe to do with a hashtable getting very full > (although 20K identifiers isn't a lot), but that's for the developers to > sort out. Perhaps - if they care about such uses. > >> And do you think your test functions are >> typical use-cases of typical Pelles C users? > > If the problem is the number of symbols, then it can well be an issue. > We don't know. If it was my compiler, I would certainly want to know > what is happening. Oh, I can appreciate that. But knowing what is happening is not the same as feeling it is appropriate to change it. Perhaps (without having any knowledge or experience of Pelles) the answer is that they would need to increase the size of their symbol hash table - but doing so increases indexes from 16-bit to 32-bit leading to a table that no longer fits in the cpu's cache, and noticeably increasing the compile time for code that is 10 kilolines or less. My point is that this is not necessarily a problem, or a bug, or a flaw, or an issue that needs handled. (Equally, I can't say it is /not/ such a problem.) > >> Don't get me wrong here - I think it is a good thing for compilers to be >> able to handle large source efficiently, of whatever kind. But I don't >> think it is a sensible priority. > > I wrote a year or two ago about problems with Nasm, getting > exponentially slower as programs got bigger. Perhaps one minute to > compiler 70Kloc, which is not a lot. > > It came up for me because my compiler generated one .asm file for a > while program. But taking 1000 times as long to assemble the input as my > compiler took to generate it was totally impractical. > > Something was wrong. And it still is. (I no longer use Nasm.) > And there you have a fine solution - use an alternative that suits your needs better. >> To put it in very simplistic terms, it is probably easy (relatively >> speaking) to make a compiler that has O(n) performance in the number of >> lines/statements/expressions in a function. > > (Yes, that's what fir says. He can't see any reason why you can't write > a 10M lines per second compiler, or why it should take more than a > couple of days.) I'd expect it to take more than a couple of days - but less than the hundreds of man-years needed for major compiler suites. > >> Compilers are tools for a handling certain kinds of tasks. Sometimes >> that is just "turn this source code into object code". Sometimes it is >> "give me the fastest possible code from this source code". Often it is >> "help me write correct code" (that is a key reason I prefer gcc). It is >> /never/ "compile this million line artificial function as fast as >> possible". So why should any compiler writer put effort into achieving >> this last goal? > > The idea of the million-line function and other such tests is to > highlight and detect any possible inefficiency in a compilers. > If that helps you find inefficiencies with 100 line functions that are otherwise hard to spot, fine. If it finds inefficiencies that only occur in million line functions, then it is useless. > Suppose gcc DID include some oversight which made it a bit slower than > it could be or more memory than it really needed; wouldn't you want that > fixed? > If it is less efficient than it could be on real-life code, then yes, it would be nice to see an improvement. But that desire would have to be balanced against other desires - would it have a negative impact on other features, or would it take development time that could be better spent on something else? And if it is less efficient only on unrealistic code, then I don't see why anyone would care. (Note that even though /I/ don't use huge functions or files, I appreciate there are other people who do for some kinds of coding. But they don't use functions that are millions of lines of duplicate code.) > If the only attitude is, 'Oh, if it's slow it's OBVIOUSLY because of the > optimiser, there can be no other explanation', then that is never going > to happen. Agreed. I haven't seen anyone display that attitude.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2019-01-21 14:38 +0100 |
| Message-ID | <q24i15$rt2$1@dont-email.me> |
| In reply to | #140046 |
What Mr Brown doesn't take into account is that C is used as a back end
language for other languages.
For instance Eiffel.
And some Eiffel compilers generate code for
int table[3]={1,2,3} // Equivalent in Eiffel of course
int main(void)
{
table[0]=1; table[1]=2; table[3]=3;
...
}
What is perfectly legal. Problem is when you have a table with 45000
entries!
One of my customers was the JPL, that used an Eiffel compiler to
calculate ephemerides and orbit parameters... My compiler was the only
one able to compile the "main" function that consisted of thousands and
thousands of statements like:
int main()
{
// ...
table[34765]=63422; table[34766]=619563; table[34767]=26445;
// ...
}
Both gcc and MSVC would fail.
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2019-01-21 15:15 +0100 |
| Message-ID | <m2womyjdw1.fsf@despina.home> |
| In reply to | #140058 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> What Mr Brown doesn't take into account is that C is used as a back
> end language for other languages.
>
> For instance Eiffel.
>
> And some Eiffel compilers generate code for
>
> int table[3]={1,2,3} // Equivalent in Eiffel of course
>
> int main(void)
> {
> table[0]=1; table[1]=2; table[3]=3;
> ...
> }
> What is perfectly legal. Problem is when you have a table with 45000
> entries!
>
> One of my customers was the JPL, that used an Eiffel compiler to
> calculate ephemerides and orbit parameters... My compiler was the only
> one able to compile the "main" function that consisted of thousands
> and thousands of statements like:
> int main()
> {
> // ...
>
> table[34765]=63422; table[34766]=619563; table[34767]=26445;
> // ...
> }
>
> Both gcc and MSVC would fail.
It would be trivial to write a script to transform:
…
table[34765]=63422; table[34766]=619563; table[34767]=26445;
…
into:
static int table[]={ …, 63422, 619563, 26445, … };
and compile it with gcc…
gcc has no problem compiling static tables of at least 1 million ints.
--
__Pascal J. Bourguignon__
http://www.informatimago.com
p
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2019-01-21 16:05 +0100 |
| Message-ID | <q24n36$st3$1@dont-email.me> |
| In reply to | #140060 |
Le 21/01/2019 à 15:15, Pascal J. Bourguignon a écrit :
> It would be trivial to write a script to transform:
>
> …
> table[34765]=63422; table[34766]=619563; table[34767]=26445;
> …
>
> into:
>
> static int table[]={ …, 63422, 619563, 26445, … };
Trivial, of course.
You have just to find out where those assignments start, and ignore
assignments where
table[1]=56;
gtb[23]=78;
and only take into accout those where initializations go beyond an
arbitrary threshold.
Of course you should accept
............... table[
347]-674534;
You have to recognize tokens, assignments etc etc. You end up with
redoing a C parser.
THEN, you have to incorporate the script into the build process, and
figure out the name of the file having the initializations, read it,
parse it, find the necessary changes, do the changes, write the
intermediate file, and then compile it with gcc!!!
MUCH easier is to ditch gcc, use lcc-win and be done with it.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-01-21 16:39 +0100 |
| Message-ID | <q24p39$ack$1@dont-email.me> |
| In reply to | #140064 |
On 21/01/2019 16:05, jacobnavia wrote:
> Le 21/01/2019 à 15:15, Pascal J. Bourguignon a écrit :
>> It would be trivial to write a script to transform:
>>
>> …
>> table[34765]=63422; table[34766]=619563; table[34767]=26445;
>> …
>>
>> into:
>>
>> static int table[]={ …, 63422, 619563, 26445, … };
>
> Trivial, of course.
>
> You have just to find out where those assignments start, and ignore
> assignments where
>
> table[1]=56;
> gtb[23]=78;
>
> and only take into accout those where initializations go beyond an
> arbitrary threshold.
>
> Of course you should accept
> ............... table[
> 347]-674534;
>
> You have to recognize tokens, assignments etc etc. You end up with
> redoing a C parser.
It would be /far/ easier than that. No one is suggesting writing a
general solution here - merely one that recognises this particular
inefficient code pattern generated by this particular Eiffel compiler.
I am not sure how trivial it would be, having never looked at the output
of Eiffel, but it would not be close to the challenge you are suggesting.
>
> THEN, you have to incorporate the script into the build process, and
> figure out the name of the file having the initializations, read it,
> parse it, find the necessary changes, do the changes, write the
> intermediate file, and then compile it with gcc!!!
That's easy.
>
> MUCH easier is to ditch gcc, use lcc-win and be done with it.
Perhaps for some people - but others want gcc (or clang, or other
compilers) rather than lcc-win. The reasons for that may be good or bad.
It is probably even easier to complain to the Eiffel folk and get them
to fix their C generator.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-01-21 12:51 -0800 |
| Message-ID | <2d66ebb8-cd72-480a-9280-d3197b7f1072@googlegroups.com> |
| In reply to | #140060 |
On Monday, 21 January 2019 14:15:20 UTC, Pascal J. Bourguignon wrote: > > gcc has no problem compiling static tables of at least 1 million ints. > MSVC++ failed for me on a dictionary of English words. It was a big dictionary including many rare spellings and so forth, and I've forgotten the size. But it was real data. I used it in a crossword project, if anyone is interested https://sourceforge.net/projects/crossworddesign/
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-22 00:16 +0000 |
| Message-ID | <zht1E.181448$fF1.2762@fx37.am4> |
| In reply to | #140072 |
On 21/01/2019 20:51, Malcolm McLean wrote:
> On Monday, 21 January 2019 14:15:20 UTC, Pascal J. Bourguignon wrote:
>>
>> gcc has no problem compiling static tables of at least 1 million ints.
>>
> MSVC++ failed for me on a dictionary of English words. It was a big
> dictionary including many rare spellings and so forth, and I've forgotten
> the size. But it was real data.
I tried that, as it seemed simple enough, just a table of 110K strings.
But I had major problems. At the heart of it is the fact the EXE file
format, which is made up of sections (minimum of initialised data,
uninitialised data and code sections for entire program), can only
accommodate 32K relocation items per section.
Such a table:
static char *table[] = {"aardvark",...., "zygote"};
consists of a sequence of 110K pointers, each holding the address of its
string. This address is an absolute value so needs to be relocatable so
that it can be adjusted according to the section start address in memory.
But with only 32K possible relocation items for 110K pointers (plus all
the other data in the program) that makes things awkward.
As are the solutions (using multiple sections, but EXE is a truly
horrible format to work with; or try to assume the likely absolute
addresses that will be used and avoid relocs, but that won't work as a
shared library).
So I will leave it for now I think.
However, how about MS devising a file format - for PE+ which is for
64-bit programs - which still uses 16-bit fields; how utterly stupid is
that?
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2019-01-22 08:43 +0100 |
| Message-ID | <q26hjb$acv$1@dont-email.me> |
| In reply to | #140074 |
Le 22/01/2019 à 01:16, Bart a écrit : > At the heart of it is the fact the EXE file format, which is made up of > sections (minimum of initialised data, uninitialised data and code > sections for entire program), can only accommodate 32K relocation items > per section. Read the specs again. There is an overflow format with a special value for the symbol that allows the number of relocations to be extended... I forget now the details
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-01-22 12:31 +0000 |
| Message-ID | <p2E1E.360123$Fi6.222660@fx12.am4> |
| In reply to | #140075 |
On 22/01/2019 07:43, jacobnavia wrote: > Le 22/01/2019 à 01:16, Bart a écrit : >> At the heart of it is the fact the EXE file format, which is made up >> of sections (minimum of initialised data, uninitialised data and code >> sections for entire program), can only accommodate 32K relocation >> items per section. > > Read the specs again. There is an overflow format with a special value > for the symbol that allows the number of relocations to be extended... > > I forget now the details I looked at the spec, but couldn't find that overflow. However it seems PE format (ie. for EXE) doesn't use that relocation info at all. It's used for COFF (ie. object files), which I'm not too concerned about. It's when generating .exe that my assembler goes wrong shortly after exceeding 32K relocation items (which are 'addr64_rel', not even absolute). I'll need to look further to see what's happening. But this is a part of coding that really isn't fun...
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2019-01-22 17:49 +0100 |
| Message-ID | <q27hjj$626$1@dont-email.me> |
| In reply to | #140082 |
Le 22/01/2019 à 13:31, Bart a écrit : > It's when generating .exe that my assembler goes wrong shortly after > exceeding 32K relocation items (which are 'addr64_rel', not even absolute). All relocation entries are in the .reloc section. They are stored in blocks, each block starting with the base address (rva) over 4 bytes, followed by the number of bytes in the using another 4 bytes. So, you have up to 2GB of blocks and up to 2GB of block size. Within each block you have 16 bit records with the higher 2 bits for the type of the relocation and the following 12 bits for the address of the relocation within the block. There is nowhere a 32K limit ... you must be conbfusing something. In the OBJECT file format there is one, but absolutely not in the .EXE format, unless you are using the obselete EXE format of 16 bit windows (Windows 3.1 or so)
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web