Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #96532 > unrolled thread

Simplest compiler for C

Back to article view | Back to comp.lang.c

Contents

  Simplest compiler for C "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-14 18:57 +0800
    Re: Simplest compiler for C Mark Storkamp <mstorkamp@yahoo.com> - 2016-11-14 08:44 -0600
      Re: Simplest compiler for C "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-14 22:46 +0800
    Re: Simplest compiler for C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-14 08:15 -0800
      Re: Simplest compiler for C "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-15 01:29 +0800
        Re: Simplest compiler for C Dutch Ingraham <spikeheron@att.net> - 2016-11-14 11:43 -0600
          Re: Simplest compiler for C "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-15 19:18 +0800
        Re: Simplest compiler for C BartC <bc@freeuk.com> - 2016-11-14 18:23 +0000
          Re: Simplest compiler for C jacobnavia <jacob@jacob.remcomp.fr> - 2016-11-14 20:09 +0100
            Re: Simplest compiler for C Gareth Owen <gwowen@gmail.com> - 2016-11-14 19:11 +0000
            Re: Simplest compiler for C BartC <bc@freeuk.com> - 2016-11-14 19:42 +0000
              Re: Simplest compiler for C fir <profesor.fir@gmail.com> - 2016-11-14 12:00 -0800
                Re: Simplest compiler for C fir <profesor.fir@gmail.com> - 2016-11-14 12:17 -0800
                  Re: Simplest compiler for C fir <profesor.fir@gmail.com> - 2016-11-14 12:19 -0800
                Re: Simplest compiler for C supercat@casperkitty.com - 2016-11-14 12:40 -0800
                  Re: Simplest compiler for C fir <profesor.fir@gmail.com> - 2016-11-14 13:08 -0800
                    Re: Simplest compiler for C fir <profesor.fir@gmail.com> - 2016-11-14 13:12 -0800
              Re: Simplest compiler for C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-14 12:10 -0800
              Re: Simplest compiler for C David Brown <david.brown@hesbynett.no> - 2016-11-15 10:05 +0100
            Re: Simplest compiler for C David Brown <david.brown@hesbynett.no> - 2016-11-15 09:50 +0100
      Re: Simplest compiler for C luser droog <luser.droog@gmail.com> - 2016-11-14 09:39 -0800
      Re: Simplest compiler for C supercat@casperkitty.com - 2016-11-14 09:53 -0800
        Re: Simplest compiler for C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-14 10:31 -0800
          Re: Simplest compiler for C BartC <bc@freeuk.com> - 2016-11-14 18:57 +0000
            Re: Simplest compiler for C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-14 11:07 -0800
          Re: optimization "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-15 19:20 +0800
          Re: Simplest compiler for C BartC <bc@freeuk.com> - 2016-11-15 12:56 +0000
            Re: Simplest compiler for C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-15 05:34 -0800
              Re: Simplest compiler for C BartC <bc@freeuk.com> - 2016-11-15 16:07 +0000
                Re: Simplest compiler for C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-15 08:59 -0800
                  Re: Simplest compiler for C BartC <bc@freeuk.com> - 2016-11-15 21:35 +0000
                    Re: Simplest compiler for C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-15 15:33 -0800
                      Re: Simplest compiler for C BartC <bc@freeuk.com> - 2016-11-16 14:58 +0000
                        Re: Simplest compiler for C supercat@casperkitty.com - 2016-11-16 08:44 -0800
                          Re: Simplest compiler for C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-16 08:54 -0800
                            Re: Simplest compiler for C supercat@casperkitty.com - 2016-11-16 09:11 -0800
                              Re: Simplest compiler for C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-16 09:36 -0800
                                Re: Simplest compiler for C supercat@casperkitty.com - 2016-11-16 11:41 -0800
                                  Re: Simplest compiler for C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-16 11:45 -0800
                                    Re: Simplest compiler for C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-16 18:54 -0800
                                      Re: Simplest compiler for C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-17 04:44 -0800
                                        Re: Simplest compiler for C supercat@casperkitty.com - 2016-11-17 08:42 -0800
                                          Re: Simplest compiler for C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-17 09:17 -0800
                                            Re: Simplest compiler for C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-17 09:42 -0800
                                            Re: Simplest compiler for C supercat@casperkitty.com - 2016-11-17 09:57 -0800
                                              Re: Simplest compiler for C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-17 10:07 -0800
                                                Re: Simplest compiler for C supercat@casperkitty.com - 2016-11-17 11:35 -0800
                                                  Re: Simplest compiler for C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-17 12:02 -0800
                                                    Re: Simplest compiler for C supercat@casperkitty.com - 2016-11-17 13:23 -0800
                                                      Re: Simplest compiler for C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-17 13:55 -0800
                                                        Re: Simplest compiler for C supercat@casperkitty.com - 2016-11-17 15:15 -0800
                                                      Re: Simplest compiler for C David Brown <david.brown@hesbynett.no> - 2016-11-18 10:41 +0100
                                                        Re: Simplest compiler for C BartC <bc@freeuk.com> - 2016-11-18 12:12 +0000
                                                          Re: Simplest compiler for C David Brown <david.brown@hesbynett.no> - 2016-11-18 13:24 +0100
                                                        Re: Simplest compiler for C Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-18 09:45 -0500
                                                  Re: Simplest compiler for C BartC <bc@freeuk.com> - 2016-11-17 20:08 +0000
                                                    Re: Simplest compiler for C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-17 12:21 -0800
                                        Re: Simplest compiler for C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-18 03:22 -0800
                                          Re: Simplest compiler for C "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 19:23 +0800
                                            Re: Simplest compiler for C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-18 03:36 -0800
                                              Re: Simplest compiler for C "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-18 19:52 +0800
                                          Re: Simplest compiler for C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-19 17:55 -0800
                          Re: Simplest compiler for C BartC <bc@freeuk.com> - 2016-11-16 17:19 +0000
                            Re: Simplest compiler for C BartC <bc@freeuk.com> - 2016-11-16 19:09 +0000
                            Re: Simplest compiler for C David Brown <david.brown@hesbynett.no> - 2016-11-16 23:12 +0100
                              Re: Simplest compiler for C "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-16 14:21 -0800
                                Re: Simplest compiler for C "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-16 18:02 -0500
                                  Re: Simplest compiler for C "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-17 17:01 -0800
                                    Re: Simplest compiler for C "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-18 01:05 -0800
                                  Re: Simplest compiler for C jameskuyper@verizon.net - 2016-11-18 10:38 -0800
                                    Re: Simplest compiler for C "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-11-20 15:38 -0800
                                Re: Simplest compiler for C David Brown <david.brown@hesbynett.no> - 2016-11-17 09:57 +0100
                              Re: Simplest compiler for C BartC <bc@freeuk.com> - 2016-11-17 11:25 +0000
                        Re: Simplest compiler for C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-16 08:56 -0800
                        Re: Simplest compiler for C fir <profesor.fir@gmail.com> - 2016-11-16 09:10 -0800
                          Re: Simplest compiler for C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-16 09:34 -0800
            Re: Simplest compiler for C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-15 06:32 -0800
              [OT] Output of C compilers and CPU architectures "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-15 22:50 +0800
                Re: [OT] Output of C compilers and CPU architectures "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-15 07:46 -0800
                  Re: [OT] Output of C compilers and CPU architectures "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-16 00:12 +0800
                    Re: [OT] Output of C compilers and CPU architectures "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-15 09:02 -0800
                      Re: [OT] Output of C compilers and CPU architectures "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-16 01:14 +0800
                        Re: [OT] Output of C compilers and CPU architectures "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-15 09:24 -0800
                          Re: [OT] Output of C compilers and CPU architectures "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-16 01:27 +0800
      Re: Simplest compiler for C Anton Shepelev <anton.txt@gmail.com> - 2016-11-14 21:49 +0300
        Re: Simplest compiler for C "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-14 11:02 -0800
    Re: Simplest compiler for C Anton Shepelev <anton.txt@gmail.com> - 2016-11-14 21:37 +0300
      Re: Simplest compiler for C "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-15 18:07 +0800
      Re: Simplest compiler for C "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-15 20:15 +0800

