FreeBSD on the Athlon64 in 64bit vs Pentium4 3.2E

veliath writes "Came by a comparison from about three weeks ago, between two systems running FreeBSD. One is an Athlon64 running FreeBSD in 64bit mode and the other a Pentium4 3.2E running FreeBSD in 32bit mode."

Comments

Old news...

[hmallett]

This is the same article as was linked to from the FreeBSD site a few weeks ago. Everyone's probably read this already. Basically, the Athlon64 is faster.

Re:Old news...

[wed128]

Thanks for giving it away, you insensitive clod...i was really gonna enjoy this, too...

Re:Old news...

[hmallett]

I cna understand wanting a spoiler alert on a post revealing the end of a film, but you must be a true geek to want a spoiler alert on a benchmark!

HT & threads

[davegaramond]

The article says that Intel's HT doesn't improve performance much. Isn't this expected, considering that IIRC FreeBSD's kernel threads still suck and most of the programs are single threaded anyway?

Re:HT & threads

[Anonymous Coward]

While I don't know about FreeBSD's threads sucking as far as I could tell none of the tests would've stressed the threading system.

The tests didn't really work to hyper-threading's advantages. Take the builds with multiple jobs running at the same time. That's more about running separate applications as separate processes and that's not what hyper-threading's advantage is because they arn't separate thread at all.

HT is more for true multithreaded applications like Photoshop or something and none of the benchmarks were anything like that.

Re:HT & threads

[aminorex]

HT does wonders for the P4 in the bandwidth tests, because they are not taxing the execution core; they are only stressing the limits of those parts of the CPU which are replicated. In fact, I can go a step further and say that they aren't even taxing those parts in any meaningful way, because the P4 just plain has fat pipes. Forthcoming dual-channel revisions of the Athlon64 will do another leap-frog, and put that architecture's bandwidth in the lead for a while, but it hasn't happened yet.

The real-world apps demonstrate that the 5% of die space spent on HT doesn't result in much more leveraging of the execution core, in practice. I can't imagine why anyone would care what the P4 numbers were without HT, since no one will ever run it that way now that OSen are supporting it.

As regards FreeBSD's kernel threads, the answer is "not really" since the overwhelming bulk of the benchmarks was spent in userspace (less so for the compile benchmarks than for the crypto ones). Notice that the user time numbers favored the Athlon64 no less than did the wall time numbers.

I think it's interesting that the synthetic benchmarks all favored the P4 (a highly academic design) while the user load tests all favored the 64.

Re:HT & threads

[ratboy666]

What HyperThreading is...

Out of order execution takes the processor to a particular level of performance. Unfortunately, (and especially with the X86 IA), we run out of steam rather quickly, and the processor blocks waiting on registers or memory. The idea behind HT is that the processor's execution elements can then be reassigned to something else waiting in cache.

Of course, this means we need a big fat cache, and something else to execute. Could be another thread or process, but the important thing is that the second job be independent.

This can increase the utilization of the processor's compute elements.

So, yes, the "builds with multiple jobs running at the same time" test makes sense.

I would like to see a benchmark with CPU stalls and utilization summarized at the end. Can't do it myself, because I am far too cheap to replace my current system (and yes, it is an MP box - dual 200Mhz PPRO - and it still does quite nicely).

Anyway, it does look the the Intel took a hit in this benchmark; too bad for them. I looked over the methodology -- and it looked reasonable given the scope of the project.

Ratboy.

Re:HT & threads

[ValourX]

I would like to see a benchmark with CPU stalls and utilization summarized at the end. Can't do it myself, because I am far too cheap to replace my current system (and yes, it is an MP box - dual 200Mhz PPRO - and it still does quite nicely).

If it were possible, I would have done this and measure temperatures as well... but I couldn't find a way to measure these things without interfering with the tests. It was really important to me to prevent anything from altering the test results. Of course if you have a suggestion on how I can monitor CPU stats consistently without messing with the testing, definitely turn me on to it.

-Jem

Re:HT & threads

[Anonymous Coward]

now that OSen are supporting it

Jesus fucking christ...

Re:HT & threads

[jo42]

FWIW, my personal simplistic non-HT vs. HT test on Windows XP showed that HT does make a difference. While, er, backing up a DVD to an XviD AVI file using AutoGK, second encode pass, non-HT took 142 minutes on my 3GHz P4 with dual channel DDR400 memory. After turning HT on, it took only 122 minutes...

Re:HT & threads

[Anonymous Coward]

Wow, I'm a nobody then. I don't turn HT on my p4 because I want the maximum power from my CPU to be applied to the task at hand. The only argument I hear from the intel types is that it makes your mp3's not skip. I feel sorry for them, but I don't get that on my linux box so I'll stick with the normal non HT mode myself.

Re:HT & threads

[Anonymous Coward]

