Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
AMD Software Apache

Covalent And Redhat Developing 64 bit Apache 47

Posted by Hemos 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." "
This discussion has been archived. No new comments can be posted.

Covalent And Redhat Developing 64 bit Apache More

Covalent And Redhat Developing 64 bit Apache

Comments Filter:

  • Grassroots (Score:2, Interesting)

    by Ann Coulter ( 614889 )
    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.

    • Re:Grassroots (Score:5, Insightful)

      by pete-classic ( 75983 ) <hutnick@gmail.com> on Monday November 18, 2002 @11:35AM (#4697675) Homepage Journal
      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

    • Re:Grassroots (Score:2, Insightful)

      by Jeff Trawick ( 139236 )
      What is "companies' subvertion of Apache"? Which companies have done what to Apache httpd, in your opinion?

    • Re:Grassroots (Score:1, Insightful)

      by Anonymous Coward
      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.
      • 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.

    • Re:Grassroots (Score:1, Interesting)

      by Anonymous Coward
      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.

    • Re:Grassroots (Score:2, Informative)

      by mexilent ( 469388 )
      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.
    • 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.

  • I'm pleading ignorance here.... (Score:2, Informative)

    by Anonymous Coward


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

    How much of the code is cpu-dependant!?

    • 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'
      • 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.

      • 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.
    • 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.
    • 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.

    • "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).
    • 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.
    • 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.
  • 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?

  • Advantage to 64bits (Score:3, Interesting)

    by DrZaius ( 6588 ) <gary.richardson+slashdot@gmail.com> on Monday November 18, 2002 @12:21PM (#4698199) Homepage
    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?
    • 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.

    • Re:Advantage to 64bits (Score:3, Informative)

      by pyrotic ( 169450 )
      http://aap.sourceforge.net/patchinfo.html [sourceforge.net]

      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.
    • 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! :)
    • 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.

  • 64bit Apache Already Available? (Score:5, Informative)

    by lylonius ( 20917 ) on Monday November 18, 2002 @02:49PM (#4699992)
    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.
    • 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.
    • 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.

  • Tux? (Score:1, Redundant)

    by Russellkhan ( 570824 )
    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?
    • 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.
  • "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...
  • 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
  • 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.

  • Surely apache should be easily ported to 64 bit processors, as the code just needs compiling in a 64 bit compiler.
  • 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!

Slashdot Top Deals

Established technology tends to persist in the face of new technology. -- G. Blaauw, one of the designers of System 360

Close