Page 1 of 5  [1] 2 3 4 5  Next page →

#96532 — Simplest compiler for C

Is it called Tiny C Compiler? is it still alive, and well? :)

[toc] | [next] | [standalone]

#96534

In article <o0c598$feb$5@dont-email.me>,
 "Mr. Man-wai Chang" <toylet.toylet@gmail.com> wrote:

> Is it called Tiny C Compiler? is it still alive, and well? :)

<http://lmgtfy.com/?q=tiny+c+compiler>

<http://lmgtfy.com/?q=simplest+c+compiler>

[toc] | [prev] | [next] | [standalone]

#96535

On 14/11/2016 10:44 PM, Mark Storkamp wrote:
> In article <o0c598$feb$5@dont-email.me>,
>  "Mr. Man-wai Chang" <toylet.toylet@gmail.com> wrote:
>
>> Is it called Tiny C Compiler? is it still alive, and well? :)
>
> <http://lmgtfy.com/?q=tiny+c+compiler>
> <http://lmgtfy.com/?q=simplest+c+compiler>

You don't know Tiny C compiler? :)

[toc] | [prev] | [next] | [standalone]

#96539

On Monday, November 14, 2016 at 5:57:19 AM UTC-5, Mr. Man-wai Chang wrote:
> Is it called Tiny C Compiler? is it still alive, and well? :)