OSen doesn't even make sense. Operating systemsen. Nice attempt at being pseudointellectual and uselessly verbose, though.

Re:HT & threads

[aminorex]

I think the dual channel memory is what is making the difference in the case you describe. You're getting a 16% bump instead of a 5 or 6% bump because the memory channels are being used more effectively, not just the core. In a single-channel memory system, I think the HT would only make a 5-6% difference. (This is an hypothesis, derived from my mental model of HT CPU operation, which can be used to confirm or disconfirm the model.)

Look what the dog dragged in !

[Anonymous Coward]

An Athlon and a Pentium system with FreeBSD running on it.
You should teach him to leave these fresh graves alone.

Re:Look what the dog dragged in !

[Anonymous Coward]

It is "Look what the cat dragged in." The *BSD trolls are so unimaginative and ignorant when they try to troll. Sad, really.

Re:Look what the dog dragged in !

[Anonymous Coward]

You never owned a cat right ?
Otherwise you would know that cats 1. never eat rotten corpses and 2. never dig out rotten rubbish.
That's what dogs do.

What about multiple processors?

[RT Alec]

Nice comparision, but what about dual or quad processor systems? I have recently installed both FreeBSD 4.9 and 5.2.1 on (almost) identical dual-Xeon servers. Both are operating as if they had 4 processors (due to HTT). How would the Athelon, etc. stack up with this setup (seriously, I'd like to know)? Maybe HTT realy shines on multiple CPU systems, not just mon-processor? Maybe.

BTW- FreeBSD (either version) on a brand new Dell rack-mount server, with hardware RAID, 2GB RAM, dual processor (of course) makes for a very fast server! I have them configured mostly as web servers, a number of Perl generated dynamic pages (ad serving mostly), rsync, CVS repository, Cyrus and Sendmail (w/SASL AUTH and TLS/SSL), MySQL, and a custom rsync staging/production environment. When I run top, it sure is nice to every now and then see 2 processors at almost 100% utilization, yet also show 50% idle. I have no benchmarks to report, alas these are production machines in use.

Re:What about multiple processors?

[Homology]

When I run top, it sure is nice to every now and then see 2 processors at almost 100% utilization, yet also show 50% idle.

It shows that you have capacity over for starting other processes. It also shows that your system is slower that it could be. Some food for thought relating to the uses of hyperthreading.

Re:What about multiple processors?

[Agent Green]

HTT offers little to zero benefit for properly optimized MP systems like FreeBSD. It helps with scheduling...not by giving you 4 processors of power.

Now, if you're running 100% on 2 "processors" which happen to be the same chip on HTT, you're really not using the full potential of the machine.

And to quote Chris Rock, "Turn that shit off!"

Re:What about multiple processors?

[Anonymous Coward]

Sorry, FreeBSD is not a properly optimized MP system no matter how you try to spin it. The stable branch only has a single threaded kernel, and the development branch is not "properly optimized". It is also not very parallel either.

But "turn that shit off" is right for a primitive MP capable system like FreeBSD - you don't want those additional threads tripping over themselves.

Re:What about multiple processors?

[ThaReetLad]

Simple answer is that an SMP opteron ('cos only 940 pin opterons work in SMP) would kick ass because they don't share memory bandwidth between processors. In fact available memory size and bandwidth scales linearly as you add processors and all available benchmarks show that overall performance scales at least twice as fast on Opteron systems as Xeon systems.

For a great aticle comparing SMP systems check out this article at Ace's Harware. I know that its not a BSD based comparison, but it should give you some idea.

Re:What about multiple processors?

[Anonymous Coward]

How would the Athelon
It's called Athlon you illiterate cumbubble.

Ultimate 64 bit Nethack box!

[forkazoo]

Wow, coupled with the ATI Radeon 9600ASC, I'd be the ultimate in cool, whilst getting my Nethack on.

I mean, don't get me wrong. I'm all about benchmarks. I love fast kit. I own an Athlon64, so seeing it win even makes me feel good about myself. OTOH, the performance differences tend not to be huge, and Athlon64 doesn't win every benchmark. Wake me up when I can afford 8 GB of RAM. That's when Athlon 64 will really matter.

Re:Ultimate 64 bit Nethack box!

[phoenix_rizzen]

You're forgetting something very crucial here ... the Athlon64 is clocked almost 1 GHz slower than the P4 ... yet the performance difference is virtually nil. That says a lot more about the performance of the Athlon64 than anything.

That's not a "ho-hum" benchmark to me. That's an "Intel has royally fubar'd themselves. Here's hoping their Pentium-M strategy brings them back on track."

Re:Ultimate 64 bit Nethack box!

[LWATCDR]

actually it would matter at anything over 4 Gigs of ram.

Re:Ultimate 64 bit Nethack box!

[Henry V .009]

So sad to see that the parent is yet another victim of the megahertz myth.

Imagine for a moment that a CPU maker created a chip that performed 10 times the number of operations per cycle that either Intel or AMD could achieve. But also imagine that because of the complexity, they could only get the chip to run at 50MHz. Not very useful, huh?

Intel has gone with a design that allows them to ramp up clock speed. AMD has gone with a design that allows them to use clock cycles more efficiently.

Both of those approaches are a perfectly good way to do things. All that matters is how fast the user's applications run in the end.

Re:Ultimate 64 bit Nethack box!

[obeythefist]

Interesting point, but surely, Intel will be running into physics problems way faster than AMD will, because Intel are running much closer to the raw speed edge.

Megahurtz myths aside, frequency is still frequency and there is an upper limit. The first one to hit the wall loses, by the way. So the frequency/performance aspect of intel processors is definately worth keeping in mind. This is why the Pentium-M is becoming the forefront processor-More IPC than the PIV architecture. Perhaps intel has hit the wall already?

Likewise, one could reason that many of the tricks that Intel are using to increase frequency could be applied to AMD's architectures in the future, giving AMD much more room for growth, as intel has already exhausted many of the available technologies.

Re:Ultimate 64 bit Nethack box!

[TheLink]

Doesn't it start to matter once you go past 2GB of RAM - e.g. 3GB, 4GB?

My limited understanding is that for many 32 bit O/Ses the kernel wants part of the address space for itself and the rest of the address space is for the currently running process.

If you have a 2GB:2GB address space split in some cases 2GB of kernel space isn't enough, in other cases 2GB of user space isn't enough. You can do 3:1 or 1:3 splits for some O/S but what gets squished into the 1GB space?

So it seems address space starts to matter way before you hit 4GB on 32bit os+machines.

Re:Ultimate 64 bit Nethack box!

[jasonsingha]

All chips are designed to run "at the edge" of the frequency upper limit and so AMD doesn't have an inherent advantage because they do more work per clock cycle and Intel does less work per cycle but has a higher frequency. All chip-makers hit the same physical limitations at about the same time and neither has the advantage because they run at a higher or lower frequency today.

The primary determination of clock-speed (besides process technology of course) is the largest number of transistors and the length of the wires in the critical path of each pipeline stage. For a chip with a higher clock-speed using the same process technology, this means that it has less wire or transistors in the longest path of each stage so it can be clocked faster. The presumption is that this is achieved by having more stages or better logic when compared to some other design, etc. but it really doesn't matter as far as the physics are concerned. All chips max out when the frequency is so high that the signals flowing through the circuits don't have enough time to go from one stage to the next and from this perspective, the only thing that matters is how much wire and how many transistors. If AMD was able to make faster chips, they would. Likewise with Intel.

It all boils down to this: if I have path with 10 units of delay and you have all paths with 8 or less units of delay, you will achieve a higher clock-speed if we use the same manufacturing process. Niether design is better for getting sped-up when moving to the next process technology since they use the same transistors and wire and are running at the same edge "node" in the current process technology.

Where AMD *may* have an advantage is that the top speed of chips may start to be effected by the power-consumption since if the chips get too hot, they will melt. Power-consumption for CMOS is determined by the dynamic component (when CMOS gates change their state they burn power) and a static component (determined by the total number of transistors). You used to be able to ignore the static component but as the feature size decreases, the leakage current begins to become quite noticeable. [AMD is using SOI already to help with this problem. Intel is eventually going to introduce its SOI work-alike (the name escapes me because it was invented by a marketing person).] Most advanced chips designs include circuits which burn power all of the time, but I'll assume that both Intel and AMD use the same tricks with the same small percentage of their transistors (and it is the same transistors with a high dynamic power usage anyways since they are important circuits).

If is conceivable that one design, Intels P4 or AMD64, is "more efficient" in this it uses less power both statically and dynamically, to acheive the same computations. At the end of the day, the more efficient processor may be able to compute the result quicker because it won't have to turn itself off just to cool down compared to the less efficient design. Currently this kind of limitation is only present in very small laptops.

However, you can't automatically assume that low frequency means the AMD64 design is more efficient. It may do more wasted work (speculation) per cycle in trying to do more work per cycle. It might have more transistors in its ALUs burning power, etc. One things that hurts Intel is that because they have a longer pipe-line, they have a higher penalty for branch mispredications, but they may just be able to tweak the branch predictor or make it larger to recoup this deficit.

At the end of the day, you'd probably find out that the two chips are about as efficient as each other (and that PowerPC processors are a little bit more efficient since they have much simpler decoders). I know that both AMD chips and Intel chips both burn a lot of power. If AMD sticks with SOI and Intel uses inferior technology, then AMD will win. But Intel has a lot of money and they probably won't get out-classed in technology by anyone.

Re:Ultimate 64 bit Nethack box!

[evilviper]

Wake me up when I can afford 8 GB of RAM. That's when Athlon 64 will really matter.

But you are forgetting a great many things.

First of there is heat and power... The Athlon 64 runs cooler, and requires less power than a regular Athlon/Pentium. And that's only the PEAK specs.

Dig deeper and you will find that the Athlon 64 is even better than that. It throttles down the MHz when the CPU isn't being fully utilized, so you are using even less power and creating even less heat, because surely you aren't going to be constantly maxing out the processor.

Then there are some other advantages. Athlon 64 uses ECC memory (which is a big advantage in my book), and has a significantly faster bus speed.

So, just because it isn't killing on all the benchmarks (is any of this 64-bit code even as well optimized as the 32-bit code? ICC isn't available for AMD64 yet...) doesn't mean it has no advantages.

Re:Ultimate 64 bit Nethack box!

[evilviper]

Both of those approaches are a perfectly good way to do things. All that matters is how fast the user's applications run in the end.

Yes, the fact that Intel's approach will melt your heatsink means nothing at all, and should be completely disregarded.

NETCRAFT NOW CONFIRMS: *BSD IS DYING

[Anonymous Coward]

It is official; Netcraft confirms: *BSD is dying

One more crippling bombshell hit the already beleaguered *BSD community when IDC confirmed that *BSD market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that *BSD has lost more market share, this news serves to reinforce what we've known all along. *BSD is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.

You don't need to be a Kreskin to predict *BSD's future. The hand writing is on the wall: *BSD faces a bleak future. In fact there won't be any future at all for *BSD because *BSD is dying. Things are looking very bad for *BSD. As many of us are already aware, *BSD continues to lose market share. Red ink flows like a river of blood.

FreeBSD is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time FreeBSD developers Jordan Hubbard and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: FreeBSD is dying.

Let's keep to the facts and look at the numbers.

OpenBSD leader Theo states that there are 7000 users of OpenBSD. How many users of NetBSD are there? Let's see. The number of OpenBSD versus NetBSD posts on Usenet is roughly in ratio of 5 to 1. Therefore there are about 7000/5 = 1400 NetBSD users. BSD/OS posts on Usenet are about half of the volume of NetBSD posts. Therefore there are about 700 users of BSD/OS. A recent article put FreeBSD at about 80 percent of the *BSD market. Therefore there are (7000+1400+700)*4 = 36400 FreeBSD users. This is consistent with the number of FreeBSD Usenet posts.

Due to the troubles of Walnut Creek, abysmal sales and so on, FreeBSD went out of business and was taken over by BSDI who sell another troubled OS. Now BSDI is also dead, its corpse turned over to yet another charnel house.

All major surveys show that *BSD has steadily declined in market share. *BSD is very sick and its long term survival prospects are very dim. If *BSD is to survive at all it will be among OS dilettante dbblers. *BSD continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, *BSD is dead.

Fact: *BSD is dying

AMD 3200 won with only 512k cache.

[BrookHarty]

I noticed they used the AMD64 3200, But the AMD64 3200+ only has 1/2 the cache compared to the 3400+, that extra cache should boost the build process even more.

Toms hardware has nice review and benchmarks for the 3400 vs the P4 3.4.

Also anyone notice, in both articles, P4's clean house on synthetic benchmarks, but real world (build process) the AMD cleans house.

Re:AMD 3200 won with only 512k cache.

[Too Much Noise]

I think you're mistaking the Athlon64 3200+ for the 3000+. 3200+ has 1M cache, while 3000+ has 512k. 3400+ has the same 1M cache, plus the 0.2GHz speed bump.

Come to think of it, this can actually be found on the very page you linked to.

Re:AMD 3200 won with only 512k cache.

[Anonymous Coward]

Yes, AMD won, not BSD. AMD rules, BSD is crap.

Mod this up, you know it's informative (unless you already knew all this, in which case it's still informative to others)

