Slashdot Mirror

← Back to Stories (view on slashdot.org)

Covalent And Redhat Developing 64 bit Apache

Posted by Hemos on from the building-it-better-and-faster dept.

ruiner5000 writes "Well it is official. AMD has just sent out a press release announcing that Covalent and Redhat are developing a 64 bit version of Apache. "Covalent is developing 64-bit compatibility because we believe the upcoming AMD Opteron processor-based server systems will deliver superior performance and reliability for our easy-to-install Apache project server software," said Mark Douglas, senior vice president of engineering, Covalent Technologies. "Compatibility is essential, and we are cooperatively working to ensure optimal performance with the upcoming AMD Opteron processors." "

47 comments

  1. Grassroots by Ann+Coulter · · Score: 2, Interesting

    I really don't trust corporations taking charge of a major Open Source project in any manner. Even if they stick to the GPL all the way I will still have doubts. First of all, AMD is another official supporter of DRM technology. I really don't trust the motives of companies' subvertion of Apache. If they continue to modify Open Source projects for the first real DRM equipt AMD, what prevents a major media corporation from funding an initiative to add DRM software to Apache and sell it to unsuspecting business customers? Why are they spending their time and resources to do something that Apache developers probably will get to in the near future? We should be more cynical with regards to corporate support of Open Source projects. In my opinion, critical Open Source projects should be managed and developed by an unbiased group of developers.

    1. Re:Grassroots by pete-classic · · Score: 5, Insightful

      The worst thing that could happen under the GPL (which you brought into the discussion) is that we have to separate the wheat of their contributions from the chaff and fork.

      The same isn't true with the Apache license, but the trump card with people playing games with Free Software is to fork.

      Open Source projects should be managed and developed by an unbiased group of developers.

      Do you mean unbiased, or biased the same way you are? While your biases (and mine) may be diametrically opposed to Covalent's, that doesn't make you (us) unbiased.

      -Peter

    2. Re:Grassroots by Anonymous Coward · · Score: 0
      Has there been any papers written on how one would take over a GPL product? (so that we can watch out for it).

      I guess the first thing you would do would be to make the project dependant on your employees.

      The second thing to do would be to make low-level changes that in themselves don't reveal what you plan to do in the future that users might not like. Make the system inflexible to alternative choices in the future. Make it hard to change it.

      The third would be good PR so that there's no perceived need for a fork. Quieten and insult those who oppose you.

      Anything else?

    3. Re:Grassroots by Jeff+Trawick · · Score: 2, Insightful

      What is "companies' subvertion of Apache"? Which companies have done what to Apache httpd, in your opinion?

    4. Re:Grassroots by Anonymous Coward · · Score: 1, Insightful

      Can I ask you what processor you use? If its an Intel or AMD, then you are supporting DRM by purchasing their processors. That goes for anything you purchase made by one or both of those two companies. Also, do you own a stand-alone DVD player?

      IBM started and still contributes to Jakarta as well as EVMS (which might go into the Linux kernel). Transmeta is hoping on the MS bandwagon as even partially owned by a MS employee and Linus Torvalds works there. Ted Tso works for IBM and he heavily contributes to ext2 and ext3. The German government is funding a KDE groupware project.

      Why is AMD helping a port to their new process for Apache? Well hmm, lets see. If they can show this port will run X percent faster than an if Apache was run on an Intel processor, and with Apache being the most used web server, they can increase their sales. So they spend a few thousand dollars, chump change for them for a potentially much much higher return.

      Maybe OS projects should be managed and developed by an unbiased group of developers, but who's going to fund them. If they have to get other jobs so they can put food on the table, it will take much longer to create these projects. So if you would prefer that, then start donating. Otherwise, shut up and wake up to reality.

    5. Re:Grassroots by Anonymous Coward · · Score: 1, Interesting

      Well, those companies which contribute to the project can't make it become 'closed source' from open, so even if they do develop DRM technologies, then someone will just release a version with all the good parts and without the unwanted DRM chaff, then that version would become dominant. So I really don't think letting companies contribute to open source projects is a problem - their changes would still have to be accepted before they were widely propogated.

    6. Re:Grassroots by mexilent · · Score: 2, Informative

      Covalent happens to employ about half of the apache developers--and it has for many years. At least these folks have a small, scrappy upstart company to work for...instead of /\/\icro$oft. How do you think apache would turn out if _that_ company started to commandeer open source projects?

      Even open source developers gotta eat, brother--and Covalent's as gooda place as any to pay the bills.

      --
      -- Know Nukes!
    7. Re:Grassroots by coene · · Score: 3

      1. DRM has nothing todo with open-source

      2. We should be more cynical with regards to corporate support of Open Source projects.

      Huh? RedHat and Covalent employee hundreds of open-source programmers. We? We? Are you going to commit the code? This is a way for programmers to further open-source projects and still bring home the bacon at the same time.

      3. In my opinion, critical Open Source projects should be managed and developed by an unbiased group of developers.

      80% of the software on a Linux machine has components developed by corporations. If a program is very popular, someone is paying for the development by now. Linux Kernel, GCC, Samba, Apache, Sendmail, you name it.

    8. Re:Grassroots by cant_get_a_good_nick · · Score: 2

      IBM started and still contributes to Jakarta

      Solaris contributed a huge amount to Jakarta as well, and in fact Jakarta is now the reference JSP container. They still contribute code.

  2. I'm pleading ignorance here.... by Anonymous Coward · · Score: 2, Informative



    Can't they just MAKE apache on a 64 bit computer?

    How much of the code is cpu-dependant!?

    1. Re:I'm pleading ignorance here.... by Lenolium · · Score: 2, Informative

      I've built apache on my multia, and on my PC164SX, both of which are 64-bit alpha machines, and it works just fine. So... I'm kindof confused about this article too. It sounds like AMD just payed about 200k or so for someone to type 'make'

    2. Re:I'm pleading ignorance here.... by masonator · · Score: 2
      I would have to agree, Apache's been around for quite a while and has been ported to most platform's around at the moment - so it probably should "just work".

      My guess is that this is just all a publicity stunt.

    3. Re:I'm pleading ignorance here.... by hawkbug · · Score: 1

      What I think they are doing is better than just allowing the 32 bit code to be compiled on a 64 bit machine. I bet they are tuning it so the 64 bit version can take full advantage of the new hardware. If they weren't doing that, or adding features, there would be no point just like you have stated. Also, think about this for a second - if somebody hadn't already added code to apache so that it would compile on any architecture you try, it wouldn't work. A fine example of this is the linux kernel - I got linux running on my Mac in 1997 for the first time. Ofcourse I couldn't just take the stock linux source code at that time and type "make". Somebody first had to port it, and then that code got added to the linux source tree. So, it's very possible that apache doesn't just "make" on the K8 yet.

    4. Re:I'm pleading ignorance here.... by Cygnusx12 · · Score: 2, Interesting

      I actually asked the same question recentlt at work!

      Having just come off a project in which we ported all of our db code from 32 bit to 64bit, (Solairs CC 6.0u2) the conversion was actually a bit tricky, and there were a few nuances we had to deal with in order to get completely functional models. (Bit-packing, etc, INTs are 4 wide rather than 2, etc.).

      Several overloaded classes also need to be created to allow portability between the 32bit and 64bit versions, and several of our tools needed upgrading as well.

      There are most likely several hooks that need to be "re-Type(defed)" in order to function i>properly under the OS, would be my ever so humble opinion.

    5. Re:I'm pleading ignorance here.... by Anonymous Coward · · Score: 0

      maybe they are creating a MPM that will take advantage
      of the 64 bit arch..

      Like WinNT MPM that uses native WinNT calls.

    6. Re:I'm pleading ignorance here.... by Russellkhan · · Score: 2

      "Can't they just MAKE apache on a 64 bit computer?

      How much of the code is cpu-dependant!?      "

      OK, IANADeveloper - in fact, I'm not even the novice programmer I once was so this may be way off-base, but it seems to me that that would require someone having previously written the Makefiles and/or configure files so that Make would know what it needs to do in order to compile and run on that platform. I would think that that's what's being done here.

      If I'm wrong, I welcome corrections - this is something I would like to understand better (Plus the fact that I aspire to be a programmer again at some point).

      --
      Information doesn't want to be anthropomorphized anymore.
    7. Re:I'm pleading ignorance here.... by cant_get_a_good_nick · · Score: 2

      Depends on how clean the code is. If you assume data sizes (something you shouldn't do anyway, but some do) you should be OK. Do you try to pass data in places that ask for pointers? You'll be in some trouble then.

      Hmm, are peoples' memories so bad that they forget that there used to be DEC Alpha binaries pretty regularly... the Alpha being a 64 bit Little-Endian chip. I'm sure the code is pretty much 64 bit clean, it may be more of an optimization for the x86-64 processor than making it 64 bit clean.

    8. Re:I'm pleading ignorance here.... by tmuller · · Score: 1

      Is it me, or does NO ONE here understand compilers? You can do exactly that, make. The biggest problem is that everything will be made "32" bit unless there is "64" bit code to handle all the nuances with the 64 bit platform (integers are wider, etc). Even if you say "Use 64 bits when I compile", if there is no handlers, the code might be compiled 64 bit, but the executable will work with 32 bit only. This means that you will effectively be moving 32 extra bits around that aren't even being used.

    9. Re:I'm pleading ignorance here.... by m1a1 · · Score: 1

      My guess is that a lot of this involves:

      a) cleaning up any assembler in the apache code if there is any (I have never looked at. They would do this to take advantage of new/improved x86-64 instructions.

      b) Examining how 64-bit compilers handle the apache code. Some things may need to be changed to work more smoothly under the 64 bit architecture and harness all that really really long number goodness.

  3. Will this benefit other upcoming 64bit chips? by dbrutus · · Score: 2

    By the time this comes out the 970 will either be released or about to be released. Will this work also benefit Apache on PPC?

  4. Advantage to 64bits by DrZaius · · Score: 3, Interesting

    What is the advantage to running a 64bit web server? From what I've heard and read, pointers are still pointers and registers are still registers. I don't really see any area where a normal webserver would benefit.

    In the webservers I run, most of the data that gets delivered is pretty small and most of the mathematically calculations can be done well within 32bits.

    Am I an ignorant fool?

    --
    -- DrZaius - Minister of Sciences and Protector of the Faith
    1. Re:Advantage to 64bits by Anonymous Coward · · Score: 0

      You need to learn assembly language programming to answer your question. The most commonly used instruction in the x86 instruction set is mov. This instruction is the basis for strcpy, memcpy, etc. in C. On a 64-bit processor you can move twice as much memory as on a 32-bit processor in the same amount of time. This is just the performance advantage of one of the many instructions.

    2. Re:Advantage to 64bits by Jeff+Trawick · · Score: 3, Insightful

      Lots of active connections handled by the same process can result in lots of mmaps. If these
      are large you can start getting worried about
      running out of address space with a 32-bit process.

      Also, perhaps sendfile works with large file support on Linux in 64-bit mode :) that would be a nice improvement

      For most situations a 64-bit Apache process isn't going to solve any problems right now. I imagine
      it will just use more memory.

    3. Re:Advantage to 64bits by Anonymous Coward · · Score: 0

      If you want to just "talk" pointers and registers in your terms, then there should be no problem running it on a 16bit machine right?

      A 64bit machine can most likely move around data faster so there you go right there.

    4. Re:Advantage to 64bits by pyrotic · · Score: 3, Informative

      http://aap.sourceforge.net/patchinfo.html

      SGI had people working on 64 bit support back in the days of Apache 1.36. Their big thing with 64 bit support was to cache huge amounts of static data with a new cacheing module, using the 64 bit address space. AFAIK there is curenlty no maintainer to this code and ASF didn't merge it into the main tree.

    5. Re:Advantage to 64bits by Anonymous Coward · · Score: 0

      Umm no because the "register" holding the "pointer" is "16" "-" "bits" " " "and" "apache" """ "is""""more"than"" " """ " "" 64K "" """ "

    6. Re:Advantage to 64bits by thogard · · Score: 1

      But moving 64 bits of data when your only going to use 16 isn't a help and that tends to be a large chunck of instructions most compilers generate. Look at the power pc, it takes 5 instructions to load a 64 bit value. It takes one for a 16 bit value. With sparcs, most programs run faster when running in 32 bit mode than 64. There isn't a single 64 bit program running on the 64 bit Nintendo 64 because the 32 bit ops are faster. A 32 bit cpu with a 64 bit memory managment (like early sparcs) give the same advantage you talk about without the mess of moving around an extra 32 bits for ever context change. Going to 64 bits doen't get you the increase that the 16->32 bit change did unless your running lots of calculations with very large numbers.

    7. Re:Advantage to 64bits by nule.org · · Score: 1

      I am an ignorant fool, but from my understanding of X86-64 there are advantages over typical 32 bit x86 code. Most of these have to do with a rather arcane assembly interface that every x86 implementation has to respect. The new x86-64 specific instructions allow for some wonderful optimizations that otherwise would never be allowed in the 32 bit space - things that would have been nice to have in x86 assembly but the limited number of registers wouldn't permit. I'm pretty sure Ars Technica had a good article about this recently, but I can't seem to find it.

      I doubt this will do incredible things for Apache or most other services we depend on, but I still can't wait to get a sledgehammer in my boxen! :)

    8. Re:Advantage to 64bits by Sludge · · Score: 2

      I'm not sure I can answer your question Gary (hi, btw), but I can tell you that sizeof(void *) is now double the size. You will now use up more memory bandwidth passing pointers around. This will actually cause a bit of a performance decrease in well written code that relies on efficientcy by not to putting data structures on the stack by passing by reference/pointer.

    9. Re:Advantage to 64bits by Anonymous Coward · · Score: 0

      Umm yes because it doesn't matter whether 16bit registers because you can address more that 16bit with 2x16bit registers

    10. Re:Advantage to 64bits by podperson · · Score: 1

      The obvious benefit of a 64-bit processor for server applications is spewing out data. When you're spitting out a web page or whatever, you don't really care what you're looking at and 64-bits is 2x 32-bits. Look at the power pc, it takes 5 instructions to load a 64 bit value This sounds wrong to me, especially if you use floating point registers. I'm too sleepy to look it up but I'm guessing 3 integer instructions at most. (1 on a 64-bit PowerPC, of course.) Which leads me to the question: if you have a 32-bit processor with 64-bit addressing, a floating point pipeline with 64-bit or 80-bit memory access for calculations, exactly what benefit is a 64-bit processor?

  5. 64bit Apache Already Available? by lylonius · · Score: 5, Informative

    If you set and export your shell environment variable CFLAGS="-m64", you already have native 64-bit support for Apache. The Sun SPARC architecture has been 64-bit for a long time now.

    The "real" problem is getting all of your supporting modules to compile with 64-bit support as well. I've successfully compiled mod_php with the -m64 flag, but since our shop utilizes the Sleepycat Berkeley db3 library (which doesn't support the flag), we cannot build db3 support into mod_php.

    1. Re:64bit Apache Already Available? by Jeff+Trawick · · Score: 2, Informative

      Yes, I've run Apache 2 as a 64-bit process on AIX and Tru64 as well. And Apache 2 has run as 64-bit process on HP-UX for ia64 for some time.

      There have been a few assume-32-bit bugs found here and there and there probably are a few more still out there, but in general people should expect Apache 2 to already work in 64-bit mode with the caveat that it hasn't been tested as much as in 32-bit mode.

    2. Re:64bit Apache Already Available? by tmuller · · Score: 1

      So what. Your most likely just moving the extra 32 bits around anyways and not using them.

      Now if your flag actually ACTIVATES code in apache to get around 32 bit code, then I'd say "Great", but a simple compiler flag generally doesn't do that.

  6. I could easily doudle AMD's return by Anonymous Coward · · Score: 0

    It sounds like AMD just payed about 200k or so for someone to type 'make'

    I'll type "make" twice.

    I't would be a real bargain for them!

  7. Apache isn't GPL by Anonymous Coward · · Score: 0

    It's under the apache license, BSD-style. Therefore companies can do whatever they want with it.

    Before you panic, look at where it is today.

  8. Tux? by Russellkhan · · Score: 1, Redundant

    I thought that RedHat was pushing their Tux webserver these days? Last I knew they were making all kinds of crazy claims about it being better, stronger and faster than Apache. Why would they support Apache then?

    Is it just to get hold of some of AMD's cash?

    --
    Information doesn't want to be anthropomorphized anymore.
    1. Re:Tux? by cant_get_a_good_nick · · Score: 2

      For certain things, TUX is better. Apache has always been designed for correctness, security, and portability (they have code for mainframes using EBCDIC, Netware, BeOS...). Speed isn't one of their top priorities. At a dotcom I worked, we considered thttpd for static pages because of its speed, and apache for anything dynamic. We never got to the point where we had any real load (dot-com implosion) so we never got to the point where the speed diff waranted having the complications of two daemons. Apache has it's place, it's not for every situation.

      TUX is much faster on most things, such as static pages. It's an in-kernel server, and takes advantage of things such as direct access to kernel buffers and DMA, something a user-land daemon such as apache can never do. But it's not as configurable, especially in dynamic content situations (can't do JSP or mod_perl, or php for example). That's fine, the default config has TUX forwarding stuff it can't understand to a userland daemon anyway. The recommended server? Apache. They're really complimentary, even in RedHats config.

      In some respects, this makes a lot of sense for RedHat. They don't sell TUX. Hell both TUX and Apache are free/open source. They sell their OS (their version of it anyway) and support. To get OS sales, you need to have apps on your OS that people want, like Apache. As far as the support goes, more people using your OS, more support opportunities. Having a 64bit server can help, sicne the Opteron is more tuned for business sales, where they're more likely to buy support anyway. They also have the inside track a bit, since they did the porting and may gain some advantage by it.

  9. Linux-based by cant_get_a_good_nick · · Score: 2

    "Apache is a very widely used *Linux*-based enterprise Web server application, and we are working with two leaders - Covalent and Red Hat - to offer simultaneous high-performance 32- and 64- bit computing to our customers,"

    Hmm, I thought that Apache was pretty much run it everywhere, not just Linux. I guess this guy better tell Yahoo to stop running it on FreeBSD...

  10. This is great by ball-lightning · · Score: 1

    This is good, even if the performance benefits aren't that great, at least AMD is getting some support here, which is what it needs most right now

  11. OSX 970 Apache? by WatertonMan · · Score: 2
    Given the nature of open source expect a variation of this to appear on OSX once the 970 versions of OSX arrive.

    However as everyone else is saying, the actual situations where one would need 64-bit apps are rather limited. It might even result in a slight slowdown due to having to move a twice the data around with pointers and other such things.

  12. Already Portable by xgoat · · Score: 1

    Surely apache should be easily ported to 64 bit processors, as the code just needs compiling in a 64 bit compiler.

  13. this is good news by GoatPigSheep · · Score: 1

    64-bit support for apache will be needed seeing as microsoft has 64-bit versions of IIS available already.

    I'd hate to see apache lose market share due to a lack of 64-bit support, good move redhat!

    --
    GoatPigSheep, the 3 most important food groups