I've used Tiny C Compiler.  It is very fast in compilation, and runs
pretty slow in execution.  For quick-and-dirty jobs it's more than
fast enough.  It's fast enough to be used in scripting languages in
lieu of other script code.

Niklaus Wirth's "Algorithms + Data Structures = Programs" and Jan van
de Snepscheut "What Computing is All About" are also nice resources
for learning how to create compilers.  And, of course, Tiny C by Marc
Feeley.

    https://en.wikipedia.org/wiki/Algorithms_%2B_Data_Structures_%3D_Programs
    http://www.springer.com/us/book/9781461276395
    https://gist.github.com/KartikTalwar/3095780

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#96544

On 15/11/2016 12:15 AM, Rick C. Hodgin wrote:
> I've used Tiny C Compiler.  It is very fast in compilation, and runs
> pretty slow in execution.  For quick-and-dirty jobs it's more than
> fast enough.  It's fast enough to be used in scripting languages in
> lieu of other script code.

You can use it as teaching tool. I wonder whether it runs in modern Linux.

> Niklaus Wirth's "Algorithms + Data Structures = Programs" and Jan van
> de Snepscheut "What Computing is All About" are also nice resources
> for learning how to create compilers.  And, of course, Tiny C by Marc
> Feeley.

Thank you, Master. When I am bored, reading them can be entertaining 
like puzzles. :)

[toc] | [prev] | [next] | [standalone]

#96549

On 11/14/2016 11:29 AM, Mr. Man-wai Chang wrote:
> On 15/11/2016 12:15 AM, Rick C. Hodgin wrote:
>> I've used Tiny C Compiler.  It is very fast in compilation, and runs
>> pretty slow in execution.  For quick-and-dirty jobs it's more than
>> fast enough.  It's fast enough to be used in scripting languages in
>> lieu of other script code.
> 
> You can use it as teaching tool. I wonder whether it runs in modern Linux.
> 
>> Niklaus Wirth's "Algorithms + Data Structures = Programs" and Jan van
>> de Snepscheut "What Computing is All About" are also nice resources
>> for learning how to create compilers.  And, of course, Tiny C by Marc
>> Feeley.
> 
> Thank you, Master. When I am bored, reading them can be entertaining 
> like puzzles. :)
> 
Definitely a bot...

[toc] | [prev] | [next] | [standalone]

#96593

On 15/11/2016 1:43 AM, Dutch Ingraham wrote:
 >
