gcc 64 bit

[Marsu42]

Ok, I should have been more precise: I was talking of the time it takes to compile something including running a lenghty ./configure, not about the performance of the compiled programs themselves. And compiling seems to be hindered by the performance of fork, for me [while (true); do /bin/date --utc; done |uniq -c] gives ~350 forks/sec on VirtualBox w/ Debian64, ~60 forks/sec on SUA and ~20 forks/sec on Cygwin (doh).

Please not a UNIX wiz and that I'm not trying to start a flame war on SUA in a SUA forum, but I think it's important to make clear that you cannot use SUA as a drop-in replacement for a real VM, speed- or compatibility-wise.

Personally, I'm just running a couple of tools with SUA (like my favourite editor joe). I am also trying to quickly (re-)compile OpenWrt w/o running a VM, and I'm nearly there, should be possible because it's mostly cross-compiling.

[jerker_back]

Marsu42

* to be fair: VirtualBox is at least 2 times as fast as SUA on my box...

Hm ... I'm not sure what you mean here. SUA is one of the fastest things you can run on Windows, with a very small memory requirement and just a few steps away from the kernel. It's also isolated from other running processes - it's a another subsystem. Hard to beat performance wise.


One of the great thing about VirtualBox is that it's open source and seem to be fast to integrate new features. However, without have looking to any tests, VMWare seems/feels faster and more stable. I can have a 64-bit NetBSD and a 64-bit FreeBSD VMWare virtual machines running while working in 2-3 Visual Studio instances without noticing any lags. I was forced to install VirtualBox to get Windows 8 to install. This virtual machine is a real pain to run though.

Just FYI, MS Hyper-V is not usable on a Windows 2008 R2 workstation.

edit:

Marsu42

gives ~350 forks/sec on VirtualBox w/ Debian64, ~60 forks/sec on SUA and ~20 forks/sec on Cygwin (doh).

Now, that was interesting ...

[Marsu42]

"But an experimental gcc4.4 compiler produces code running as fast as any commercial compiler"


... could you please point me in the right direction, is there a working source code setup or even a precompiled archive available? I couldn't find anything searching the forum but development work in progress. Thanks!


The latest compiler I found was gcc 4.2 from Debian Interix, but its target is i486-pc-interix3 instead of i586-pc-interix3 and I'm wondering about compatibility.

[tnat]

Rodney

In the "Department of Positive Thinking" I came across some positive information. The first item of positiveness is that web
traffic to SUA Community had increased a large amount from 2010 (which had slightly increased from 2009). The second
is that ftp downloads are up significantly as well (raw bytes, # of bundles, # of individual packages). I just started to look
at this data yesterday and there's a lot to go through to determine certain data is a not a "monthly blip".

Well, SUA was mentioned last week in Slashdot. That might explain some of the traffic:


http://tech.slashdot.org/story/11/09/22/...-windows-8

[rodney]

> Well, SUA was mentioned last week in Slashdot. That might explain some of the traffic:

Thanks for that link.
But I haven't bothered looking at September because it's only a partial month at this point in time.
I'm now looking at traffic for the previous 12 months (and 24 months somewhat).
I started to do IP analysis and could divide the increase into two groups: individuals and businesses.
The individuals tend to be clustered geographically. Some some businesses might be in this group
because they're connecting through using an ISP's set of addresses.
The businesses look to be large and geographically distributed for the most part. These connections
seemed to be over several months (not blips).

[oeffner]

Marsu42


"But an experimental gcc4.4 compiler produces code running as fast as any commercial compiler"


... could you please point me in the right direction, is there a working source code setup or even a precompiled archive available? I couldn't find anything searching the forum but development work in progress. Thanks!


The latest compiler I found was gcc 4.2 from Debian Interix, but its target is i486-pc-interix3 instead of i586-pc-interix3 and I'm wondering about compatibility.

It's code I played around with 2 years ago. See http://www.suacommunity.com/forum/tm.asp...ge=3#17384

There were issues with OpenMP parallelisation of string operations and I eventually gave up upon it. But doing pure numbercrunching in tests proved that executables produced was as fast as code compiled with Microsofts VC2005.

I would think that the efforts put into current gcc 64 bit ffor interix have superseeded that experimental build. Maybe it's straightforward bootstrapping the g modules on this gcc compiler as to get g 64 bit.

[rodney]

To keep information in the same thread (for search and sanity).

Currently gcc 64-bit has the macro "_WIN64" defined internally. It shouldn't be defined.

You can see all of the internally defined gcc macros with the commands:
touch foo.h ; cpp -dM foo.h
You can, of course, pipe that into grep if you're looking for something in particular.

Anyway, it shouldn't be defined because there is source code #ifdef'd on _WIN64
that assumes things that MSVC has internally but gcc doesn't (for example, "__int64").

As a workaround for now you can add "-U_WIN64" to your gcc options.

[jerker_back]

I get while trying to build apache httpd apr

[rodney]

I built apr as a separate package using gcc64 (not as part of httpd).
What I did was I chose the configure options "--disable-shared --disable-dso".
Everything built just fine after that.
The separate httpd is supposed to have its apr from apr.
To leverage the apr package you need to add the path "/usr/local/apr/lib/pkgconfig" to
the environment variable PKG_CONFIG_PATH (or check it is there).

If you edit the Makefile and wack the "--silent" then you'll get to see what's actually passed to gcc and/or ld. Occasionally removing "-std=gnu99" will fix things.

Anyway, when that "safecrti.o" appears it's usually trying a shared lib build.

[jerker_back]

--disable-shared

Yes, this should fix it (not listed in httpd configure options) - thanks. I've been on apr several times before and it should be straight forward, but it always seem to be some problems. But if one think about it, it is a compatibility library with several more or less system-like functions.