What a Refreshing Review!

[FFFish]

One page, no annoying Flash advertisements, no tedious space-filling fluff, solid information.

It's the antithesis of a Tom's review!

Re:What a Refreshing Review!

[Anonymous Coward]

One page, no annoying Flash advertisements,

It's good, Linux emulation on my FreeBSD box does not work, so Flash does not work. People who want to publish materials for FreeBSD folks should think twice before using Flash on their web sites.

64 bit is faster

[Anonymous Coward]

In the end I think the initial point is made with this review though, and that is that 64-bit does make a difference to the "average user" as well as the power user or administrator, but that performance advantage may not be evident in all situations. When under heavy load or dealing with large blocks of data, the Athlon64 (and we can assume that the Opteron and Athlon64-FX also apply) in 64-bit mode achieves superior performance to the same machine in IA32 (x86) mode. This is not so much because of the 64-bit addressing as it is the fact that there are twice as many general-purpose registers available.

It has been confirmed, Linux sucks...

[Anonymous Coward]

From Improving
Passive Packet Capture: Beyond Device Polling.

"Linux, a very popular OS used for running network appliances, performs very poorly with respect to other OSs used in the same test" (FreeBSD and Win2k).

"The Linux kernel module is almost as fast as the userspace FreeBSD application".

Percentage of packets captured (in user space), using device polling, at 80,000 packets per second? Linux 5.6%, FreeBSD 99.9%. Linux manages 99.5% only using a kernel module.

SO LINUX MUST GO TO KERNEL SPACE TO ALMOST BE AS FAST AS FREEBSD WITHIN USER SPACE! Oh yeah, Linux runs much better than the BSD's.

Maybe if you BSD is dying trolls stopped crapping on here about BSD dying and instead actually learned a language apt for your OS of choice, you might actually be able to bring Linux up to "dead status" with the BSD's.

But wait, it gets worse! While trying to capture packets from a DoS application, Linux could only manage capture rates of 0.8% in user space and 9.7% in kernel space, while FreeBSD managed 74.7% in user space!

"FreeBSD performs much better than Linux"

"it is obvious that a vanilla FreeBSD system is much more efficient than a vanilla Linux system when used for packet capture."

Re:It has been confirmed, Linux sucks...

[Anonymous Coward]

... at packet sniffing. In other news, FreeBSD
sucks
at
everything
else

From the recent tests performed by a BSD advocate, and linked here, we see Linux 2.6 has TRIPLE the exec throughput of FreeBSD 5.2, TRIPLE the context switch speed, less than half the system call overhead, and all, of course while being far more scalable.

I suggest that if you really have the need to show that FreeBSD is better than Linux, then you should concentrate on something other than performance. Stability might suit you better, because it is far more difficult for someone to get evidence either way to counter your FUD.

Have a nice day.

Re:It has been confirmed, Linux sucks...

[Anonymous Coward]

Troll? Sure.

If you FreeBSD zealots don't want the facts to escape, I suggest you stop giving me such easy targets.

At least if you use the old "stability" or "better engineered" lines or something equally stupid, I won't be able to easily prove you wrong.

Re:It has been confirmed, Linux sucks...

[Anonymous Coward]

Your google link is not very compelling, the mailing list link links off to a broken link, the fefe benchmark shows that FreeBSD and especially NetBSD perform very well (did you read it all? They had huge improvements in a very short time.) and the NASA story seems to have no relevence to BSD (can you enlighten us on that?).

The problem is, that at any one time, you can point at different versions of two kernels and get wildly varying results. Linux 2.6 performance is very impressive though.

The stable generic BSD's in the past have performed very well and consistent, often better than Linux. The improvements in NetBSD show that great things are coming and they will make it to FreeBSD eventually.

I think Linux and BSD will be neck and neck soon, as far as performance goes. As they both get closer to theoretical walls. Not that tricks like those found with NetBSD and FreeBSD won't be engineered.

Re:It has been confirmed, Linux sucks...

[Anonymous Coward]

Your google link is not very compelling

Oh, so a couple of BSD developers said this:


>> No, in theory increased performance should come from increased
>> parallelism with no increased overhead. Any increased overhead is a
>> bug. Linux 2.4 runs a thread safe kernel with less overhead than we
>> have in 4.x. Its possible.
>
> How are we going to achieve increased paralellism w/o increased overhead?
> Discounting redesigning algo's which would have been a win in the
> non-parallel kernel as well. A mutex is far more expensive than an spl.
> You have to protect against more things. Of course overhead is going to
> go up.

I have no idea really. All I know is that linux 2.4 is more parallel
than 5.x is today, yet it outperforms 4.x for things like system call
latency and networking packets/sec through a single interface.
Therefore it must be possible.


And you aren't "compelled"? OK...

The mailing list link did show Linux 2.6 had triple the exec throughput and triple the context switch speed and half the syscall latency. NetBSD had similar numbers to FreeBSD. Unfortunately it is broken now, yes.

The fefe benchmark still showed Linux ahead of the BSDs for the far majority of tests. They also have the tested (2.6) kernel released now. FreeBSD 5-STABLE is a long way off.

And the NASA story is just a nice little one I like for all those elite FreeBSD developers who, a couple of years ago were rubbishing those pimply faced linux kids and their crappy SMP scalability methods that wouldn't get very far and would end up in a big tangle of locks and single threaded performance would suck etc etc.

Guess what? Linux scaled to 512 CPUs, the core kernel and vm code is still pretty straightfoward, and single threaded performance is still very high.

And FreeBSD 5 on the other hand, is a big tangle of crap, it has taken big hits in single threaded performance, and it is still far less scalable than probably even Linux 2.4 (a modified version of which runs this 512CPU beauty).

I think Linux and BSD will be neck and neck soon, as far as performance goes