> Definitely a bot...

Describe this "bot" in C. You have unlimited time to do it. :)

[toc] | [prev] | [next] | [standalone]

#96552

On 14/11/2016 17:29, Mr. Man-wai Chang wrote:
> On 15/11/2016 12:15 AM, Rick C. Hodgin wrote:
>> I've used Tiny C Compiler.  It is very fast in compilation, and runs
>> pretty slow in execution.  For quick-and-dirty jobs it's more than
>> fast enough.  It's fast enough to be used in scripting languages in
>> lieu of other script code.
>
> I wonder whether it runs in modern Linux.

I managed to compile 'hello world' with TCC.EXE from Windows, using 
'wine', after duplicating needed files in ./lib and ./include. However 
that produces HELLO.EXE so you need also 'wine' to run any output.

But 'wine' also seems to slow it down considerably (eg. 150ms on Windows 
=> 1000ms on Linux). Although this was virtual Linux which might be a 
factor too.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#96560

So, you are running a simulation of linux under windows. In that 
emulation you run the windows emulator, that eventually runs  your program.

No wonder!

[toc] | [prev] | [next] | [standalone]

#96561

jacobnavia <jacob@jacob.remcomp.fr> writes:

> So, you are running a simulation of linux under windows. In that
> emulation you run the windows emulator, that eventually runs  your
> program.

And all of us are inside The Matrix.

[toc] | [prev] | [next] | [standalone]

#96563

On 14/11/2016 19:09, jacobnavia wrote:
>
> So, you are running a simulation of linux under windows. In that
> emulation you run the windows emulator, that eventually runs  your program.
>
> No wonder!

AFAIK native code code ought to run at full speed, as it is not 
emulating the x86 processor. And some programs do.

But others (like some of mine!) run slower than they ought, even leaving 
wine out of it, but perhaps 30-50% slower. And one seemed to be 
sensitive to some cache issues. So something about it (Virtualbox) is 
causing problems.

At the moment however I can only generate executable code to run 
natively on Linux via gcc, which is yet another factor. (And I didn't 
forget the -O3!)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#96566

W dniu poniedziałek, 14 listopada 2016 20:42:44 UTC+1 użytkownik Bart napisał:
> On 14/11/2016 19:09, jacobnavia wrote:
> >
> > So, you are running a simulation of linux under windows. In that
> > emulation you run the windows emulator, that eventually runs  your program.
> >
> > No wonder!
> 
> AFAIK native code code ought to run at full speed, as it is not 
> emulating the x86 processor. And some programs do.
> 
> But others (like some of mine!) run slower than they ought, even leaving 
> wine out of it, but perhaps 30-50% slower. And one seemed to be 
> sensitive to some cache issues. So something about it (Virtualbox) is 
> causing problems.
> 
> At the moment however I can only generate executable code to run 
> natively on Linux via gcc, which is yet another factor. (And I didn't 
> forget the -O3!)
> 
speaking about efficiency (i may repeat it though i already said it more than once - though not many people mention that though those really optymising ones should know that):

c beats c in speed like 5-10-20 times

this is becouse tehere is c and c, if you optymise you will 
get rid of divisions unroll in elaborate things, precompute,
 tabelarize, maybe even linerize by tiling and more - 

after that your code is virtually like memset (more precise memcopy with some slight arithmetic and branching) - in short there is c and c

[toc] | [prev] | [next] | [standalone]

#96568

