Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #129216 > unrolled thread
| Started by | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| First post | 2018-04-15 10:38 +0200 |
| Last post | 2018-04-15 23:20 +0200 |
| Articles | 20 on this page of 165 — 15 participants |
Back to article view | Back to comp.lang.c
stdcbench benchmark Philipp Klaus Krause <pkk@spth.de> - 2018-04-15 10:38 +0200
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-15 02:31 -0700
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-15 13:42 +0100
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-15 18:00 +0100
Re: stdcbench benchmark Melzzzzz <Melzzzzz@zzzzz.com> - 2018-04-15 18:11 +0000
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-15 19:30 +0100
Re: stdcbench benchmark Melzzzzz <Melzzzzz@zzzzz.com> - 2018-04-15 18:52 +0000
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-15 20:15 -0700
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-15 20:42 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-15 22:31 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-15 23:29 +0100
Re: stdcbench benchmark Philipp Klaus Krause <pkk@spth.de> - 2018-04-16 07:48 +0200
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-15 23:22 -0700
Re: stdcbench benchmark Philipp Klaus Krause <pkk@spth.de> - 2018-04-16 11:52 +0200
Re: stdcbench benchmark Philipp Klaus Krause <pkk@spth.de> - 2018-04-16 09:56 +0200
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-16 01:58 -0700
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-16 10:08 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-16 11:37 +0100
Re: stdcbench benchmark Ian Collins <ian-news@hotmail.com> - 2018-04-16 22:42 +1200
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-16 12:54 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-16 13:02 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-16 14:39 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-16 14:53 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-16 16:32 +0200
Re: stdcbench benchmark scott@slp53.sl.home (Scott Lurndal) - 2018-04-16 14:41 +0000
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-16 15:56 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-16 17:21 +0200
Re: stdcbench benchmark scott@slp53.sl.home (Scott Lurndal) - 2018-04-16 15:43 +0000
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-16 17:00 +0100
Re: stdcbench benchmark scott@slp53.sl.home (Scott Lurndal) - 2018-04-16 16:09 +0000
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-16 17:22 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 09:35 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-17 11:42 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 14:14 +0200
Re: stdcbench benchmark Philipp Klaus Krause <pkk@spth.de> - 2018-04-17 15:49 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-17 18:45 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 23:00 +0200
Re: stdcbench benchmark scott@slp53.sl.home (Scott Lurndal) - 2018-04-17 21:18 +0000
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-17 23:20 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-18 09:27 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-18 11:30 +0100
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-18 03:43 -0700
Re: stdcbench benchmark Ian Collins <ian-news@hotmail.com> - 2018-04-18 22:58 +1200
Re: stdcbench benchmark mark.bluemel@gmail.com - 2018-04-18 04:01 -0700
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-18 12:39 +0100
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-18 06:52 -0700
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-18 13:59 +0100
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-18 06:14 -0700
Re: stdcbench benchmark Ian Collins <ian-news@hotmail.com> - 2018-04-19 07:39 +1200
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-18 06:14 -0700
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-18 16:31 +0200
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-18 08:00 -0700
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-18 17:26 +0200
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-18 08:37 -0700
Re: stdcbench benchmark scott@slp53.sl.home (Scott Lurndal) - 2018-04-18 16:12 +0000
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-18 18:15 +0100
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-18 04:01 -0700
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-18 13:01 +0200
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-18 04:15 -0700
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-18 13:41 +0200
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-18 05:35 -0700
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-18 12:26 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-18 13:58 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-18 22:29 +0100
Re: stdcbench benchmark Keith Thompson <kst-u@mib.org> - 2018-04-18 10:34 -0700
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-18 22:34 +0200
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-18 22:35 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-19 20:05 +0100
Re: stdcbench benchmark Ian Collins <ian-news@hotmail.com> - 2018-04-20 08:07 +1200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-19 23:34 +0100
Re: stdcbench benchmark Keith Thompson <kst-u@mib.org> - 2018-04-19 16:05 -0700
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-20 00:18 +0100
Re: stdcbench benchmark scott@slp53.sl.home (Scott Lurndal) - 2018-04-25 23:12 +0000
Re: stdcbench benchmark Ian Collins <ian-news@hotmail.com> - 2018-04-20 16:15 +1200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-20 11:39 +0100
Re: stdcbench benchmark Ian Collins <ian-news@hotmail.com> - 2018-04-20 23:46 +1200
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-20 05:04 -0700
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-20 13:27 +0100
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-20 06:06 -0700
Re: stdcbench benchmark supercat@casperkitty.com - 2018-04-20 13:05 -0700
Re: stdcbench benchmark mark.bluemel@gmail.com - 2018-04-20 01:23 -0700
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-20 01:40 -0700
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-20 12:04 +0100
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-20 04:16 -0700
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-20 13:48 +0100
Re: stdcbench benchmark Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-23 11:53 -0700
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-23 20:33 +0100
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-26 01:00 -0700
Re: stdcbench benchmark Keith Thompson <kst-u@mib.org> - 2018-04-20 09:17 -0700
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-20 19:25 +0100
Re: stdcbench benchmark Keith Thompson <kst-u@mib.org> - 2018-04-20 11:58 -0700
Re: stdcbench benchmark supercat@casperkitty.com - 2018-04-20 12:30 -0700
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-20 21:03 +0100
Re: stdcbench benchmark Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-04-20 22:16 +0100
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-20 23:09 +0100
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-20 14:42 +0100
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-20 09:30 -0700
Re: stdcbench benchmark Ian Collins <ian-news@hotmail.com> - 2018-04-21 07:24 +1200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-20 20:43 +0100
Re: stdcbench benchmark Ian Collins <ian-news@hotmail.com> - 2018-04-21 07:59 +1200
Re: stdcbench benchmark Ian Collins <ian-news@hotmail.com> - 2018-04-21 08:01 +1200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-20 21:18 +0100
Re: stdcbench benchmark Ian Collins <ian-news@hotmail.com> - 2018-04-21 09:17 +1200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-20 23:15 +0100
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-18 02:14 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-18 09:54 +0200
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-18 01:21 -0700
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-18 11:40 +0100
Re: stdcbench benchmark Ian Collins <ian-news@hotmail.com> - 2018-04-18 11:26 +1200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-18 01:48 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-18 09:58 +0200
Re: stdcbench benchmark Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-04-16 16:45 +0000
Re: stdcbench benchmark scott@slp53.sl.home (Scott Lurndal) - 2018-04-16 17:31 +0000
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-16 18:53 +0100
Re: stdcbench benchmark scott@slp53.sl.home (Scott Lurndal) - 2018-04-16 17:55 +0000
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-16 19:01 +0100
Re: stdcbench benchmark Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-04-16 20:28 +0000
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-16 21:57 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 09:45 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-17 12:24 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 14:31 +0200
Re: stdcbench benchmark Robert Wessel <robertwessel2@yahoo.com> - 2018-04-16 16:59 -0500
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-17 01:02 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 09:47 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-17 13:16 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 14:38 +0200
Re: stdcbench benchmark scott@slp53.sl.home (Scott Lurndal) - 2018-04-17 13:18 +0000
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-17 14:37 +0100
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-17 06:44 -0700
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 15:58 +0200
Re: stdcbench benchmark scott@slp53.sl.home (Scott Lurndal) - 2018-04-17 15:43 +0000
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-17 08:47 -0700
Re: stdcbench benchmark Ian Collins <ian-news@hotmail.com> - 2018-04-17 08:04 +1200
Re: stdcbench benchmark scott@slp53.sl.home (Scott Lurndal) - 2018-04-16 20:30 +0000
Re: stdcbench benchmark Melzzzzz <Melzzzzz@zzzzz.com> - 2018-04-16 16:31 +0000
Re: stdcbench benchmark Keith Thompson <kst-u@mib.org> - 2018-04-20 14:22 -0700
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-17 00:42 -0700
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-16 07:00 -0700
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-16 16:35 +0200
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-16 09:28 -0700
Re: stdcbench benchmark scott@slp53.sl.home (Scott Lurndal) - 2018-04-16 17:42 +0000
Re: stdcbench benchmark Robert Wessel <robertwessel2@yahoo.com> - 2018-04-16 17:07 -0500
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-17 02:50 -0700
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 12:42 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-17 11:58 +0100
Re: stdcbench benchmark Philipp Klaus Krause <pkk@spth.de> - 2018-04-17 14:01 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-17 13:40 +0100
Re: stdcbench benchmark Philipp Klaus Krause <pkk@spth.de> - 2018-04-17 15:41 +0200
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 14:46 +0200
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-17 06:09 -0700
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 16:07 +0200
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 14:43 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-17 15:26 +0100
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-17 07:42 -0700
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 16:51 +0200
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-17 08:07 -0700
Re: stdcbench benchmark Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-17 08:16 -0700
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 23:17 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-17 17:12 +0100
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 23:26 +0200
Re: stdcbench benchmark bartc <bc@freeuk.com> - 2018-04-17 23:38 +0100
Re: stdcbench benchmark Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-17 05:52 -0700
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 16:10 +0200
Re: stdcbench benchmark David Brown <david.brown@hesbynett.no> - 2018-04-17 10:02 +0200
Re: stdcbench benchmark Philipp Klaus Krause <pkk@spth.de> - 2018-04-15 23:20 +0200
Page 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-04-15 10:38 +0200 |
| Subject | stdcbench benchmark |
| Message-ID | <pav31c$k5r$1@solani.org> |
stdcbench, a new benchmark suitable for small systems, has evolved a bit over time since the previous discussion on comp.lang.c in late January / early February. The current version includes example ports to a few targets (besides the host port, there are ports for 4 ARM, 2 MCS-51 and 3 STM8 systems). I intend to make release tarballs soon. If any of you find the time to have a look at current stdcbench, I welcome your comments. In particular, I want to make sure that the benchmark is written in reasonable C and there is no unnecessary reliance on implementation-defined behaviour. Also, I haven't written any measurement / run /reporting rules yet. So far, I intend to be a bit less restrictive than other benchmarks, in particular, unlike Dhrystone I want to allow all compiler optimizations that do not make the compiler non-conforming wrt. the C standard (Dhrystone disallows some interprocedural optimizations). On the other hand, I wonder if one should require posting of full code to reproduce results (i.e. including Makefiles, or project fuiles for IDEs). Suggestions are welcome. Philipp
[toc] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-04-15 02:31 -0700 |
| Message-ID | <9ee78458-36c9-4488-85ac-e555304dda6d@googlegroups.com> |
| In reply to | #129216 |
On Sunday, April 15, 2018 at 1:38:13 AM UTC-7, Philipp Klaus Krause wrote: > stdcbench, a new benchmark suitable for small systems, has evolved a bit > over time since the previous discussion on comp.lang.c in late January / > early February. The current version includes example ports to a few > targets (besides the host port, there are ports for 4 ARM, 2 MCS-51 and > 3 STM8 systems). I intend to make release tarballs soon. > > If any of you find the time to have a look at current stdcbench, I > welcome your comments. In particular, I want to make sure that the > benchmark is written in reasonable C and there is no unnecessary > reliance on implementation-defined behaviour. > > Also, I haven't written any measurement / run /reporting rules yet. So > far, I intend to be a bit less restrictive than other benchmarks, in > particular, unlike Dhrystone I want to allow all compiler optimizations > that do not make the compiler non-conforming wrt. the C standard > (Dhrystone disallows some interprocedural optimizations). On the other > hand, I wonder if one should require posting of full code to reproduce > results (i.e. including Makefiles, or project fuiles for IDEs). > Suggestions are welcome. > > Philipp What Systemd looks like is the least of your problems and then it is not like Systemd, especially if it's approved by RMS. Having to tolerate the use of Systemd would just confuse the general user. Can you knock off begging for my attention? And in retaliation you have nothing but an attempt to start a war. - This broke the Internet!! https://youtu.be/UkAyrfOZaXc http://www.5z8.info/trojan_p4g1zy_how-to-skin-a-gerbil Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-15 13:42 +0100 |
| Message-ID | <bNHAC.1100666$iE.956313@fx05.am4> |
| In reply to | #129216 |
On 15/04/2018 09:38, Philipp Klaus Krause wrote:
> stdcbench, a new benchmark suitable for small systems, has evolved a bit
> over time since the previous discussion on comp.lang.c in late January /
> early February. The current version includes example ports to a few
> targets (besides the host port, there are ports for 4 ARM, 2 MCS-51 and
> 3 STM8 systems). I intend to make release tarballs soon.
>
> If any of you find the time to have a look at current stdcbench, I
> welcome your comments. In particular, I want to make sure that the
> benchmark is written in reasonable C and there is no unnecessary
> reliance on implementation-defined behaviour.
I tried it today but was mainly interested in finding out how my
compiler fared on my desktop PC relative to other compilers, not on a
small system. (Actually, in whether it would work at all.)
I compiled all the .c files in the main directory into an executable. To
the .c files shown, I had to add the GNU/GCC versions of portme.c and
portme.h from the examples subdirectory.
Results on my Windows C compilers (running on an old desktop PC) were as
follows. All were optimised, if possible, and used 64-bit code except
where stated:
Rank Score
gcc 1.0 359809 5.1.0
MSVC 1.1 318190 From VS 2017
DMC 2.0 180409 32 bits
lccwin 2.3 159220
Tiny C 2.9 122556 Unoptimised [Revamped tcc version]
mcc (mine) 3.1 117752 Unoptimised
Pelles C -- ["c90lib_lnlc() Result validation failed"]
OK, that's fine (mcc required a #pragma added for reasons I won't go
into), except that usually mcc is above Tiny C. Tight benchmarks are not
kind to it.
(A test using a real app gives these more typical results:
Rank Seconds
gcc 1.0 3.3
MSVC 1.0 3.3
Pelles C 1.1 3.7
--- 1.3 4.4 (my compiler working from original source)
mcc 1.5 5.1 (my compiler working from C source)
Tiny C 2.0 6.7 (Original tcc 6.5)
lccwin -- -- (Couldn't compile)
DMC -- -- (Not 64-bit)
Tiny C drops down partly due to poor 'switch' handling.)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-15 18:00 +0100 |
| Message-ID | <ryLAC.291893$Cz7.15937@fx10.am4> |
| In reply to | #129222 |
On 15/04/2018 13:42, bartc wrote: > (A test using a real app gives these more typical results: > > Rank Seconds > > gcc 1.0 3.3 > MSVC 1.0 3.3 > Pelles C 1.1 3.7 > --- 1.3 4.4 (my compiler working from original source) > mcc 1.5 5.1 (my compiler working from C source) > Tiny C 2.0 6.7 (Original tcc 6.5) > lccwin -- -- (Couldn't compile) > DMC -- -- (Not 64-bit) The DMC result was unfair; it was just too much effort to generate a C version suitable for 32 bits (I no longer support C generation). But with DMC, the table looks like this: gcc 1.0 3.3 -O3 MSVC 1.0 3.3 Pelles C 1.1 3.7 [Non-C 1.3 4.4 Uses non-standard call convention] DMC 1.5 5.0 (32-bits) mcc 1.5 5.1 gcc 1.6 5.3 -O0 Tiny C 2.0 6.7 This test was computationally intensive with little i/o or library calls, but the difference between slowest and fastest C compilers is only 2:1, and less than that if tcc is disregarded (someone needs to fix those switch statements). On other kinds of applications, the range could be even narrower. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2018-04-15 18:11 +0000 |
| Message-ID | <dBMAC.929375$oi5.839740@fx43.am4> |
| In reply to | #129228 |
On 2018-04-15, bartc <bc@freeuk.com> wrote: > On 15/04/2018 13:42, bartc wrote: > >> (A test using a real app gives these more typical results: >> >> Rank Seconds >> >> gcc 1.0 3.3 >> MSVC 1.0 3.3 >> Pelles C 1.1 3.7 >> --- 1.3 4.4 (my compiler working from original source) >> mcc 1.5 5.1 (my compiler working from C source) >> Tiny C 2.0 6.7 (Original tcc 6.5) >> lccwin -- -- (Couldn't compile) >> DMC -- -- (Not 64-bit) > > The DMC result was unfair; it was just too much effort to generate a C > version suitable for 32 bits (I no longer support C generation). But > with DMC, the table looks like this: > > gcc 1.0 3.3 -O3 > MSVC 1.0 3.3 > Pelles C 1.1 3.7 > [Non-C 1.3 4.4 Uses non-standard call convention] > DMC 1.5 5.0 (32-bits) > mcc 1.5 5.1 > gcc 1.6 5.3 -O0 > Tiny C 2.0 6.7 > > This test was computationally intensive with little i/o or library > calls, but the difference between slowest and fastest C compilers is > only 2:1, and less than that if tcc is disregarded (someone needs to fix > those switch statements). > > On other kinds of applications, the range could be even narrower. > ~/projects/stdcbench-code >>> CC=icc make -f examples/Makefile.GCC-GNU clean rm -f portme.c portme.h ~/projects/stdcbench-code >>> CC=icc make -f examples/Makefile.GCC-GNU cp examples/portme.c.GCC-GNU portme.c cp examples/portme.h.GCC-GNU portme.h icc -O2 -march=native *.c -o stdcbench ~/projects/stdcbench-code >>> ./stdcbench stdcbench 0.4 stdcbench c90base score: 396043 stdcbench c90lib score: 300459 stdcbench final score: 696502 ~/projects/stdcbench-code >>> CC=gcc make -f examples/Makefile.GCC-GNU clean rm -f portme.c portme.h ~/projects/stdcbench-code >>> CC=gcc make -f examples/Makefile.GCC-GNU cp examples/portme.c.GCC-GNU portme.c cp examples/portme.h.GCC-GNU portme.h gcc -O2 -march=native *.c -o stdcbench ~/projects/stdcbench-code >>> ./stdcbench stdcbench 0.4 stdcbench c90base score: 264315 stdcbench c90lib score: 190659 stdcbench final score: 454974 ~/projects/stdcbench-code >>> CC=clang make -f examples/Makefile.GCC-GNU clean rm -f portme.c portme.h ~/projects/stdcbench-code >>> CC=clang make -f examples/Makefile.GCC-GNU cp examples/portme.c.GCC-GNU portme.c cp examples/portme.h.GCC-GNU portme.h clang -O2 -march=native *.c -o stdcbench ~/projects/stdcbench-code >>> ./stdcbench stdcbench 0.4 stdcbench c90base score: 458481 stdcbench c90lib score: 270938 stdcbench final score: 729419 -- press any key to continue or any other to quit...
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-15 19:30 +0100 |
| Message-ID | <VSMAC.948773$_91.657799@fx02.am4> |
| In reply to | #129229 |
On 15/04/2018 19:11, Melzzzzz wrote: > ~/projects/stdcbench-code >>> CC=icc make -f examples/Makefile.GCC-GNU clean > rm -f portme.c portme.h > ~/projects/stdcbench-code >>> CC=icc make -f examples/Makefile.GCC-GNU > cp examples/portme.c.GCC-GNU portme.c > cp examples/portme.h.GCC-GNU portme.h > icc -O2 -march=native *.c -o stdcbench > ~/projects/stdcbench-code >>> ./stdcbench > stdcbench 0.4 > stdcbench c90base score: 396043 > stdcbench c90lib score: 300459 > stdcbench final score: 696502 > ~/projects/stdcbench-code >>> CC=gcc make -f examples/Makefile.GCC-GNU clean > rm -f portme.c portme.h > ~/projects/stdcbench-code >>> CC=gcc make -f examples/Makefile.GCC-GNU > cp examples/portme.c.GCC-GNU portme.c > cp examples/portme.h.GCC-GNU portme.h > gcc -O2 -march=native *.c -o stdcbench > ~/projects/stdcbench-code >>> ./stdcbench > stdcbench 0.4 > stdcbench c90base score: 264315 > stdcbench c90lib score: 190659 > stdcbench final score: 454974 > ~/projects/stdcbench-code >>> CC=clang make -f examples/Makefile.GCC-GNU clean > rm -f portme.c portme.h > ~/projects/stdcbench-code >>> CC=clang make -f examples/Makefile.GCC-GNU > cp examples/portme.c.GCC-GNU portme.c > cp examples/portme.h.GCC-GNU portme.h > clang -O2 -march=native *.c -o stdcbench > ~/projects/stdcbench-code >>> ./stdcbench > stdcbench 0.4 > stdcbench c90base score: 458481 > stdcbench c90lib score: 270938 > stdcbench final score: 729419 > > So, to summarise: icc 696502 = 396043 + 300459 1.05 gcc 454974 = 264315 + 190659 1.60 clang 729419 = 458481 + 270938 1.00 The gcc results look suspiciously low compared with the other two. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2018-04-15 18:52 +0000 |
| Message-ID | <PbNAC.627843$Jj7.436502@fx45.am4> |
| In reply to | #129230 |
On 2018-04-15, bartc <bc@freeuk.com> wrote: > On 15/04/2018 19:11, Melzzzzz wrote: > >> ~/projects/stdcbench-code >>> CC=icc make -f examples/Makefile.GCC-GNU clean >> rm -f portme.c portme.h >> ~/projects/stdcbench-code >>> CC=icc make -f examples/Makefile.GCC-GNU >> cp examples/portme.c.GCC-GNU portme.c >> cp examples/portme.h.GCC-GNU portme.h >> icc -O2 -march=native *.c -o stdcbench >> ~/projects/stdcbench-code >>> ./stdcbench >> stdcbench 0.4 >> stdcbench c90base score: 396043 >> stdcbench c90lib score: 300459 >> stdcbench final score: 696502 >> ~/projects/stdcbench-code >>> CC=gcc make -f examples/Makefile.GCC-GNU clean >> rm -f portme.c portme.h >> ~/projects/stdcbench-code >>> CC=gcc make -f examples/Makefile.GCC-GNU >> cp examples/portme.c.GCC-GNU portme.c >> cp examples/portme.h.GCC-GNU portme.h >> gcc -O2 -march=native *.c -o stdcbench >> ~/projects/stdcbench-code >>> ./stdcbench >> stdcbench 0.4 >> stdcbench c90base score: 264315 >> stdcbench c90lib score: 190659 >> stdcbench final score: 454974 >> ~/projects/stdcbench-code >>> CC=clang make -f examples/Makefile.GCC-GNU clean >> rm -f portme.c portme.h >> ~/projects/stdcbench-code >>> CC=clang make -f examples/Makefile.GCC-GNU >> cp examples/portme.c.GCC-GNU portme.c >> cp examples/portme.h.GCC-GNU portme.h >> clang -O2 -march=native *.c -o stdcbench >> ~/projects/stdcbench-code >>> ./stdcbench >> stdcbench 0.4 >> stdcbench c90base score: 458481 >> stdcbench c90lib score: 270938 >> stdcbench final score: 729419 >> >> > > So, to summarise: > > icc 696502 = 396043 + 300459 1.05 > gcc 454974 = 264315 + 190659 1.60 > clang 729419 = 458481 + 270938 1.00 > > The gcc results look suspiciously low compared with the other two. > These are results from gcc-trunk: ~/projects/stdcbench-code >>> CC=gcc-trunk make -f examples/Makefile.GCC-GNU clean rm -f portme.c portme.h ~/projects/stdcbench-code >>> CC=gcc-trunk make -f examples/Makefile.GCC-GNU cp examples/portme.c.GCC-GNU portme.c cp examples/portme.h.GCC-GNU portme.h gcc-trunk -O2 -march=native *.c -o stdcbench ~/projects/stdcbench-code >>> ./stdcbench stdcbench 0.4 stdcbench c90base score: 394974 stdcbench c90lib score: 189879 stdcbench final score: 584853 It is significantly faster, but still lower then clang and icc. -- press any key to continue or any other to quit...
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-04-15 20:15 -0700 |
| Message-ID | <80c3012f-6353-4e12-96f2-5ded7e58b189@googlegroups.com> |
| In reply to | #129229 |
On Sunday, April 15, 2018 at 11:11:31 AM UTC-7, Melzzzzz wrote: > On 2018-04-15, bartc <bc@freeuk.com> wrote: > > On 15/04/2018 13:42, bartc wrote: > > > >> (A test using a real app gives these more typical results: > >> > >> Rank Seconds > >> > >> gcc 1.0 3.3 > >> MSVC 1.0 3.3 > >> Pelles C 1.1 3.7 > >> --- 1.3 4.4 (my compiler working from original source) > >> mcc 1.5 5.1 (my compiler working from C source) > >> Tiny C 2.0 6.7 (Original tcc 6.5) > >> lccwin -- -- (Couldn't compile) > >> DMC -- -- (Not 64-bit) > > > > The DMC result was unfair; it was just too much effort to generate a C > > version suitable for 32 bits (I no longer support C generation). But > > with DMC, the table looks like this: > > > > gcc 1.0 3.3 -O3 > > MSVC 1.0 3.3 > > Pelles C 1.1 3.7 > > [Non-C 1.3 4.4 Uses non-standard call convention] > > DMC 1.5 5.0 (32-bits) > > mcc 1.5 5.1 > > gcc 1.6 5.3 -O0 > > Tiny C 2.0 6.7 > > > > This test was computationally intensive with little i/o or library > > calls, but the difference between slowest and fastest C compilers is > > only 2:1, and less than that if tcc is disregarded (someone needs to fix > > those switch statements). > > > > On other kinds of applications, the range could be even narrower. > > > ~/projects/stdcbench-code >>> CC=icc make -f examples/Makefile.GCC-GNU clean > rm -f portme.c portme.h > ~/projects/stdcbench-code >>> CC=icc make -f examples/Makefile.GCC-GNU > cp examples/portme.c.GCC-GNU portme.c > cp examples/portme.h.GCC-GNU portme.h > icc -O2 -march=native *.c -o stdcbench > ~/projects/stdcbench-code >>> ./stdcbench > stdcbench 0.4 > stdcbench c90base score: 396043 > stdcbench c90lib score: 300459 > stdcbench final score: 696502 > ~/projects/stdcbench-code >>> CC=gcc make -f examples/Makefile.GCC-GNU clean > rm -f portme.c portme.h > ~/projects/stdcbench-code >>> CC=gcc make -f examples/Makefile.GCC-GNU > cp examples/portme.c.GCC-GNU portme.c > cp examples/portme.h.GCC-GNU portme.h > gcc -O2 -march=native *.c -o stdcbench > ~/projects/stdcbench-code >>> ./stdcbench > stdcbench 0.4 > stdcbench c90base score: 264315 > stdcbench c90lib score: 190659 > stdcbench final score: 454974 > ~/projects/stdcbench-code >>> CC=clang make -f examples/Makefile.GCC-GNU clean > rm -f portme.c portme.h > ~/projects/stdcbench-code >>> CC=clang make -f examples/Makefile.GCC-GNU > cp examples/portme.c.GCC-GNU portme.c > cp examples/portme.h.GCC-GNU portme.h > clang -O2 -march=native *.c -o stdcbench > ~/projects/stdcbench-code >>> ./stdcbench > stdcbench 0.4 > stdcbench c90base score: 458481 > stdcbench c90lib score: 270938 > stdcbench final score: 729419 > > > -- > press any key to continue or any other to quit... Not long ago I did work on and showed some Ruby for the front end (only works on high end systems) which is the only thing you can do when trying to avoid ultred 'The Flooder' ragnusen's immature crap while reading with Google Groups. Marketing is a wonderful thing and consumer cluelessness is even better. The cult-like herd of convenient friends value being like everyone else more than they do productivity. ultred 'The Flooder' ragnusen is far too stupid to write a useful script. The only scripting he's able to do is automating his trolling in this group. I can tell ultred 'The Flooder' ragnusen does not even know what is wrong with Alex Jones. I believe we have different beliefs about ultred 'The Flooder' ragnusen. I have known voices in my head who argue better than you do. Someone's reverse compiled Windows with (it appears) the MaxCliqueDyn Maximum Clique algorithm to automate posts which are made to sound like a response from my posts. -- Get Rich Slow! http://www.5z8.info/freeanimalporn.com-start-download_s9j7do_dogporn https://youtu.be/IhOfBmWwCVY Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-15 20:42 +0100 |
| Message-ID | <tWNAC.645818$a15.98543@fx22.am4> |
| In reply to | #129216 |
On 15/04/2018 09:38, Philipp Klaus Krause wrote:
> stdcbench, a new benchmark suitable for small systems, has evolved a bit
> over time since the previous discussion on comp.lang.c in late January /
> early February. The current version includes example ports to a few
> targets (besides the host port, there are ports for 4 ARM, 2 MCS-51 and
> 3 STM8 systems). I intend to make release tarballs soon.
>
> If any of you find the time to have a look at current stdcbench, I
> welcome your comments. In particular, I want to make sure that the
> benchmark is written in reasonable C and there is no unnecessary
> reliance on implementation-defined behaviour.
The c90base tests revolved around this loop:
do
{
c90base_compression();
c90base_isort();
c90base_immul();
iterations++;
}
But the three tests it calls are unbalanced. That is, if all but one are
commented out, then it can do 3M iterations of immul(), compared with
70K of isort() and 40K of compression().
However, that was with gcc-O3. With other compilers, the figure was much
slower, around 40K to 130K iterations of immult(). And even with gcc-O0,
it was 41K.
So this might be part of the benchmark that can be unfairly optimised
(70 times improvement between -O3 and -O0 is remarkable, and even on
MSVC, optimising made a 12 times improvement). Unfair in that it is
possible the requested task is not being executed.
If I remove the immul() test completely, then the score of gcc-O3 stays
about the same. But for the other compilers it increases by 10K to 23K.
gcc is still top, but the gap between the rest is narrower.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-04-15 22:31 +0200 |
| Message-ID | <pb0crv$fs7$1@dont-email.me> |
| In reply to | #129234 |
On 15/04/18 21:42, bartc wrote:
> On 15/04/2018 09:38, Philipp Klaus Krause wrote:
>> stdcbench, a new benchmark suitable for small systems, has evolved a bit
>> over time since the previous discussion on comp.lang.c in late January /
>> early February. The current version includes example ports to a few
>> targets (besides the host port, there are ports for 4 ARM, 2 MCS-51 and
>> 3 STM8 systems). I intend to make release tarballs soon.
>>
>> If any of you find the time to have a look at current stdcbench, I
>> welcome your comments. In particular, I want to make sure that the
>> benchmark is written in reasonable C and there is no unnecessary
>> reliance on implementation-defined behaviour.
>
> The c90base tests revolved around this loop:
>
> do
> {
> c90base_compression();
> c90base_isort();
> c90base_immul();
>
> iterations++;
> }
>
> But the three tests it calls are unbalanced. That is, if all but one are
> commented out, then it can do 3M iterations of immul(), compared with
> 70K of isort() and 40K of compression().
>
> However, that was with gcc-O3. With other compilers, the figure was much
> slower, around 40K to 130K iterations of immult(). And even with gcc-O0,
> it was 41K.
>
> So this might be part of the benchmark that can be unfairly optimised
> (70 times improvement between -O3 and -O0 is remarkable, and even on
> MSVC, optimising made a 12 times improvement). Unfair in that it is
> possible the requested task is not being executed.
>
Looking at some generated assembly from this, it appears that at -O3 gcc
is doing autovectorisation which can easily make a huge difference.
It is also possible that at least some of the calculations can be
skipped, but if my interpretation of the source code is correct based on
a quick glance, the "volatile" marker in the source data array will
ensure that the calculations are done.
> If I remove the immul() test completely, then the score of gcc-O3 stays
> about the same. But for the other compilers it increases by 10K to 23K.
>
> gcc is still top, but the gap between the rest is narrower.
>
>
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-15 23:29 +0100 |
| Message-ID | <LmQAC.1594032$jx2.496088@fx03.am4> |
| In reply to | #129235 |
On 15/04/2018 21:31, David Brown wrote: > On 15/04/18 21:42, bartc wrote: >> So this might be part of the benchmark that can be unfairly optimised >> (70 times improvement between -O3 and -O0 is remarkable, ... > Unfair in that it is >> possible the requested task is not being executed. >> > > Looking at some generated assembly from this, it appears that at -O3 gcc > is doing autovectorisation which can easily make a huge difference. > > It is also possible that at least some of the calculations can be > skipped, but if my interpretation of the source code is correct based on > a quick glance, the "volatile" marker in the source data array will > ensure that the calculations are done. If I use a counter incremented within each inner loop, then apparently 62 billion inner loops have been executed using gcc-O3. All in 8 seconds that the test runs for. Which is funny because just a plain loop doing nothing but incrementing a number 62 billion times takes 2 minutes to run, also with gcc-O3 but using volatile. So some odd things are going on. If this was testing vector capability, then fine. But as a general test of ordinary, ad hoc multiply operations that cannot be vectorised, then results will be misleading as it will make gcc look better than another compiler which doesn't have vector ops, when gcc in reality is not much better. But as the OP said, this vectorisation is unlikely on the small devices it is intended for testing on. (I ran the tests again with optimisations off. Then the difference between fastest and slowest compiler was 1.3:1 instead of 3:1 (with gcc 4th fastest). Here at least I know it is doing the work it has been told to do. This is also better for me as I can more usefully tweak my code generators to try and match the better compilers, as there are no scary optimisations to try and replicate.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-04-16 07:48 +0200 |
| Message-ID | <pb1df1$4au$1@solani.org> |
| In reply to | #129237 |
Am 16.04.2018 um 00:29 schrieb bartc: > On 15/04/2018 21:31, David Brown wrote: >> On 15/04/18 21:42, bartc wrote: > >>> So this might be part of the benchmark that can be unfairly optimised >>> (70 times improvement between -O3 and -O0 is remarkable, ... >> Unfair in that it is >>> possible the requested task is not being executed. >>> >> >> Looking at some generated assembly from this, it appears that at -O3 gcc >> is doing autovectorisation which can easily make a huge difference. >> >> It is also possible that at least some of the calculations can be >> skipped, but if my interpretation of the source code is correct based on >> a quick glance, the "volatile" marker in the source data array will >> ensure that the calculations are done. > > If I use a counter incremented within each inner loop, then apparently > 62 billion inner loops have been executed using gcc-O3. > > All in 8 seconds that the test runs for. Which is funny because just a > plain loop doing nothing but incrementing a number 62 billion times > takes 2 minutes to run, also with gcc-O3 but using volatile. > > So some odd things are going on. On second look at the C code, a very sophisticated compiler could be able to optimize out the calculation there. After all, it basically just calculates v0 = v; v1 = (L * (B * v0)); v2 = (L * B) * v0; For 16 different v. An then each time verifies that v1 == v2. Only v is volatile, while the cached copy in v0 is not. So a compiler that can reason well enough to prove that my code is essentially just the calculation given above, and that knows enough about linear algebra to prove that v1 will always be the same as v2 could optimize out the computation. I'll have a look at the asm generated by GCC to see if that really happens; if yes, it seems quite impressive to me. Either way, I should fix that before the tarball release of stdcbench. Philipp
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-04-15 23:22 -0700 |
| Message-ID | <967f6963-4916-491b-b1ad-844b0dc8906a@googlegroups.com> |
| In reply to | #129241 |
On Sunday, April 15, 2018 at 10:48:27 PM UTC-7, Philipp Klaus Krause wrote: > Am 16.04.2018 um 00:29 schrieb bartc: > > On 15/04/2018 21:31, David Brown wrote: > >> On 15/04/18 21:42, bartc wrote: > > > >>> So this might be part of the benchmark that can be unfairly optimised > >>> (70 times improvement between -O3 and -O0 is remarkable, ... > >> Unfair in that it is > >>> possible the requested task is not being executed. > >>> > >> > >> Looking at some generated assembly from this, it appears that at -O3 gcc > >> is doing autovectorisation which can easily make a huge difference. > >> > >> It is also possible that at least some of the calculations can be > >> skipped, but if my interpretation of the source code is correct based on > >> a quick glance, the "volatile" marker in the source data array will > >> ensure that the calculations are done. > > > > If I use a counter incremented within each inner loop, then apparently > > 62 billion inner loops have been executed using gcc-O3. > > > > All in 8 seconds that the test runs for. Which is funny because just a > > plain loop doing nothing but incrementing a number 62 billion times > > takes 2 minutes to run, also with gcc-O3 but using volatile. > > > > So some odd things are going on. > > On second look at the C code, a very sophisticated compiler could be > able to optimize out the calculation there. After all, it basically just > calculates > > v0 = v; > v1 = (L * (B * v0)); > v2 = (L * B) * v0; > > For 16 different v. > An then each time verifies that v1 == v2. Only v is volatile, while the > cached copy in v0 is not. So a compiler that can reason well enough to > prove that my code is essentially just the calculation given above, and > that knows enough about linear algebra to prove that v1 will always be > the same as v2 could optimize out the computation. > > I'll have a look at the asm generated by GCC to see if that really > happens; if yes, it seems quite impressive to me. > > Either way, I should fix that before the tarball release of stdcbench. > > Philipp Over and over, the demand is Jesus wants to "talk tech", but the guy spends most of his time whining about "obsession". You've proven only what a moron you are. If Jesus calls having his ass handed to him by dozens of people (and completely killing his name and any reason for advocates to give credence to anything he has to say) good 'trolling', then sure... he is a magnificent troll. I do not accept that view, I use another term. I call that person an out-and-out mouth-breather. Who *doesn't* know that this kind of rot is Jesus's MO, not the MO of Jeff Torrey? It's all just projection... the flooding, the sock puppets, the writing of incomprehensible idiocy, the outbursts... the diaper rash and eagerness to show how distressed he is over being booted from the sandbox for shitting in it again... all of it ;) Seriously, what lie? Do you have a high school diploma? - This broke the Internet http://www.5z8.info/add-worm_z4r9qk_fakelogin Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-04-16 11:52 +0200 |
| Message-ID | <pb1rpo$cuf$1@solani.org> |
| In reply to | #129241 |
Am 16.04.2018 um 07:48 schrieb Philipp Klaus Krause: > > I'll have a look at the asm generated by GCC to see if that really > happens; if yes, it seems quite impressive to me. > > Either way, I should fix that before the tarball release of stdcbench. The fix is not yet comitted, but testing does not show a big impact on scores. Philipp
[toc] | [prev] | [next] | [standalone]
| From | Philipp Klaus Krause <pkk@spth.de> |
|---|---|
| Date | 2018-04-16 09:56 +0200 |
| Message-ID | <pb1kul$8cn$1@solani.org> |
| In reply to | #129237 |
Am 16.04.2018 um 00:29 schrieb bartc: > On 15/04/2018 21:31, David Brown wrote: >> On 15/04/18 21:42, bartc wrote: > >>> So this might be part of the benchmark that can be unfairly optimised >>> (70 times improvement between -O3 and -O0 is remarkable, ... >> Unfair in that it is >>> possible the requested task is not being executed. >>> >> >> Looking at some generated assembly from this, it appears that at -O3 gcc >> is doing autovectorisation which can easily make a huge difference. >> >> It is also possible that at least some of the calculations can be >> skipped, but if my interpretation of the source code is correct based on >> a quick glance, the "volatile" marker in the source data array will >> ensure that the calculations are done. > > If I use a counter incremented within each inner loop, then apparently > 62 billion inner loops have been executed using gcc-O3. > > All in 8 seconds that the test runs for. Which is funny because just a > plain loop doing nothing but incrementing a number 62 billion times > takes 2 minutes to run, also with gcc-O3 but using volatile. > > So some odd things are going on. > > If this was testing vector capability, then fine. But as a general test > of ordinary, ad hoc multiply operations that cannot be vectorised, then > results will be misleading as it will make gcc look better than another > compiler which doesn't have vector ops, when gcc in reality is not much > better. > It is meant to test integer matrix operations. So benefiting from vectorization is fine. I just had a look at the asm generated by GCC 7 and 8 with -O3 -march=native -S c90base-immul.c on a i7-7500U. While x86 asm is hard to read for me (I am mostly just familiar with 8-bit architectures), it seems the calculations are actually done (using SSE) and not optimized out. The improvement from -O2 to -O3 is a factor of about 10 on my system. Philipp
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-04-16 01:58 -0700 |
| Message-ID | <ef425368-e430-4481-a368-8ed3600af2c4@googlegroups.com> |
| In reply to | #129243 |
On Monday, April 16, 2018 at 12:56:14 AM UTC-7, Philipp Klaus Krause wrote: > Am 16.04.2018 um 00:29 schrieb bartc: > > On 15/04/2018 21:31, David Brown wrote: > >> On 15/04/18 21:42, bartc wrote: > > > >>> So this might be part of the benchmark that can be unfairly optimised > >>> (70 times improvement between -O3 and -O0 is remarkable, ... > >> Unfair in that it is > >>> possible the requested task is not being executed. > >>> > >> > >> Looking at some generated assembly from this, it appears that at -O3 gcc > >> is doing autovectorisation which can easily make a huge difference. > >> > >> It is also possible that at least some of the calculations can be > >> skipped, but if my interpretation of the source code is correct based on > >> a quick glance, the "volatile" marker in the source data array will > >> ensure that the calculations are done. > > > > If I use a counter incremented within each inner loop, then apparently > > 62 billion inner loops have been executed using gcc-O3. > > > > All in 8 seconds that the test runs for. Which is funny because just a > > plain loop doing nothing but incrementing a number 62 billion times > > takes 2 minutes to run, also with gcc-O3 but using volatile. > > > > So some odd things are going on. > > > > If this was testing vector capability, then fine. But as a general test > > of ordinary, ad hoc multiply operations that cannot be vectorised, then > > results will be misleading as it will make gcc look better than another > > compiler which doesn't have vector ops, when gcc in reality is not much > > better. > > > > It is meant to test integer matrix operations. So benefiting from > vectorization is fine. > > I just had a look at the asm generated by GCC 7 and 8 with -O3 > -march=native -S c90base-immul.c on a i7-7500U. While x86 asm is hard to > read for me (I am mostly just familiar with 8-bit architectures), it > seems the calculations are actually done (using SSE) and not optimized out. > The improvement from -O2 to -O3 is a factor of about 10 on my system. > > Philipp Just rubbish from Jesus Christ. But Jesus Christ has completely left objectivity behind and is just holding me responsible for the deeds of himself. Lying sack of shit does it every time. Then the flood begins. Because the mama's boy just has to run to other groups in an effort to get attention from someone. Anyone. Jesus Christ wants to punish us: If Jesus Christ can't be the focus here then his flooding crap will. No no. Jesus Christ never agreed to stop flooding. He lied about his trolling and that was that. Jesus Christ can not help but understand everyone knows he is just lying! Yup. It seems this is what we have to stop. Jerks who have no reason for being here other than to attack Jonathan Rhodes. This is undoubtedly a hobby of mine. A flaming bush that never burns, magnified by the reciprocal of the endless vastness of space, demonstrating the vast nothingness of Jesus Christ's so-called thought process. - Puppy Videos! https://prescottareapsychopaths.wordpress.com/mark-bilk-psychopath/ Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-04-16 10:08 +0200 |
| Message-ID | <pb1lm0$pj0$1@dont-email.me> |
| In reply to | #129237 |
On 16/04/18 00:29, bartc wrote: > On 15/04/2018 21:31, David Brown wrote: >> On 15/04/18 21:42, bartc wrote: > >>> So this might be part of the benchmark that can be unfairly optimised >>> (70 times improvement between -O3 and -O0 is remarkable, ... >> Unfair in that it is >>> possible the requested task is not being executed. >>> >> >> Looking at some generated assembly from this, it appears that at -O3 gcc >> is doing autovectorisation which can easily make a huge difference. >> >> It is also possible that at least some of the calculations can be >> skipped, but if my interpretation of the source code is correct based on >> a quick glance, the "volatile" marker in the source data array will >> ensure that the calculations are done. > > If I use a counter incremented within each inner loop, then apparently > 62 billion inner loops have been executed using gcc-O3. > > All in 8 seconds that the test runs for. Which is funny because just a > plain loop doing nothing but incrementing a number 62 billion times > takes 2 minutes to run, also with gcc-O3 but using volatile. > > So some odd things are going on. I haven't studied things well enough to guess. But unless you have made that loop counter volatile, gcc could quite possibly have figured out the total loop count and set it once to 62 billion. And while the "volatile" stuff in the source code means it can't pre-calculate or skip everything, it might be able to skip some of the calculations. > > If this was testing vector capability, then fine. But as a general test > of ordinary, ad hoc multiply operations that cannot be vectorised, then > results will be misleading as it will make gcc look better than another > compiler which doesn't have vector ops, when gcc in reality is not much > better. If gcc can vectorise the code and generate much faster code, then it /is/ that much better - for the code in question. If gcc can figure out that some calculations can be skipped entirely or handled at compile time, then it /is/ better for the code in question - it gives the results you asked for in the source code, and does so with shorter run times. That is a mark of a good compiler. (Things that can be pre-calculated, at least partially, turn up a lot in real code when you write general and flexible functions but only call them once or twice. It is especially common with link-time optimised code, or with header-heavy C++ libraries.) This is the whole problem with such benchmarks. They rarely test what you think they will, and they are rarely directly applicable to real code. In all testing and benchmarking, it is best if you can test with /your/ code, /your/ application. > > But as the OP said, this vectorisation is unlikely on the small devices > it is intended for testing on. > Yes. > (I ran the tests again with optimisations off. Then the difference > between fastest and slowest compiler was 1.3:1 instead of 3:1 (with gcc > 4th fastest). Here at least I know it is doing the work it has been told > to do. But you also know that the results are totally and utterly meaningless. Testing compiler speed with optimisation turned off is like comparing the speeds of cars in first gear. > > This is also better for me as I can more usefully tweak my code > generators to try and match the better compilers, as there are no scary > optimisations to try and replicate.) >
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-04-16 11:37 +0100 |
| Message-ID | <y1%AC.962735$fn3.874925@fx32.am4> |
| In reply to | #129245 |
On 16/04/2018 09:08, David Brown wrote: > On 16/04/18 00:29, bartc wrote: >> (I ran the tests again with optimisations off. Then the difference >> between fastest and slowest compiler was 1.3:1 instead of 3:1 (with gcc >> 4th fastest). Here at least I know it is doing the work it has been told >> to do. > > But you also know that the results are totally and utterly meaningless. > Testing compiler speed with optimisation turned off is like comparing > the speeds of cars in first gear. It is making sure that all cars are taking the same route /and/ do the same number of full circuits. Since they are all identical cars with the same engine, it's a useful way of finding out why the fastest one is 30% faster than the slowest. I can see this is not something that you worry about much as you are /only/ concerning with getting from A to B, even on a circuit test, and don't care if short cuts are taken. Nor about getting the slower vehicles up to speed; you will only hire the fastest. Testing only immul(), my own compiler is faster than gcc-O0. So I don't need to look at that code. But with isort() and compress(), overall gcc-O0 is faster, so I might want to have a quick look at why. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-04-16 22:42 +1200 |
| Message-ID | <fjjd0dFoi67U1@mid.individual.net> |
| In reply to | #129249 |
On 04/16/2018 10:37 PM, bartc wrote: > On 16/04/2018 09:08, David Brown wrote: >> On 16/04/18 00:29, bartc wrote: > >>> (I ran the tests again with optimisations off. Then the difference >>> between fastest and slowest compiler was 1.3:1 instead of 3:1 (with gcc >>> 4th fastest). Here at least I know it is doing the work it has been told >>> to do. >> >> But you also know that the results are totally and utterly meaningless. >> Testing compiler speed with optimisation turned off is like comparing >> the speeds of cars in first gear. > > It is making sure that all cars are taking the same route /and/ do the > same number of full circuits. Since they are all identical cars with the > same engine, it's a useful way of finding out why the fastest one is 30% > faster than the slowest. Testing cars with the handbrake on is a better analogy! -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-04-16 12:54 +0200 |
| Message-ID | <pb1vcv$iab$1@dont-email.me> |
| In reply to | #129249 |
On 16/04/18 12:37, bartc wrote: > On 16/04/2018 09:08, David Brown wrote: >> On 16/04/18 00:29, bartc wrote: > >>> (I ran the tests again with optimisations off. Then the difference >>> between fastest and slowest compiler was 1.3:1 instead of 3:1 (with gcc >>> 4th fastest). Here at least I know it is doing the work it has been told >>> to do. >> >> But you also know that the results are totally and utterly meaningless. >> Testing compiler speed with optimisation turned off is like comparing >> the speeds of cars in first gear. > > It is making sure that all cars are taking the same route /and/ do the > same number of full circuits. No, that is a totally incorrect analogy for compiler optimisation. > Since they are all identical cars with the > same engine, it's a useful way of finding out why the fastest one is 30% > faster than the slowest. What you want to compare is the time taken for the car to transport something (say, 100 people) from one place to another. If the car can do that by going faster, using a turbo, carrying more passengers, etc., then that is /fine/. That is what optimisation is about. If you limit the optimisation on the compiler, you are intentionally crippling it rather than testing the tool. What is vital is that you make sure all the passengers are picked up, and you make sure that all the passengers are delivered at the end. You do this in a benchmark by making sure that the input data is marked "volatile", and that the output data is marked "volatile". Any checkpoints along the way are handled by extra volatile variables. In between these points, anything goes. And if you find that the good optimising compiler has thrashed another tool because it has found shortcuts that you don't like, then the fault lies with the benchmark, not the compiler. > > I can see this is not something that you worry about much as you are > /only/ concerning with getting from A to B, even on a circuit test, and > don't care if short cuts are taken. Nor about getting the slower > vehicles up to speed; you will only hire the fastest. > What you do with the results - pick the best car, fix the slow ones, figure out speed per dollar ratios, etc., is up to you. > Testing only immul(), my own compiler is faster than gcc-O0. So I don't > need to look at that code. But with isort() and compress(), overall > gcc-O0 is faster, so I might want to have a quick look at why. > gcc -O0 is basically useless, and no one who understands compilers uses it for anything serious. The generated code has a very simplistic style, but is often harder to follow than -O1 due to the massive use of stack data. It can often be /much/ slower and /much/ bigger than -O1. It does not perform as good static analysis for warning checks, because it does not do as much analysis as optimised passes. It is not a "non-optimising compiler" in the eyes of "C should be what I think it used to be" fanatics, since it /does/ do some optimisations, such as assuming signed integer arithmetic never overflows. It is not even much faster than -O1. About the only use of -O0 is for syntax checking - or for pretending that your own compiler generates better code than gcc.
[toc] | [prev] | [next] | [standalone]
Page 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web