They used to be neck and neck, now Linux is in front and accelerating. Let me tell you, the theoretical walls for multiprocessor scalability are a *long* way further away from Free and NetBSD as they are from Linux.

Re:It has been confirmed, Linux sucks...

[Anonymous Coward]

I dont know why this got modded down. Anti-Linux stuff gets modded up constantly here.. but anyone who defends such attacks gets modded down.

Hypocrisy.

Re:It has been confirmed, Linux sucks...

[Anonymous Coward]

Ivan's benchmarking document is complete.

I love to use OpenBSD, for lots of reasons. I would love top performance as a bonus, but I use OpenBSD for where I like it to fit.

I'm getting into Gentoo now, so I'm happy there too.

I don't understand why people get so upset over what performs the best. The BSD's and Linux have benefited from each other and in the end we all get to choose what fits our needs the best.

Linux 2.6 excellent performance will probably benefit the BSD's in some way, even if just urging the BSD developers on and in the future no doubt the opposite will be true.

NetBSD made great improvements due to Felix's benchmark.

Re:It has been confirmed, Linux sucks...

[Anonymous Coward]

They used to be neck and neck, now Linux is in front and accelerating.

Have you looked at the finished benchmark document?

There is an area where Linux is 100 times faster than FreeBSD and yet NetBSD is 400 times faster than FreeBSD.

This benchmark that you covet so highly, is being largely discredited, to the point where the author is considering taking it off the net and re-doing it properly.

Linux 2.6 is pretty new, FreeBSD 4.9 takes very cautious steps forward and 5.x is an unstable work in progress. NetBSD made massive strides towards O(1) scaling in various areas, in a very short time.

Any fucking idiot can look at loads of benchmark numbers, find one small area where his OS of choice beats the "opposing" OS and then declare his OS the greatest.

Did you look at the real World benchmarks?

Judging by the bonnie++ and bytebench results alone, all Linux systems should have had a score far superior to the BSD's, but that is not the case. Linux 2.4 seems to be bound by some scalability issues, but they seem to be mostly resolved in the 2.6 series.

Doesn't look like Linux killing the BSD's and accelerating to me.

A clear winner here is FreeBSD 4.9, with Linux 2.6 not so far behind.

So, to sum up: You discredit an experimental branch of FreeBSD by linking to developer comments that are essentially regarding a moment in time. You link to the fefe benchmark and claim Linux to be far superior, when in fact it compares OS at very different stages of development and shows BSD's making huge improvements in just 2 weeks! And you link to a story about NASA deploying Linux to 512 processors, as a way of rubbing some people nose into the fact that Linux can actually scale well!

You are declaring a winner when the race in not yet finished. And here is a tip. The race never will be finished and during the never ending race, the lead will swap many times in many different areas. Stupid insecure people will continue to seek at least small areas where their OS shines, so as to feel good about themselves and belittle others.

You need to get over yourself.

BTW, I am not trying to say BSD rocks and Linux sucks, I am merely pointing out, that both have strengths and weaknesses (as compared to each other), in small areas. It is the overall performance of the required application that matters.

Re:It has been confirmed, Linux sucks...

[Anonymous Coward]

There is an area where Linux is 100 times faster than FreeBSD and yet NetBSD is 400 times faster than FreeBSD.

Yes, this is the per-char IO tests. If you knew anything about it, you would know that per-char IO throughput tests don't mean much here. FreeBSD probably goes to the kernel for each char, while NetBSD does a lot of buffering.

Any fucking idiot can look at loads of benchmark numbers, find one small area where his OS of choice beats the "opposing" OS and then declare his OS the greatest.

I said Linux had better exec, context switch and system call overhead. This is undisputed and confirmed by the results. You obviously got blined with rage by this and translated it into "Linux is the greatest". No such thing, zealot.

And you link to a story about NASA deploying Linux to 512 processors, as a way of rubbing some people nose into the fact that Linux can actually scale well!

Actually, proof. Some people still think FreeBSD "scales" better than Linux. Some people who know better try to perpetuate this myth too.

You are declaring a winner when the race in not yet finished. And here is a tip. The race never will be finished and during the never ending race, the lead will swap many times in many different areas. Stupid insecure people will continue to seek at least small areas where their OS shines, so as to feel good about themselves and belittle others.

You need to get over yourself.

All I did was post a couple of links. You're the one getting all insecure. I never said Linux was the winner. I said it is ahead now and it is.

When is 5.3-RELEASE coming out?

[Anonymous Coward]

It was supposed to be out on the 29th of March. :(

Re:When is 5.3-RELEASE coming out?

[Anonymous Coward]

Don't get your hopes up: it still seems pretty far from stable. Although of course they could release 5.3 soon, it probably wouldn't be -STABLE.

Either way, I'd expect there won't be a 5-STABLE branch until the end of the year if not longer.

Re:When is 5.3-RELEASE coming out?

[boelthorn]

I am running -CURRENT on my router. It has been running 50 days without any problems. I also run -CURRENT on my laptop and desktop systems, without problems... The only panic I had was when I forgot to recompile my nvidia kernel module after doing installworld/installkernel.

Re:When is 5.3-RELEASE coming out?

[Anonymous Coward]

Riiight, that must mean all the people reporting problems are just making them up.

Oh, and you can tell the developers they needn't bother implementing the rest of the required-for-5-stable functionality because you don't need it, just release now. After all, what do they know? If it works for your router it must be stable.

32 bit/64 bit comparision

[Chris_Jefferson]

Personally I feel the much more important part of these results is not the athlon64 pentium 4, but the athlon64 on 32-bit and 64-bit code. This is a set of benchmarks I've been trying to find for some time

If we ignore the cases where the 32-bit code has been optimised via ASM, it looks like the athlon64 is noticably faster on 64-bit code, and often much faster. This backs up what a number of people had been saying, that even if 64-bit code takes up more space the extra registers are a bonus (I'm thinking it's quite likely that gcc hasn't got around to using the various new instructions available yet)

Finally !!!

[DrYak]

I just got fed up reading article where Athlon64 are compared in 32bit mode on windows. Ok, I know that 64bits version of Windows XP is not finished yet, and that most of the "avarage bob user" will be going to use windows. But why has no benchmarking site (like Tom's Hardware) ever tried to make some {Linux64,BSD64,whatever-64} benchmark, juste to show us what benefits of the x86_64 architecture are already measurable ?

Re:Finally !!!

[bandrzej]

Actually, there is a beta version of Windows 64 bit out for AMD and Intel users to test out. Cost nothing to download, and you can get a CD in the mail if you need to. I had problems burning from their ISO, so i opted for the CD in the mail. The biggest advantage of Win 64 bit is you get past a great deal of the memory limitations in Windows XP and 2000. I have noticed a great difference in speed between running the same AMD 64 3200+ machine in Windows XP and Windows 64 bit on a dual boot.

Holy Crap!

[TR0GD0RtheBURNiNAT0R]

If thats what a standard Athlon64 does to a EE P4, I'd love to see what, say, the AthlonFX-53 would be capable of...

*salivate* If only I could afford one of the damn things...

Re:Holy Crap!

[MikeCapone]

If thats what a standard Athlon64 does to a EE P4, I'd love to see what, say, the AthlonFX-53 would be capable of...

IIRC, the Athlon FX is basically an Opteron and the P4 EE is a Xeon, so it says something about the server market too.

Re:Holy Crap!

[mobby_6kl]

I can't RTFA, but from the article summary it is a regular Prescott, not ExtremeEdition. IIRC, "E" stands for Prescott, "C" would be for Northwood core.

But...

[DrYak]

1. No compare has been ever made between Windows and Windows 64, AFAIK
2. This crappy beta's installer doesn't boot on my machine. And we're not the only one having problem do get it work.

Why BSD ?

[Anonymous Coward]

Why install BSD and not a popular OS like Linux or Windows 2000 on such fine hardware ?

Installing a dead OS is almost an insult.

I installed BSD once, and it was no fun. All the features are to ensure you have absolutely no fun and never enjoy anything you do. Immutable files everywhere, the OS restricts you in any way possible, and performance is lackluster.

I told BSD what everyone should say, "NO THANKS!"

Re:Why BSD ?

[Anonymous Coward]

I think they used BSD to show the quality of their hardware. Like "if our hardware excels with this crap OS, imagine what it can do for you!" - it's a marketing trick.

Re:Why BSD ?

[ValourX]

From a related article referenced in the story (I'll post the excerpt because you're a stupid troll and aren't going to RTFA):

"Before I continue, I'd like to elaborate on why I chose FreeBSD as a benchmarking platform. The original reason was that it supports both the AMD64 and IA32 (i386) architectures, and the purpose of the benchmarking project was to compare performance between an Athlon 64 machine in both i386 and AMD64 modes. I also wanted to compare these two setups with a Pentium4 3.2E system to discover if Hyper-Threading or 64-bit extensions were more important to computing power. Microsoft operating systems available at the time of the project were not able to run in AMD64 mode, and even if they were, there was no 64-bit capable benchmarking software to use on a Windows platform. So the first goal was to find an OS that could use these two machines in the required modes, and the second goal was to find relevant benchmarking methods that could show the performance difference between the configurations. GNU/Linux was an option (specifically Gentoo Linux), but it wasn't mature enough at the time of testing and it didn't offer much to me in the way of benchmarking. NetBSD was also a consideration because it supports so many architectures and has been working with AMD64 longer than most other OSes. This was particularly attractive to me because I could also benchmark machines that were based on the SPARC, POWER, and MIPS architectures and compare them all. This would have worked except for the fact that NetBSD didn't have an official release for AMD64 when I was ready to test, so I'd have to have used experimental code. I also would have trouble getting the same exact code onto each machine because it changes so quickly. FreeBSD already had an AMD64 release (two, actually) and it worked terrifically for my purposes. When I started testing I was using 5.2-RELEASE, but switched to and retested with 5.2.1-RELEASE when it became available. FreeBSD was perfect because I could use the actual release (guaranteeing the same age and quality of the code for both AMD64 and i386), and the ports tree had a number of excellent benchmark tests to choose from.

The FreeBSD base system comes with OpenSSL, which offers an excellent benchmarking mode. It also includes the old Unix time command, which is essential for stopwatch tests. So, all things considered, FreeBSD was the best operating system for the project."

I guess FreeBSD can't be dead if it had a more stable and mature AMD64 port than other operating systems did.

-Jem

Re:Why BSD ?

[cant_get_a_good_nick]

Yes, this is a troll, but Win2K does not have a AMD64 build. Even Current win2002 is beta on AMD64

Re:Why BSD ?

[Anonymous Coward]

time is included in most Linux distros.
So it OpenSSL.

I think someone cant get over the fact that *BSD is dead.

*BSD Joins the "B" Team

[Anonymous Coward]

It is with a heavy heart that we must report that Bob "I'm still dead" Hope has gone on to join the "B" team. As you all may know, BSD has been part of the "B" team for quite some time.

The Year of Our Lord 2003 has been a particularly bad year for the "B"s,

• Bob Hope
• Buddy Ebsen
• Buddy Hackett
• Barry White
• BSD

This honored list of dead is but a small token of adieu from the many fans of the deceased.
These dead were truly some American Icons. They will be missed.

Re:*BSD Joins the "B" Team

[Anonymous Coward]

Actually, I won't miss BSD. It wasn't very good, to put it charitably.

What I'd like to know is...

[Anonymous Coward]

Why do all comments that aren't flattering of BSD get moderated as "troll"? I have used FreeBSD for several months, I've read the handbook. I have also used various Linux distributions for years (but mostly Debian).

You can stifle free speech all you want, but you won't change my opinion that FreeBSD simply isn't anywhere as good as Debian in terms of reliability, ease-of-use and maintenance and user community. And I'm not saying this because I used Debian for very long - I gave FreeBSD a try at about the same time as Debian. I'm not saying this because I'm a GPL bigot either - my opinion is purely technical.

Re:What I'd like to know is...

[Anonymous Coward]

Why do all comments that aren't flattering of BSD get moderated as "troll"?

Because if you have nothing good to say about the dead, you shouldn't say anything at all. That's why.

Re:What I'd like to know is...

[DashEvil]

I like how you use four key points, without defending them at all.

How is it more reliable, how is it easier to use, maintain, and how is the community better?

I mean, personally I don't give a shit which you use; I prefer FreeBSD over Linux any day, for any purpose. That's just me.

P.S. Several months == nothing. n00b@!$!$ :P
But seriously, you do seem a TAD biased towards Linux. But that's cool too, because your opinion isn't going to change shit for me in the end.

Re:What I'd like to know is...

[Anonymous Coward]

I like how you use four key points, without defending them at all.

I like how you don't refute them with counterpoints either.

I've never heard a compelling argument about why BSD is better than Linux. It's like all those BSD fanboys and snobs just assume it to be true. There are no benchmarks, nothing. Just the belief that it has to be superior because it's so much leeter than those n00bs using Linux.

BSD snobs disgust me.

Re:What I'd like to know is...

[DashEvil]

I don't refute with counterpoints because I have no argument other than that your argument is weak.
BSD is not better than Linux, and Linux is not better than BSD. I personally am much more comfortable with a BSD system, your experience may vary. I don't care, and I do not think highly of someone who dislikes someone simply because of the OS that they choose to put their support behind.

BSD snobs disgust me.

Speed and stability aren't everything. For example: BSD could be 50% slower than Linux, and I could still get my work done in it faster. Don't agree? Don't believe me? That's your problem.

Get over it. What OS you use is irrelevant, it's whether or not you're accomplishing the task that you got on the computer to complete that matters.

BSD is very stable

[Anonymous Coward]

BSD is so stable, it doesn't move at all. Wait, doesn't breathe either.

think about the benchmarks!

[Anonymous Coward]

The benchmarks show that BSD is 2-5 times slower depending on the task being performed, so why do these zealots still use it? Someone needs to help them get their heads out of their a^H behinds.

how do I moderate the story down?

[Anonymous Coward]

thx. I think the story is a troll. 99% of benchmarks are trolling just to get people angry.

Unfair & Biased Moderations

[Anonymous Coward]

anything pro-BSD gets modded up.. anything pro Linux gets modded down.