W dniu poniedziałek, 14 listopada 2016 21:01:03 UTC+1 użytkownik fir napisał:
> W dniu poniedziałek, 14 listopada 2016 20:42:44 UTC+1 użytkownik Bart napisał:
> > On 14/11/2016 19:09, jacobnavia wrote:
> > >
> > > So, you are running a simulation of linux under windows. In that
> > > emulation you run the windows emulator, that eventually runs  your program.
> > >
> > > No wonder!
> > 
> > AFAIK native code code ought to run at full speed, as it is not 
> > emulating the x86 processor. And some programs do.
> > 
> > But others (like some of mine!) run slower than they ought, even leaving 
> > wine out of it, but perhaps 30-50% slower. And one seemed to be 
> > sensitive to some cache issues. So something about it (Virtualbox) is 
> > causing problems.
> > 
> > At the moment however I can only generate executable code to run 
> > natively on Linux via gcc, which is yet another factor. (And I didn't 
> > forget the -O3!)
> > 
> speaking about efficiency (i may repeat it though i already said it more than once - though not many people mention that though those really optymising ones should know that):
> 
> c beats c in speed like 5-10-20 times
> 
> this is becouse tehere is c and c, if you optymise you will 
> get rid of divisions unroll in elaborate things, precompute,
>  tabelarize, maybe even linerize by tiling and more - 
> 
> after that your code is virtually like memset (more precise memcopy with some slight arithmetic and branching) - in short there is c and c

worth to mention (i also said that more than once, i usually dilike repeating myself though in this case i repeat as this is some way
nice 'cool'/'sweat' topic) that from this point you may get further
using simd intrinsics (of hand assembly) to revrite it down and
obtain possibly jet better results (but this needs assembly practice 
to do it with bigger pain, also im not sure as to possible obtainable speedups - if that would get 3x i would consider it worth it but if 
30% possibly not -- and i was usually not dong it becouse it make code 
stiff/rigid (hard to made changes) and even after c-level unroling and
precalculation it is already stiff/rigidized - but topic is cool)

[toc] | [prev] | [next] | [standalone]

#96569

> to do it with bigger pain,

to do it without bigger pain*

[toc] | [prev] | [next] | [standalone]

#96573

On Monday, November 14, 2016 at 2:01:03 PM UTC-6, fir wrote:
> c beats c in speed like 5-10-20 times

Perhaps you should have added some qualifiers to your uses of "C" above, to
distinguish what flavors you're referring to?

Some people judge the quality of a compiler based upon the performance of
quality of code it can generate for a program written in strictly-conforming
C; others judge the quality based upon the performance of code it can generate
when wielded by a programmer familiar with the strengths of the underlying
platform.

Today's compilers are much better than those of years past at turning
simply-written code into an optimized version *in cases where the code uses
patterns that they recognize*.  In some cases, the performance they can
achieve given simply-written code may be better than the performance they
can achieve when given a "hand-optimized" version.  On the other hand, the
non-optimized version may end up performing very poorly if it uses a pattern
that the compiler doesn't recognize.

[toc] | [prev] | [next] | [standalone]

#96577

W dniu poniedziałek, 14 listopada 2016 21:40:17 UTC+1 użytkownik supe...@casperkitty.com napisał:
> On Monday, November 14, 2016 at 2:01:03 PM UTC-6, fir wrote:
> > c beats c in speed like 5-10-20 times
> 
> Perhaps you should have added some qualifiers to your uses of "C" above, to
> distinguish what flavors you're referring to?
> 
perhaps not
[if i would do that then though i wanted to say by it would vanish]

[toc] | [prev] | [next] | [standalone]

#96578

> [if i would do that then though i wanted to say by it would vanish]

thought*

[toc] | [prev] | [next] | [standalone]

#96567

On Monday, November 14, 2016 at 2:42:44 PM UTC-5, Bart wrote:
> On 14/11/2016 19:09, jacobnavia wrote:
> >
> > So, you are running a simulation of linux under windows. In that
> > emulation you run the windows emulator, that eventually runs  your program.
> >
> > No wonder!
> 
> AFAIK native code code ought to run at full speed, as it is not 
> emulating the x86 processor. And some programs do.
> 
> But others (like some of mine!) run slower than they ought, even leaving 
> wine out of it, but perhaps 30-50% slower. And one seemed to be 
> sensitive to some cache issues. So something about it (Virtualbox) is 
> causing problems.
> 
> At the moment however I can only generate executable code to run 
> natively on Linux via gcc, which is yet another factor. (And I didn't 
> forget the -O3!)
> 
> -- 
> Bartc

