Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Posted Apr 22, 2005 5:14 UTC (Fri) by yem (guest, #1138)
Posted Apr 22, 2005 6:43 UTC (Fri) by nix (subscriber, #2304)
(You can't upload anything to ftp.gnu.org and mirrors anymore without that.)
Posted Apr 22, 2005 8:12 UTC (Fri) by yem (guest, #1138)
Ah so they do. Sorry. ftp.gnu.org was down and the mirror I checked isn't carrying the signatures.
All is well :-)
gcc 4.0 available
Posted Apr 22, 2005 5:21 UTC (Fri) by xoddam (subscriber, #2322)
gcc-2.95.3 was a good vintage...
Posted Apr 22, 2005 6:27 UTC (Fri) by dank (guest, #1865)
Posted Apr 22, 2005 6:45 UTC (Fri) by nix (subscriber, #2304)
Posted Apr 22, 2005 11:29 UTC (Fri) by steven97 (guest, #2702)
Posted Apr 22, 2005 12:39 UTC (Fri) by nix (subscriber, #2304)
1) rtl optimizers will be disabled. It appears this won't happen any
If the damned things weren't so intertwined they'd be easier to ditch: and indeed it's their intertwined and hard-to-maintain nature that makes it all the more important to try to ditch them (or at least simplify them to an absolute minimum).
Obviously some optimizations (peepholes and such) actually benefit from being performed at such a low level, but does anyone really think that loop analysis, for instance, should be performed on RTL? It is, but its benefits at that level are... limited compared to its time cost.
2) rtl optimizers do less, so they consume less time. I wish that were
true. There is usually no relation between the number of transformations
and the running time of a pass. Most of the time is in visiting
instructions and doing the data flow analysis. That takes time even if
there isn't a single opportunity for a pass to do something useful.
Posted Apr 22, 2005 18:02 UTC (Fri) by steven97 (guest, #2702)
Posted Apr 22, 2005 21:02 UTC (Fri) by nix (subscriber, #2304)
I didn't mean the RTL optimizers had become intrinsically faster (except inasmuch as code's been ripped out of them).
Posted Apr 22, 2005 16:03 UTC (Fri) by Ross (subscriber, #4065)
Posted Apr 22, 2005 17:06 UTC (Fri) by mmarq (guest, #2332)
And that is what should matter the most; *The end user*. Because if people complain about the speed of the compilation process they should change to a better computer, perhaps a NForce 4/5 based for Atlhon64 or Pentium4 or the latest VIA chipsets with support for SLI and those Dual Core CPUs coming out soon!...
... he, right!, support for those beasts aren't good enough for Linux right now! But that isn't much different from what was in, say 2001!...
I've no intention to add to any flamewar, but my point is as exposed above that the community trend to discuss heavly on less important issues. The Linux commercial party are battling for scratchs whyle the majority of end users not only dont know, but they dont whant to know, because Linux like Unix is viewed as something for geeks or bearded gurus,..., and worst of all standars go at the speed of a snail, because the philosophy is add features and avoid standards.
There are hundreds of distros but i havent seen one that adds a report of tested hardware configurations(if anyone know one please link it), or care about those, or care about being *religious* about standards, because that is the only way to expose the masses of low tech end users to the same 'methods' and 'ways', for a much larger period of time, adding the change for distros to get very good at the 'interface for low tech users',and in consequence gain a larger adoption percentage.
Open Source community is closing itself inside it's own technical space! And when, if, that happens completly, then it's another Unix story almost like a carbon copy.
Posted Apr 22, 2005 21:16 UTC (Fri) by sdalley (subscriber, #18550)
Posted Apr 24, 2005 17:09 UTC (Sun) by mmarq (guest, #2332)
I've done a search on that site, on 'Certified Hardware' for hardware/software, for the companys ASUSTEK, ECS, EPOX, DFI, GIGABYTE and INTEL with the the keywords "motherbord", and without any keyword which means every piece of hardware.
Since those are manufactores that also do Graphic Boards besides Mobos, they would represent perhaps more than 70% of a common desktop system, and representing perhaps more than 70% of the market, very ahead of the integrators HP/Compaq, IBM, gateway and DELL all put togheter. And Since some of those manufactors also do server 'iron', Mobos or systems, i belive that is represented, perhaps not far from 90% of *all* (server+desktop) deployed base.
The only result i've got was for ASUSTEK showing old Network Servers, and INTEL showing LAN driver(net adpaters), RAID adapters and Network Servers, some aging a lot??!!!
Understanding what line of business Novell is in, still i consider this very far from reasonable... not reasonable even to them if they want to survive in a medium to long term!.
Posted May 8, 2005 5:43 UTC (Sun) by barrygould (guest, #4774)
FWIW, Dell supposedly often uses ASUS motherboards.
FWIW, I've never had a problem with linux on any motherboard unless it was based on a brand-new chipset for which drivers were just becoming available.
If you're really worried, find out what kernel version is used by a distribution, and see if the kernel.org kernel of that version supports your chipset, etc.
Posted Apr 22, 2005 21:36 UTC (Fri) by nix (subscriber, #2304)
(Oh, also, GCC is very much more than `the Linux compiler'. All the free BSDs use it, many commercial Unix shops use it, Cygwin uses it, Apple relies on it for MacOSX, and it's very widely used in the embedded and (I believe) avionics worlds. Even if, with the wave of a magic wand, the Hurd was perfected and Linux dissolved into mist tomorrow, GCC would still be here.)
Posted Apr 22, 2005 21:22 UTC (Fri) by nix (subscriber, #2304)
Alas, major performance gains on register-poor arches like IA32 may be hard to realize without rewriting the register allocator --- and the part of GCC that does register allocation (badly) also does so much else, and is so old and crufty, that rewriting it is a heroic task that has so far defeated all comers...
Posted Apr 25, 2005 6:38 UTC (Mon) by HalfMoon (guest, #3211)
Alas, major performance gains on register-poor arches like
IA32 may be hard to realize without rewriting the register allocator ...
Then there's Opteron, or at least AMD64 ... odd how by the
time GCC starts to get serious support for x86, the hardware finally
started to grow up (no thanks to Intel of course).
Posted Apr 24, 2005 20:35 UTC (Sun) by dank (guest, #1865)
I'd love to switch to the new compiler, because
I value its improved standards compliance,
but it's hard for me to argue for a switch
when it *slows down* important applications.
I don't need *better* code before I switch,
but I do need to verify there are no performance
regressions. And sadly, there are still some of
those in apps compiled with gcc-3.4.1 compared to gcc-2.95.3.
As I said in my original post, I don't expect later versions to
definitively beat 2.95.3 until gcc-4.1.
The whole point of gcc-4.0 is to shake out the bugs
in the new tree optimization stuff.
I am starting to build and test all my apps with gcc-4.0 and
plan to help resolve any problems I find, because I want
to be ready for gcc-4.1.
Posted Apr 25, 2005 16:05 UTC (Mon) by nix (subscriber, #2304)
Strings are now unavoidably constants
Posted Apr 22, 2005 11:35 UTC (Fri) by gdt (subscriber, #6284)
The removal of the -fwritable-strings option will flush out any code yet to be moved to ANSI C. It will be interesting to see how much there is.
Our user group had an experience this week of a program SEGVing from writing to a string constant. The beginner programmer had typed in example code from a C textbook which was popular five years ago, and was obviously confused and concerned that it didn't work. So not all pre-ANSI code will be old.
Posted Apr 22, 2005 21:39 UTC (Fri) by nix (subscriber, #2304)
The removal of the -fwritable-strings option will flush out any code yet to be moved to ANSI C.
Posted Apr 22, 2005 22:38 UTC (Fri) by gdt (subscriber, #6284)
Sorry, I expressed myself poorly. There's a lot of code out there that is K&R with ANSI function definitions. I'm interested to see how many of these break from this semantic change.
I've no idea if it is a little or a lot. It will be interesting to see.
Posted Apr 23, 2005 21:30 UTC (Sat) by nix (subscriber, #2304)
Copyright © 2005, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds