Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #56134 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2015-01-10 13:11 -0800 |
| Last post | 2015-01-20 00:12 -0800 |
| Articles | 20 on this page of 205 — 34 participants |
Back to article view | Back to comp.lang.c
faster than c fir <profesor.fir@gmail.com> - 2015-01-10 13:11 -0800
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-10 14:26 -0800
Re: faster than c Chad <cdalten@gmail.com> - 2015-01-10 14:43 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-10 15:20 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-10 15:39 -0800
Re: faster than c glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-11 09:23 +0000
Re: faster than c asetofsymbols@gmail.com - 2015-01-11 02:17 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-11 06:00 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-12 06:46 -0800
Re: faster than c Morris Dovey <mrdovey@iedu.com> - 2015-01-12 15:01 -0600
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-12 13:44 -0800
Re: faster than c Morris Dovey <mrdovey@iedu.com> - 2015-01-12 16:59 -0600
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-12 15:25 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-13 04:56 -0800
Re: faster than c glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-12 23:26 +0000
Re: faster than c jt@toerring.de (Jens Thoms Toerring) - 2015-01-13 01:10 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-13 05:16 -0800
faster than c Chad <cdalten@gmail.com> - 2015-01-10 14:42 -0800
Re: faster than c Cooler_x0a <c00f3r@gmail.com> - 2015-01-10 15:51 -0800
Re: faster than c Geoff <geoff@invalid.invalid> - 2015-01-11 00:21 -0800
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-11 02:27 -0800
Re: faster than c gamo <gamo@telecable.es> - 2015-01-11 12:17 +0100
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-11 21:02 +0100
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-21 03:44 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-21 05:08 -0800
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-21 13:53 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-21 06:03 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-22 15:06 +0100
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-22 06:57 -0800
Re: faster than c mark.bluemel@gmail.com - 2015-01-22 07:27 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-22 07:36 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-22 07:45 -0800
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 22:36 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-11 21:16 +0100
Re: faster than c Tim Prince <tprince@computer.org> - 2015-01-11 15:42 -0500
Re: faster than c Michael Angelo Ravera <maravera@prodigy.net> - 2015-01-14 12:25 -0800
Re: faster than c Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-01-17 13:29 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 05:32 -0800
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-01-17 14:42 +0100
Re: faster than c Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-01-17 19:29 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 11:55 -0800
Re: faster than c "Osmium" <r124c4u102@comcast.net> - 2015-01-17 08:00 -0600
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-17 10:15 -0800
Re: faster than c wssimms@gmail.com - 2015-01-17 10:31 -0800
Re: faster than c glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-17 19:10 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 11:21 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 11:13 -0800
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-01-17 12:32 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-19 11:01 +0100
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-01-19 08:24 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-19 22:52 +0100
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-20 00:04 -0600
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-01-19 10:12 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-19 23:05 +0100
Re: faster than c Öö Tiib <ootiib@hot.ee> - 2015-01-19 16:23 -0800
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 09:32 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-03-24 19:08 +0100
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 12:31 -0700
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-25 12:45 -0700
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-03-25 12:58 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-03-25 21:22 +0100
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 16:30 -0700
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-03-26 00:50 +0100
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 09:20 -0700
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-03-26 00:55 +0100
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-03-26 01:06 +0100
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-03-26 11:34 +0100
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-03-25 20:29 -0700
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 16:34 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-03-26 13:53 +1300
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 15:08 -0700
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-03-29 11:28 +1300
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-30 12:42 -0700
Re: faster than c Kaz Kylheku <kaz@kylheku.com> - 2015-03-30 20:06 +0000
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-03-31 16:37 +1300
Re: faster than c Kaz Kylheku <kaz@kylheku.com> - 2015-03-31 05:13 +0000
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-03-31 16:33 +1300
Re: faster than c Philip Lantz <prl@canterey.us> - 2015-03-31 00:14 -0700
Re: faster than c wssimms@gmail.com - 2015-01-17 10:33 -0800
Re: faster than c Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-17 20:03 +0000
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-19 11:07 +0100
Re: faster than c wpihughes@gmail.com - 2015-01-26 13:30 -0800
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-01-18 16:36 +1300
Re: faster than c glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-17 19:02 +0000
Re: faster than c BartC <bc@freeuk.com> - 2015-01-17 19:14 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 11:41 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 12:06 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-17 20:36 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 13:01 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-17 21:18 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 13:36 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-19 11:17 +0100
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-19 10:40 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 03:29 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 03:41 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-19 12:45 +0100
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 04:00 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 04:31 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 04:48 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-19 15:23 +0100
Re: faster than c mark.bluemel@gmail.com - 2015-01-19 07:25 -0800
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-19 08:56 -0800
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-19 17:01 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 09:08 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 09:19 -0800
Re: faster than c Bartc <bc@freeuk.com> - 2015-01-19 17:46 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 10:19 -0800
Re: faster than c Geoff <geoff@invalid.invalid> - 2015-01-19 10:56 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 11:30 -0800
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-01-19 14:22 -0800
Re: faster than c mark.bluemel@gmail.com - 2015-01-20 00:45 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-20 01:20 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 08:25 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-20 00:57 -0800
Re: faster than c fmassei@gmail.com - 2015-01-19 03:58 -0800
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-20 00:05 -0600
Re: faster than c fmassei@gmail.com - 2015-01-20 02:11 -0800
Re: faster than c asetofsymbols@gmail.com - 2015-01-20 02:18 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-20 02:30 -0800
Re: faster than c asetofsymbols@gmail.com - 2015-01-20 05:16 -0800
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-01-20 14:18 +0100
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-20 15:29 -0600
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-20 21:53 +0000
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-20 17:37 -0600
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-21 00:05 +0000
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-21 01:38 -0600
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-21 07:46 +0000
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-21 03:23 -0800
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-21 13:52 +0000
Re: faster than c Morris Dovey <mrdovey@iedu.com> - 2015-01-21 08:53 -0600
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-01-21 01:18 +0100
Re: faster than c fmassei@gmail.com - 2015-01-20 16:41 -0800
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-01-21 01:58 +0100
Re: faster than c fmassei@gmail.com - 2015-01-20 17:11 -0800
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-01-21 02:18 +0100
Re: faster than c fmassei@gmail.com - 2015-01-20 17:38 -0800
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-01-21 08:48 -0800
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-20 15:24 -0600
Re: faster than c fmassei@gmail.com - 2015-01-20 13:38 -0800
Re: faster than c Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-21 16:43 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-21 10:09 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-24 01:15 -0800
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-21 23:59 -0600
Re: faster than c fmassei@gmail.com - 2015-01-22 01:17 -0800
Re: faster than c wssimms@gmail.com - 2015-01-22 05:16 -0800
Re: faster than c fmassei@gmail.com - 2015-01-22 05:27 -0800
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-22 05:36 -0800
Re: faster than c fmassei@gmail.com - 2015-01-22 05:54 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-22 05:55 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-22 15:18 +0100
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-01-23 00:53 -0600
Re: faster than c fmassei@gmail.com - 2015-01-23 00:36 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-23 01:09 -0800
Re: faster than c fmassei@gmail.com - 2015-01-23 01:33 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-23 01:55 -0800
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-01-23 22:44 +1300
Re: faster than c fmassei@gmail.com - 2015-01-23 01:56 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-22 15:11 +0100
Re: faster than c fmassei@gmail.com - 2015-01-22 06:21 -0800
Re: faster than c David Brown <david.brown@hesbynett.no> - 2015-01-22 16:46 +0100
Re: faster than c fmassei@gmail.com - 2015-01-22 07:58 -0800
Re: faster than c Lowell Gilbert <lgusenet@be-well.ilk.org> - 2015-01-22 12:29 -0500
Re: faster than c fmassei@gmail.com - 2015-01-22 10:09 -0800
Re: faster than c "Chris M. Thomasson" <no@spam.invalid> - 2015-01-22 14:07 -0800
Re: faster than c asetofsymbols@gmail.com - 2015-01-24 00:40 -0800
Re: faster than c "Chris M. Thomasson" <no@spam.invalid> - 2015-01-24 12:53 -0800
Re: faster than c Greg Martin <greg.at.softsprocket@dot.com> - 2015-01-22 15:09 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-22 01:59 -0800
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-24 09:46 -0700
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-03-25 02:15 -0500
Re: faster than c asetofsymbols@gmail.com - 2015-03-25 02:45 -0700
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-25 11:30 -0700
Re: faster than c Robert Wessel <robertwessel2@yahoo.com> - 2015-03-26 00:42 -0500
Re: faster than c Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-28 11:35 -0700
Re: faster than c Keith Thompson <kst-u@mib.org> - 2015-01-17 14:42 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-17 22:53 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 15:13 -0800
Re: faster than c glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-17 22:02 +0000
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-17 16:21 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-18 01:27 +0000
Re: faster than c glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-01-18 01:41 +0000
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-18 00:11 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-18 11:23 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-18 05:55 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-18 20:11 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-18 13:12 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-18 23:11 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-18 15:49 -0800
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-18 16:06 -0800
Re: faster than c Bartc <bc@freeuk.com> - 2015-01-19 01:03 +0000
Re: faster than c Richard Heathfield <invalid@see.sig.invalid> - 2015-01-19 08:13 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-19 01:39 -0800
Re: faster than c Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-01-18 13:52 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-18 23:36 +0000
Re: faster than c Walter Banks <walter@bytecraft.com> - 2015-01-20 14:01 -0500
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-20 11:18 -0800
Re: faster than c Melzzzzz <mel@zzzzz.com> - 2015-01-17 22:30 +0100
Re: faster than c Ian Collins <ian-news@hotmail.com> - 2015-01-18 16:49 +1300
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 05:55 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-17 14:30 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 07:32 -0800
Re: faster than c BartC <bc@freeuk.com> - 2015-01-17 15:56 +0000
Re: faster than c fir <profesor.fir@gmail.com> - 2015-01-17 08:33 -0800
Re: faster than c fmassei@gmail.com - 2015-01-19 02:26 -0800
faster than c asetofsymbols@gmail.com - 2015-01-20 00:12 -0800
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-01-18 01:41 +0000 |
| Message-ID | <m9f2vt$29v$1@speranza.aioe.org> |
| In reply to | #56408 |
BartC <bc@freeuk.com> wrote:
(snip, someone wrote
>>> a = b*c;
>>> Not much to optimise here, unless a, b and c are large
>>> matrices perhaps.
(snip)
> I don't follow. The programmer /needs/ to multiply two matrices to
> produce a third; the work needs to be done.
> The choice is between giving a hint to the compiler:
> 'I want to multiply matrix b by c; you know the sizes; just do it using
> fastest, most efficient, tried and tested method you have', but written
> as 'a=b*c'.
OK, how about:
a = b*spread(c,1,size(b,2))
(This was actually suggested in a recent Fortran newsgroup post,
though I believe using a constant instead of size.)
-- glen
> Or presenting the compiler instead with a page of code full of nested
> loops and arithmetic, which it will have no idea what it does, but just
> has to optimise as best it can.
>
> When the compiler knows what is being done, it might then be able to
> optimise in ways not otherwise possible (for example, checking for
> diagonal matrices in some cases when the calculations can be simplified).
>
> (And actually my example came from an interpreted language, whose
> runtime can do the arithmetic using the fast, statically compiled code
> that the interpreter is written in, rather than do it using interpreted
> code. In that situation having a built-in can make a magnitude or two of
> difference.)
>
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-01-18 00:11 -0800 |
| Message-ID | <483cedfe-96e9-4e75-b6ca-0ab2fd3a7829@googlegroups.com> |
| In reply to | #56408 |
On Sunday, January 18, 2015 at 1:27:47 AM UTC, Bart wrote: > > I don't follow. The programmer /needs/ to multiply two matrices to > produce a third; the work needs to be done. > But if we say a = a * b (a and b matrices) then we need an intermediate and to copy it to a, at least with most matrix multiplication algorithms. C makes the need for this explicit, so programmers don't tend to do the extra copy step unless it is truly necessary. And a simple higher level language will tend to always do the copy, even for a = b * c. > > The choice is between giving a hint to the compiler: > > 'I want to multiply matrix b by c; you know the sizes; just do it using > fastest, most efficient, tried and tested method you have', but written > as 'a=b*c'. > > Or presenting the compiler instead with a page of code full of nested > loops and arithmetic, which it will have no idea what it does, but just > has to optimise as best it can. > > When the compiler knows what is being done, it might then be able to > optimise in ways not otherwise possible (for example, checking for > diagonal matrices in some cases when the calculations can be simplified). > > (And actually my example came from an interpreted language, whose > runtime can do the arithmetic using the fast, statically compiled code > that the interpreter is written in, rather than do it using interpreted > code. In that situation having a built-in can make a magnitude or two of > difference.) > Matlab has some very good matrix multiplication code built in. It also has a C interface. If you write a function in Matlab, then translate to C, typically you get a 10x speedup, but only if you know what you're doing - there's no point trying to beat the eigenvector code, for example, it's bound to be extremely well- written and you're unlikely to gain more than small percentage, even by investing enormous development effort. On the other hand a string search, which Matlab handles poorly, will go ten to twenty times faster.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-01-18 11:23 +0000 |
| Message-ID | <iJMuw.243694$lm5.1323@fx36.am4> |
| In reply to | #56413 |
On 18/01/2015 08:11, Malcolm McLean wrote: > On Sunday, January 18, 2015 at 1:27:47 AM UTC, Bart wrote: >> >> I don't follow. The programmer /needs/ to multiply two matrices to >> produce a third; the work needs to be done. >> > But if we say a = a * b (a and b matrices) then we need an intermediate > and to copy it to a, at least with most matrix multiplication > algorithms. > C makes the need for this explicit, so programmers don't tend to > do the extra copy step unless it is truly necessary. And a simple > higher level language will tend to always do the copy, even for > a = b * c. That is both the advantage and disadvantage of using C. The advantage is managing to get a bit of extra speed (if it is needed). The disadvantage is having to constantly check for overwriting and aliasing and updating in-place, and worrying about where to put intermediates and who's going to manage the memory allocations, instead of looking at the bigger picture and just getting the task accomplished. And after all that, maybe the speed wasn't that critical. Or maybe you're in the middle of development where these operations are going to be added or removed all the time; no point in wasting time on such considerations before the thing works properly! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-01-18 05:55 -0800 |
| Message-ID | <b365f3c4-4439-44be-8ec5-9bd7d1a8369a@googlegroups.com> |
| In reply to | #56416 |
W dniu niedziela, 18 stycznia 2015 12:24:11 UTC+1 użytkownik Bart napisał: > On 18/01/2015 08:11, Malcolm McLean wrote: > > On Sunday, January 18, 2015 at 1:27:47 AM UTC, Bart wrote: > >> > >> I don't follow. The programmer /needs/ to multiply two matrices to > >> produce a third; the work needs to be done. > >> > > But if we say a = a * b (a and b matrices) then we need an intermediate > > and to copy it to a, at least with most matrix multiplication > > algorithms. > > C makes the need for this explicit, so programmers don't tend to > > do the extra copy step unless it is truly necessary. And a simple > > higher level language will tend to always do the copy, even for > > a = b * c. > > That is both the advantage and disadvantage of using C. > > The advantage is managing to get a bit of extra speed (if it is needed). > > The disadvantage is having to constantly check for overwriting and > aliasing and updating in-place, and worrying about where to put > intermediates and who's going to manage the memory allocations, instead > of looking at the bigger picture and just getting the task accomplished. > > And after all that, maybe the speed wasn't that critical. Or maybe > you're in the middle of development where these operations are going to > be added or removed all the time; no point in wasting time on such > considerations before the thing works properly! > if you want bigger picture in matrix algebra in c you could probably use library (i was never doin matrx algebra) if you want specyfic optymisations probebly it is right way to get c code and think on it.. i dont know (this "half-buitin" proposal of you doeasn seem much fun for me, doubt also in proficiency of this, i would preffer to take harder route and optymise it myself or tak some solution of others than to count on compiler builtins; relain on compiler is something like bit worse to mythan relayin on library, compiler efficiency is more obscure then library implementation, changes in more unpleasant way, also history teaches me that it fou do not take look into internals yourself youre exposed to efficiency glitches, i do not belive to much in both libraries and compilers)
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-01-18 20:11 +0000 |
| Message-ID | <4sUuw.131356$394.66573@fx25.am4> |
| In reply to | #56419 |
On 18/01/2015 13:55, fir wrote: > > if you want specyfic optymisations > probebly it is right way to get c > code and think on it.. i dont know > > (this "half-buitin" proposal of you > doeasn seem much fun for me, doubt also in proficiency of this, i would preffer to take harder route and optymise it myself or tak some solution of others than to count on compiler builtins; relain on compiler is something like bit worse to mythan relayin on library, compiler efficiency is more obscure then library implementation, changes in more unpleasant way, also history teaches me that it fou do not take look into internals yourself youre exposed to efficiency glitches, i do not belive to much in both libraries and compilers) > I develop interpreters and I've tried a few approaches to try and get them faster. On one set of benchmarks, using gcc -O3 (the fastest compiled C code I have available), the total timing was 28 seconds using Standard C. Then I used a feature in C that was a gcc extension so not so portable. Using that, the timing was 25 seconds. I also developed my own language and compiler just for this purpose. With that, the timing was 33 seconds; not as good as gcc/O3, but not bad considering how much effort has gone into gcc. (But I'm not done yet with the code generator for that.) However, with my own language, it is easier to integrate some ASM code to take care of some bottlenecks. With my language plus one ASM module the timing was 12 seconds - twice as fast as the best C! The downside is that I lose portability (I only target x64), so I maintain the C version too. (With real programs rather than benchmarks, the timings are closer and more variable, but can still be typically in 2:3:4 proportions when comparing my HLL+ASM to fastest C to my HLL.) Anyway that just shows there are other alternatives to just sticking with C. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-01-18 13:12 -0800 |
| Message-ID | <0c1a9f3d-a289-4e0e-947e-a1735ca963d6@googlegroups.com> |
| In reply to | #56428 |
W dniu niedziela, 18 stycznia 2015 21:11:54 UTC+1 użytkownik Bart napisał: > On 18/01/2015 13:55, fir wrote: > > > > > if you want specyfic optymisations > > probebly it is right way to get c > > code and think on it.. i dont know > > > > (this "half-buitin" proposal of you > > doeasn seem much fun for me, doubt also in proficiency of this, i would preffer to take harder route and optymise it myself or tak some solution of others than to count on compiler builtins; relain on compiler is something like bit worse to mythan relayin on library, compiler efficiency is more obscure then library implementation, changes in more unpleasant way, also history teaches me that it fou do not take look into internals yourself youre exposed to efficiency glitches, i do not belive to much in both libraries and compilers) > > > > I develop interpreters and I've tried a few approaches to try and get > them faster. > > On one set of benchmarks, using gcc -O3 (the fastest compiled C code I > have available), the total timing was 28 seconds using Standard C. > > Then I used a feature in C that was a gcc extension so not so portable. > Using that, the timing was 25 seconds. > > I also developed my own language and compiler just for this purpose. > With that, the timing was 33 seconds; not as good as gcc/O3, but not bad > considering how much effort has gone into gcc. (But I'm not done yet > with the code generator for that.) > > However, with my own language, it is easier to integrate some ASM code > to take care of some bottlenecks. With my language plus one ASM module > the timing was 12 seconds - twice as fast as the best C! > > The downside is that I lose portability (I only target x64), so I > maintain the C version too. > > (With real programs rather than benchmarks, the timings are closer and > more variable, but can still be typically in 2:3:4 proportions when > comparing my HLL+ASM to fastest C to my HLL.) > > Anyway that just shows there are other alternatives to just sticking with C. > i really dislike such kind of answers, not specyfic and wrong generalisations leading to effectively false pseudo-conclusions (do not want to continue this )
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-01-18 23:11 +0000 |
| Message-ID | <15Xuw.190454$fD1.134193@fx37.am4> |
| In reply to | #56430 |
On 18/01/2015 21:12, fir wrote: > W dniu niedziela, 18 stycznia 2015 21:11:54 UTC+1 użytkownik Bart napisał: >> On 18/01/2015 13:55, fir wrote: >> >>> >>> if you want specyfic optymisations >>> probebly it is right way to get c >>> code and think on it.. i dont know >>> >>> (this "half-buitin" proposal of you >>> doeasn seem much fun for me, doubt also in proficiency of this, i would preffer to take harder route and optymise it myself or tak some solution of others than to count on compiler builtins; relain on compiler is something like bit worse to mythan relayin on library, compiler efficiency is more obscure then library implementation, changes in more unpleasant way, also history teaches me that it fou do not take look into internals yourself youre exposed to efficiency glitches, i do not belive to much in both libraries and compilers) >>> >> >> I develop interpreters and I've tried a few approaches to try and get >> them faster. ... >> Anyway that just shows there are other alternatives to just sticking with C. >> > i really dislike such kind of answers, > not specyfic It is very specific. The thread title is 'faster than C'. I explained one approach I used to get faster than C, /which I have actually done and it was, in fact, faster than C/. > and wrong generalisations leading to effectively false pseudo-conclusions What was the conclusion? And why was it false? > (do not want to continue this ) Well, I would really like to know exactly what you after. Why don't you give an example of the sort of answer you would like to hear? Unless you are playing some sort of game which involves dismissing every post or disagreeing with anyone else's opinions, then I can play along too until I get bored (or 'tired'). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-01-18 15:49 -0800 |
| Message-ID | <60f57950-41dd-4e6e-bb71-234b049f6c2d@googlegroups.com> |
| In reply to | #56437 |
W dniu poniedziałek, 19 stycznia 2015 00:12:07 UTC+1 użytkownik Bart napisał: > On 18/01/2015 21:12, fir wrote: > > W dniu niedziela, 18 stycznia 2015 21:11:54 UTC+1 użytkownik Bart napisał: > >> On 18/01/2015 13:55, fir wrote: > >> > >>> > >>> if you want specyfic optymisations > >>> probebly it is right way to get c > >>> code and think on it.. i dont know > >>> > >>> (this "half-buitin" proposal of you > >>> doeasn seem much fun for me, doubt also in proficiency of this, i would preffer to take harder route and optymise it myself or tak some solution of others than to count on compiler builtins; relain on compiler is something like bit worse to mythan relayin on library, compiler efficiency is more obscure then library implementation, changes in more unpleasant way, also history teaches me that it fou do not take look into internals yourself youre exposed to efficiency glitches, i do not belive to much in both libraries and compilers) > >>> > >> > >> I develop interpreters and I've tried a few approaches to try and get > >> them faster. > ... > >> Anyway that just shows there are other alternatives to just sticking with C. > >> > > i really dislike such kind of answers, > > not specyfic > > It is very specific. > > The thread title is 'faster than C'. I explained one approach I used to > get faster than C, /which I have actually done and it was, in fact, > faster than C/. > > > and wrong generalisations leading to effectively false pseudo-conclusions > > What was the conclusion? And why was it false? > > > (do not want to continue this ) > > Well, I would really like to know exactly what you after. > > Why don't you give an example of the sort of answer you would like to hear? > > Unless you are playing some sort of game which involves dismissing every > post or disagreeing with anyone else's opinions, then I can play along > too until I get bored (or 'tired'). > got no time to that and just dislike that, in short you often make wrong and uninteresting generelisations** - even her you continue to do this i do not dismiss "every" post, or disagree with "anyone else " opinion etc ** note that it has to weak points, specyfics (like real examples, cases etc) are more informative, (if true, but it is harder to make false specyfics) generatlisations are valueble when true and interesying, but less than zero valuable when wrong really i got no time for this .. what is an answer i can get - just true answer, true generalisms or true specyfics what was conclusion and why was false, that was about only one conclusion: that you wrote something twice faster than "best c" - whay it was false? becouse here such 'best c' is obviously just 'poor c compiled with -O3', extremmaly poor kind of best c, really :C that post of you was extremally weak, nothing interesting yet false making and big time wasting - got no time for that, I should probably not answer at all (not being ill-mannered really 9i consider myself being really constructive etc) but just dont want to spoil 2 (or more) hours of my life)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-01-18 16:06 -0800 |
| Message-ID | <38409787-2e52-4a84-9ac1-d922cc6d84d5@googlegroups.com> |
| In reply to | #56444 |
W dniu poniedziałek, 19 stycznia 2015 00:49:40 UTC+1 użytkownik fir napisał: > W dniu poniedziałek, 19 stycznia 2015 00:12:07 UTC+1 użytkownik Bart napisał: > > On 18/01/2015 21:12, fir wrote: > > > W dniu niedziela, 18 stycznia 2015 21:11:54 UTC+1 użytkownik Bart napisał: > > >> On 18/01/2015 13:55, fir wrote: > > >> > > >>> > > >>> if you want specyfic optymisations > > >>> probebly it is right way to get c > > >>> code and think on it.. i dont know > > >>> > > >>> (this "half-buitin" proposal of you > > >>> doeasn seem much fun for me, doubt also in proficiency of this, i would preffer to take harder route and optymise it myself or tak some solution of others than to count on compiler builtins; relain on compiler is something like bit worse to mythan relayin on library, compiler efficiency is more obscure then library implementation, changes in more unpleasant way, also history teaches me that it fou do not take look into internals yourself youre exposed to efficiency glitches, i do not belive to much in both libraries and compilers) > > >>> > > >> > > >> I develop interpreters and I've tried a few approaches to try and get > > >> them faster. > > ... > > >> Anyway that just shows there are other alternatives to just sticking with C. > > >> > > > i really dislike such kind of answers, > > > not specyfic > > > > It is very specific. > > > > The thread title is 'faster than C'. I explained one approach I used to > > get faster than C, /which I have actually done and it was, in fact, > > faster than C/. > > > > > and wrong generalisations leading to effectively false pseudo-conclusions > > > > What was the conclusion? And why was it false? > > > > > (do not want to continue this ) > > > > Well, I would really like to know exactly what you after. > > > > Why don't you give an example of the sort of answer you would like to hear? > > > > Unless you are playing some sort of game which involves dismissing every > > post or disagreeing with anyone else's opinions, then I can play along > > too until I get bored (or 'tired'). > > > > got no time to that and just dislike that, in short you often make wrong and uninteresting generelisations** - > > even her you continue to do this i do not dismiss "every" post, or disagree with "anyone else " opinion etc > > ** note that it has to weak points, specyfics (like real examples, cases etc) are more informative, (if true, but it is harder to make false specyfics) > > generatlisations are valueble when > true and interesying, but less than zero valuable when wrong > > really i got no time for this .. > > what is an answer i can get - just true answer, true generalisms or true specyfics > > what was conclusion and why was false, > that was about only one conclusion: > that you wrote something twice faster than "best c" - whay it was false? > becouse > here such 'best c' is obviously just 'poor c compiled with -O3', extremmaly poor kind of best c, really :C > > that post of you was extremally weak, > nothing interesting yet false making > and big time wasting - got no time for that, I should probably not answer at all (not being ill-mannered really 9i consider myself being really constructive etc) but just dont want to spoil 2 (or more) hours of my life) ps besides unintersting and wrong youre going out of the wuestion and this is very side note for me, ofc you can produce side notes (i very often like to do that) but as i am not showed that i am interesting in this kind of side topic yopu should not adres it to me but better left it as unadressed one sdo i wiuld not feel that i have to answer on uninteresting side notes.. thats all, i dont want to continue this (no 'offence', i already said find you as a sympathtic user in general, and quite intelligent, but sometimes you are 'acting' a bit strange)
[toc] | [prev] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-01-19 01:03 +0000 |
| Message-ID | <m9hl3c$ulf$1@dont-email.me> |
| In reply to | #56447 |
On 19/01/2015 00:06, fir wrote: > W dniu poniedziałek, 19 stycznia 2015 00:49:40 UTC+1 użytkownik fir napisał: >> W dniu poniedziałek, 19 stycznia 2015 00:12:07 UTC+1 użytkownik Bart napisał: >>>> i really dislike such kind of answers, >>> >>>> and wrong generalisations leading to effectively false pseudo-conclusions >> got no time to that and just dislike that, in short you often make wrong and uninteresting generelisations** - >> ** note that it has to weak points, specyfics (like real examples, cases etc) are more informative, (if true, but it is harder to make false specyfics) >> really i got no time for this .. >> >> what is an answer i can get - just true answer, true generalisms or true specyfics >> >> what was conclusion and why was false, >> that was about only one conclusion: >> that you wrote something twice faster than "best c" - whay it was false? >> becouse >> here such 'best c' is obviously just 'poor c compiled with -O3', extremmaly poor kind of best c, really :C Nevertheless, I managed to get /exactly the same/ algorithm running faster than in C, in some cases double the speed. Fact. And the thread topic just happens to be 'faster than C'. >> that post of you was extremally weak, >> nothing interesting yet false making >> and big time wasting - got no time for that, I should probably not answer at all (not being ill-mannered really 9i consider myself being really constructive etc) but just dont want to spoil 2 (or more) hours of my life) > > ps besides unintersting and wrong youre going out of the wuestion OK, I get it. My responses are weak, uninteresting, off-topic, and wrong! Or too general, or too specific. I'm even wasting your time forcing you to read them. (Forget the time wasted by the dozens of people responding to all your numerous threads trying to help you!) > (no 'offence' And I'm getting the impression that you have no idea what you're talking about and have no idea either exactly what you want. No offence! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <invalid@see.sig.invalid> |
|---|---|
| Date | 2015-01-19 08:13 +0000 |
| Message-ID | <513vw.221113$c03.9689@fx42.am4> |
| In reply to | #56450 |
Bartc wrote: > On 19/01/2015 00:06, fir wrote: <snip> >> ps besides unintersting and wrong youre going out of the wuestion > > OK, I get it. My responses are weak, uninteresting, off-topic, and > wrong! Bart, you are in excellent company. I wouldn't worry about it. > Or too general, or too specific. I'm even wasting your time > forcing you to read them. (Forget the time wasted by the dozens of > people responding to all your numerous threads trying to help you!) Don't worry. He will. > > > (no 'offence' > > And I'm getting the impression that you have no idea what you're talking > about and have no idea either exactly what you want. Neither, alas, does anyone else know *precisely* what he's talking about, because he is either unwilling or unable to communicate clearly. Judging as best I can from his own claims, it is not inability but sheer stupid pig- headedness that drives him to obscure his meaning behind ridiculous misspellings. it sa if i wer t o try or o write without renenberign where a;l;l the letters are. (Actually, that's too legible. To write as badly as him, typographical errors are insufficient - I would have to hand-craft it.) > No offence! A somewhat tongue-in-cheek response, which is understandable. This fir character seeks to give offence at every turn, but always pretends otherwise. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-01-19 01:39 -0800 |
| Message-ID | <902627ce-62a1-487f-b1b6-d77f43131cd6@googlegroups.com> |
| In reply to | #56455 |
W dniu poniedziałek, 19 stycznia 2015 09:14:08 UTC+1 użytkownik Richard Heathfield napisał: > it is not inability but sheer stupid pig- > headedness that drives him this is insult, Richard this is general problem instead of leave some matters to more inteligent people, (not all here on your level of thinking) you judge this in your own simple and insulting way and just create this simple insulting reality (take care i am totally out of this, may be a little sad to read it as you flying low)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-01-18 13:52 -0800 |
| Message-ID | <d9eb4179-d0a1-4088-ae19-0c7c78dfb4ad@googlegroups.com> |
| In reply to | #56428 |
On Sunday, January 18, 2015 at 8:11:54 PM UTC, Bart wrote: > > However, with my own language, it is easier to integrate some ASM code > to take care of some bottlenecks. With my language plus one ASM module > the timing was 12 seconds - twice as fast as the best C! > The test is conducted by someone who is also advocating one of the methods being benchmarked. So of course on most measures it will show at least one point of superiority. That doesn't tell you nothing - it means it's possible to construct a problem which isn't too outrageously artificial on which the favoured method excels, which means it has to be in some sense a competitor. But you can't take the results at face value either.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-01-18 23:36 +0000 |
| Message-ID | <QrXuw.150707$QY7.44135@fx21.am4> |
| In reply to | #56432 |
On 18/01/2015 21:52, Malcolm McLean wrote: > On Sunday, January 18, 2015 at 8:11:54 PM UTC, Bart wrote: >> >> However, with my own language, it is easier to integrate some ASM code >> to take care of some bottlenecks. With my language plus one ASM module >> the timing was 12 seconds - twice as fast as the best C! >> > The test is conducted by someone who is also advocating one of > the methods being benchmarked. So of course on most measures it > will show at least one point of superiority. That doesn't tell you > nothing - it means it's possible to construct a problem which isn't > too outrageously artificial on which the favoured method excels, > which means it has to be in some sense a competitor. But you can't > take the results at face value either. But I gave two of my results that weren't from C, one was slower, the other faster! And there is no point in deceiving myself on the figures either. I've tested the three versions on as real an application as I have, which is a compiler. The following elapsed times were shown by by IDE to compile all modules of a compiler (ie. a compiler compiling itself): MyHLL+ASM 1.4 seconds C/gcc/O3 2.3 seconds** (note this figure was not right) MyHLL 2.2 seconds However something didn't quite ring true here; normally gcc is much faster than my compiler. It took some investigation to discover that the "-std=c99" switch I've recently started using with gcc seems, somehow, to be slowing it down. Removing that switch (these are built-in to my IDE so is not so easy) gives the results I'd expected: MyHLL+ASM 1.4 seconds C/gcc/O3 1.8 seconds MyHLL 2.2 seconds (And the 25 seconds I'd quoted in a previous post should be just under 24 seconds.) One problem here is that there is not just one C version, there can be dozens, depending on choice of compiler and compiler options. Many variations, if they haven't be tested for a while, also tend to stop working. The timing shown here is that of the fastest combination I have: gcc for x86 in 32-bit mode, -O3 optimisation, and *no* -std=c99 switch! (I've no idea why C99 mode should slow down the compiler.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Walter Banks <walter@bytecraft.com> |
|---|---|
| Date | 2015-01-20 14:01 -0500 |
| Message-ID | <54BEA5F8.197BA5D7@bytecraft.com> |
| In reply to | #56383 |
glen herrmannsfeldt wrote: > Jorgen Grahn <grahn+nntp@snipabacken.se> wrote: > > On Sat, 2015-01-10, fir wrote: > > >> there are some languages that are low level like c [...] I mean some > >> languages that could teoretically compete with c in efficiency.. do > >> maybe some of such language some solution that make the outcome > >> program to be faster (or equally speed but with different solution) > >> comparing to c? > > > I have a hard time parsing your question, but C++ tends to be faster > > than C. > > Why would that be? > > > Plenty of other languages are faster, in specialized cases. > > If you use the fancier features of any language, usually that allow > for less work by the programmer, they often have more run-time > overhead. A simpler language requires more work by the programmer, > and often runs faster as a result. That may or may not be true. The more information that a compiler has about an application the better it can optimize. The vicious circle many developers get into is deciding if they are describing a problem for a set of code generating tools or implementing a solution. Simple solutions do not always produce the best (depending on the definition of "best") results. In the long battles between asm vs C implementation it is clear that asm "could" always produce an equal or better solution to C, but that is rarely true except for trivial programs. Compiler can do many things that asm programmers cannot easily do. (accounting, ram allocation, full ISA usage and execution threads for example) In languages where a lot of unambiguous application information is available to the compiler then very tight application code can be created. w..
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-01-20 11:18 -0800 |
| Message-ID | <8b4c45f7-6613-4617-90f5-ff8ced8c91c7@googlegroups.com> |
| In reply to | #56526 |
W dniu wtorek, 20 stycznia 2015 19:58:27 UTC+1 użytkownik Walter Banks napisał: > glen herrmannsfeldt wrote: > > > Jorgen Grahn <grahn+nntp@snipabacken.se> wrote: > > > On Sat, 2015-01-10, fir wrote: > > > > >> there are some languages that are low level like c [...] I mean some > > >> languages that could teoretically compete with c in efficiency.. do > > >> maybe some of such language some solution that make the outcome > > >> program to be faster (or equally speed but with different solution) > > >> comparing to c? > > > > > I have a hard time parsing your question, but C++ tends to be faster > > > than C. > > > > Why would that be? > > > > > Plenty of other languages are faster, in specialized cases. > > > > If you use the fancier features of any language, usually that allow > > for less work by the programmer, they often have more run-time > > overhead. A simpler language requires more work by the programmer, > > and often runs faster as a result. > > That may or may not be true. The more information that a > compiler has about an application the better it can optimize. > The vicious circle many developers get into is deciding if they > are describing a problem for a set of code generating tools > or implementing a solution. > > Simple solutions do not always produce the best (depending on > the definition of "best") results. In the long battles between > asm vs C implementation it is clear that asm "could" always > produce an equal or better solution to C, but that is rarely true > except for trivial programs. > imo this is rarely non true though in real world the ease of obtaining something my count quite much (asm is too hard for me, some c routines build about sse intrincisc?, ye i can stand it ) > Compiler can do many things that asm programmers cannot > easily do. (accounting, ram allocation, full ISA usage and > execution threads for example) > > In languages where a lot of unambiguous application information > is available to the compiler then very tight application code can > be created. >
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2015-01-17 22:30 +0100 |
| Message-ID | <20150117223018.2a4b6590@maxa-pc> |
| In reply to | #56368 |
On 17 Jan 2015 21:21:34 GMT ram@zedat.fu-berlin.de (Stefan Ram) wrote: > Jorgen Grahn <grahn+nntp@snipabacken.se> writes: > >I have a hard time parsing your question, but C++ tends to be faster > >than C. > > C++ does not have the »restrict« qualifier. > So, C++ compilers can't make all the optimizations, > C compilers can do. > > In fact, the famous »shootout« benchmark site shows > C to be faster than C++. > Actually shootout shows them as about equal? What interests me is lines of code, not benchmark ;) C and C++ are both similar in this case, too
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-01-18 16:49 +1300 |
| Message-ID | <ci0oqfFgs9mU2@mid.individual.net> |
| In reply to | #56368 |
Stefan Ram wrote: > Jorgen Grahn <grahn+nntp@snipabacken.se> writes: >> I have a hard time parsing your question, but C++ tends to be faster >> than C. > > C++ does not have the »restrict« qualifier. > So, C++ compilers can't make all the optimizations, > C compilers can do. While correct (I suspect due in part to the added complexity of pass by reference), a number of C++ compilers support restrict as an extension. I also suspect there are fewer uses cases for restrict in typical C++ code where templates are used in preference to void* than there are in C. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2015-01-17 05:55 -0800 |
| Message-ID | <e01b784f-47b6-42ab-8c46-01545793af95@googlegroups.com> |
| In reply to | #56134 |
ps somewhere here was some thread on possible simple types that could be nice to have i c/asm (couldnt find where it was) recently think that maybe 32 bit size 3d vertex could be usefull to get, I like rich geometry in games (dilike texturing), got some complex model of vader tie it is 100k triangles, traingle is 9 floats, which makes 3.6MB of geometry in ram and file.. probably using 32bit iny-like vertex instead of 3 floats would suffice to encode model, making it 3 times smaller as an intermediate format
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-01-17 14:30 +0000 |
| Message-ID | <Amuuw.218897$7p1.28465@fx03.am4> |
| In reply to | #56372 |
On 17/01/2015 13:55, fir wrote: > ps somewhere here was some thread on possible simple types that could be nice to have i c/asm (couldnt find where it was) > > recently think that maybe 32 bit size 3d vertex could be usefull to get, I like rich geometry in games (dilike texturing), got some complex model of vader tie it is 100k triangles, traingle is 9 floats, which makes 3.6MB of geometry in ram and file.. probably using 32bit iny-like vertex instead of > 3 floats would suffice to encode model, > making it 3 times smaller as an intermediate format You're representing each triangle independently? In most models, triangles will share edges and vertices, so reducing the amount of data needed (but requiring more structure). Also, if you have separate objects that are the same shape, they can share the same collection of triangles (but will need to be transformed into a different location, size and orientation). This reduces space requirements but might need extra processing if it can't be incorporated into what is already being done. If the triangles represent a curved surface, you might try smoother shading then you might get away with fewer triangles. That depends on how the triangle data is generated. If triangles are generated on-the-fly, then you could try evaluating the overall size of the object on the screen, and if it's small, then use a smaller and therefore faster number of triangles. But the scene will now be made up of more highly structured objects and it becomes harder to work in real time if that's what you're after. (It's not clear where you model data comes from; maybe there is a already some hierarchical 3D model somewhere which has already been flattened into a linear display-list of triangles.) -- Bartc
[toc] | [prev] | [next] | [standalone]
Page 10 of 11 — ← Prev page 1 … 8 9 [10] 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web