I experience the same variability.  I have potentially traced it down
to long uptimes as I typically use them full-screen during use, scale
down to a small window and then save them where they are.

Periodically rebooting seems to resolve some of the variability.  I
run Windows Server 2003 in my VM in Linux.  I run Linux Mint and Ubuntu
in my VM in Windows.  Running Windows in Linux seems to be faster than
running Linux in Windows.  But, it's still fast enough as I grew up in
the 80486 DOS days (as I'm pretty sure you did too). :-)  Even slower
computers are more than fast enough for most things I find.

Best regards,
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#96589

On 14/11/16 20:42, BartC wrote:
> On 14/11/2016 19:09, jacobnavia wrote:
>>
>> So, you are running a simulation of linux under windows. In that
>> emulation you run the windows emulator, that eventually runs  your
>> program.
>>
>> No wonder!
> 
> AFAIK native code code ought to run at full speed, as it is not
> emulating the x86 processor. And some programs do.

Yes.

> 
> But others (like some of mine!) run slower than they ought, even leaving
> wine out of it, but perhaps 30-50% slower. And one seemed to be
> sensitive to some cache issues. So something about it (Virtualbox) is
> causing problems.

Make sure you isolate any startup delays from the timing - Wine has to
create a bit of Windows-like environment at startup.

Cache issues /can/ have an effect, though usually the speed difference
of the main x86 code between native and VirtualBox is very minor.  One
thing to note is that when an OS is running natively, it has more
information about the processors and can make more intelligent
scheduling decisions.  For example, if you have 4 cores with SMT, then
the Linux kernel knows which cores are shared between two threads, and
takes that into account when scheduling up to 8 running processes.  But
if you create a virtual machine and tell it to use up to 8 processors,
the kernel in the virtual machine only sees 8 cpus but knows nothing
about the SMT pairs, or cache sizes, etc.  It also loses (almost) all
information about processor affinity and cache contents - normally the
Linux kernel will try to re-schedule processes on the same core in order
to minimise cache misses.  It can't do that when a Windows host OS has
played with the cpus and caches behind its back.  (I have no idea how
smart the cpu scheduler is on Windows these days, I only know about the
Linux one.)


> 
> At the moment however I can only generate executable code to run
> natively on Linux via gcc, which is yet another factor. (And I didn't
> forget the -O3!)
> 

Often -O2 is faster than -O3, as -O3 does a lot more loop unrolling and
other code transformations that increase the size of code.  L1 caches,
prefetches, BTBs, etc., usually mean that the smaller code in -O2 is
faster than the expanded -O3 code.  But it can depend on details of the
code - picking the best switches for the very fastest code generation is
more of an art than a science.  Unless you are interested in reading the
documentation and doing a lot of trial and error, then stick to these:

-O2	// Basic solid optimisation
-march=native	// Tell gcc to take full advantage of /your/ cpu
-ffast-math	// Makes floating point much faster, but not IEEE


And try with something a little more demanding than "Hello, world!",
even if it is little more than a big summation loop, to isolate the
actual code performance.

[toc] | [prev] | [next] | [standalone]

#96588

On 14/11/16 20:09, jacobnavia wrote:
> 
> So, you are running a simulation of linux under windows. In that
> emulation you run the windows emulator, that eventually runs  your program.
> 

Virtualisation is not simulation.  Hardware interaction and privileged
instructions need to be virtualised, and thus run slower.  Normal code
runs at normal speed.

And Wine is not an emulator ("WINE" is an acronym  for exactly that).
It creates a windows-like environment for the code, and implements the
Windows API with translations to Linux and X APIs as needed.  For some
types of code, this translation makes programs run noticeably slower.
For other types of code, the faster implementations of libraries and
better underlying OS makes Windows code run faster under Wine.  And for
the normal code running the application - the straight x86 code - the
speed will be the same as it runs directly on the same processor.

> No wonder!

I imagine the difference is simply that programs under Wine take a
little longer to start up as Wine needs to create a small Windows-like
environment for the program before starting the exe code itself.

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web