Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Benchmarks of Debian GNU/kFreeBSD vs. GNU/Linux

timothy posted more than 4 years ago | from the slashing-for-both-teams dept.

Debian 143

An anonymous reader writes "The Debian Squeeze release is going to be accompanied by a first-rate kFreeBSD port and now early benchmarks of this port have started coming out using daily install images. The Debian GNU/kFreeBSD project is marrying the FreeBSD kernel with a GNU userland and glibc while making most of the Debian repository packages available for kfreebsd-i386 and kfreebsd-amd64. The first Debian GNU/kFreeBSD benchmarks compare the performance of it to Debian GNU/Linux with the 2.6.30 kernel while the rest of the packages are the same. Results are shown for both i386 and x86_64 flavors. Debian GNU/kFreeBSD may be running well, but it has a lot of catching up to do in terms of speed against Linux."

cancel ×

143 comments

Holy moley ! (0)

ls671 (1122017) | more than 4 years ago | (#30836206)

From the Linux only perspective, I am still running everything (servers, desktop, laptop) on Linux 32 bits even on 64 bits machine because I figured that running 64 bits wasn't really worth yet.

Now, I am really surprised to see that Debian Linux 32 bits is actually faster than Debian Linux 64 bits in many tests !

Re:Holy moley ! (1)

MBGMorden (803437) | more than 4 years ago | (#30836258)

32-bit was faster in a few tests, but it seems like overall the 64-bit still came ahead in more tests than it fell behind in.

Re:Holy moley ! (1)

ls671 (1122017) | more than 4 years ago | (#30836524)

Before seeing this benchmark I took for granted that 64 bits would be faster or at least come to par in all tests. How do you explain that 32 bits is faster in some tests ?

The only way I can explain it is that some piece of code is not optimized yet to run on 64 bits. This kind of prove my impression right; I can still wait for a while before upgrading to 64 bits OSes. The overall performance
gain might or might not be there depending on your use cases.

Of course, I will upgrade to 64 bits some day. Stability is also so a major concern and often, newer equals less stable or at least a new set of problems to troubleshoot.

Re:Holy moley ! (3, Insightful)

DAldredge (2353) | more than 4 years ago | (#30836632)

64-bit data structures can take up more space in the L1/L2/L3 caches which may cause code to run somewhat slower.

I've heard this...Unlikley. (0)

gbutler69 (910166) | more than 4 years ago | (#30837594)

Why? Because every 64-Bit CPU I've ever used always had more than twice as much L2 cache as 32-bit Systems. In other words, the hardware manufacturers/designers have already accounted for that.

Re:I've heard this...Unlikley. (3, Insightful)

ls671 (1122017) | more than 4 years ago | (#30837766)

> Because every 64-Bit CPU I've ever used always had more than twice as much L2 cache as 32-bit Systems.

I am glad I am using 64 bits CPUs to run my 32 bits OSes then ;-)

Well unless somehow, the "twice as much" doesn't get used with 32 bits OSes running...

What do you think ?

Re:I've heard this...Unlikley. (1)

barrkel (806779) | more than 4 years ago | (#30837900)

If you're talking about x64, the primary 64-bit consumer desktop / laptop CPU architecture, has it occurred to you that code running in the CPU's 32-bit mode also benefits from the doubled cache? It's not like the 32-bit code only uses half the cache, with 64-bit code using the full cache.

Re:I've heard this...Unlikley. (1)

obarthelemy (160321) | more than 4 years ago | (#30838470)

the tricky part is to NOT use half the caches when running 32 bit apps :-p

Re:Holy moley ! (3, Interesting)

Sillygates (967271) | more than 4 years ago | (#30838446)

But on x86, you are only guaranteed 4 *real* general purpose registers. x86_64 increases this number. With a good compiler, the register allocator would use all of these, and you would have much fewer loads from main memory, which can take on the order of 75+ cpu cycles on a cache miss, or 5+ cycles on a cache hit.

Re:Holy moley ! (1, Informative)

Anonymous Coward | more than 4 years ago | (#30839914)

The extra registers do help, but x86 has register renaming going on in microcode, and it's pretty good at it. It's only some very specific kinds of code that see dramatic benefit from the extra visible registers.

Mind you any app that uses 64-bit ints, like databases, usually sees dramatic improvements.

Re:Holy moley ! (1)

mirix (1649853) | more than 4 years ago | (#30839734)

Are they able to store double the words in 32 bit mode though? Or does it just stick a 32bit word in a 64bit register, and waste half of it?
If that's the case, it shouldn't give x64 a performance hit...

Why so ?!? (3, Informative)

DrYak (748999) | more than 4 years ago | (#30840166)

No, not necessary.

It's not because your CPU is running a 64bits OS that suddenly every data format has to be replaced with one using 64bit integers.
It's not because your CPU is running a 32bits OS that you aren't allowed to manipulate anything bigger 32bits.

The OS bittage has almost no impact on what data format can be used. Only how fast those format will be processed, and how many memory can easily be addressed in a straight-forward way.

A 256 x 256 bitmap, RGBA, with 8bits per channel, will always take the same amount of memory wherever the OS is running 32bits or 64bits code. Only with a 64bits OS it will be much more easy to store more than 3GiB worth of textures.
And even a 32bits OS can manipulate 1024bit data structures like crypto key (only a little bit slower, because the CPU internally won't be able to do 64bit operations).

Also most OSes are LLP64 or LP64, meaning that the default "int" still is 32bits. Thus code recompiled in 64bits will tend to approximately use the same amount of data as original code in 32bits.

Re:Holy moley ! (1)

Bert64 (520050) | more than 4 years ago | (#30836804)

64bit code uses more memory, which can in some cases result in decreased performance..
Also, i believe on some intel cpus some performance features are not available in 64bit mode (i forget the exact details)...

Re:Holy moley ! (4, Informative)

MBGMorden (803437) | more than 4 years ago | (#30837022)

As others have said, 64-bit programs take more memory to run. There's nothing inherently faster about 64-bit registers and operations unless you're dealing with integers that get that big (which in most everyday programs, they don't). What makes 64-bit faster isn't just "more bits", but optimizations. 32-bit code is typically compiled for the lowest common denominator: i386. However, x86-64 CPU's are guaranteed to be at least i686 compatible (you're also guaranteed up to a certain level of SSE compatibility and such). In that regard, it's the code optimization that we can rely on and not "more bits" (which due to extra memory usage, will typically make things SLOWER, not faster) to make things faster.

However, not every app or test really benefits that much from i686 optimizations. For those that don't, and don't deal in larger numbers (AND that don't use so much memory that a 64-bit chip is needed to address it), 32-bit processors will typically be faster.

As to stability, x86-64 is well past the "new" stage. The specification is 10 years old and processors based on it 7 years old - Linux support was almost immediate. Just how long does it take for you to consider it not bleeding edge anymore? :)

Re:Holy moley ! (4, Informative)

gmack (197796) | more than 4 years ago | (#30837254)

You missed out on the fact that there are more registers on 64 bit than the famously register starved 32 bit x86. More places to put things can't hurt even if your not dealing in 64 bit values.

The problem with 64 bit is that a lot of code is still hand tuned to the maximum possible performance on 32 bit arches and in at least a couple of the cases listed in the benchmarks I wouldn't be shocked if there was some hand done assembler involved. I have also noticed GCC has some performance tweaks that work around the lack of registers on 32 bit that also tend to get enabled in 64 bit..

Re:Holy moley ! (4, Insightful)

TheRaven64 (641858) | more than 4 years ago | (#30837030)

On most architectures, 64-bit code is slower. Pointers are bigger, which means you need more memory bandwidth to load them and you use more cache holding them. On x86-64, the situation is confused by the fact that 64-bit means 'using Long mode,' as well as 'using 64-bit pointers'.

Long mode gives you 64-bit registers (so you can store 64-bit values in a single register, rather than spread across two, doubling the number of 64-bit values you can store in registers), more registers, and a few other benefits like removing the 'must use EAX as the target' restriction on a lot of instructions (reducing the number of register-register moves, and decreasing instruction cache usage as a side effect). 64-bit pointers use more memory bandwidth and data cache.

For best performance on x86-64, you want pointers to remain 32 bits, but still run in Long mode. The OS should make sure that everything is mapped below the 4GB line for the process. As far as I am aware, no operating systems actually support this mode of operation. Without that, for any process using less than 4GB of address space, you have some advantages and some disadvantages when running in 64-bit mode. Whether the advantages outweigh the disadvantages, or vice versa, depends on the code.

Re:Holy moley ! (1)

ls671 (1122017) | more than 4 years ago | (#30837534)

> Whether the advantages outweigh the disadvantages, or vice versa, depends on the code.

That is exactly what I had figured out by intuition I guess ;-))

I have learned (or got refreshed on?) some logical explanations to this fact here today, thanks to you and some others.

I have to admit that I don't remember taking the time to evaluate 32 bits vs 64 bits advantages, just postponing that analysis and an eventual upgrade to later. I though I was past due on that matter but with what I have read today, I will postpone my upgrade for another 2 or 3 years. Ah, problems quickly solved, I like this.

Yet, I think some people might be under the impression that 64 bits performs way better than it actually does, like say, up to twice as fast ;-) This was almost the case when we went from 8 bits to 16 bits for obvious reasons like a few applications used only bytes (8 bits) in their code. Most of them were using types that typically require more than 8 bits, almost doubling the time to store/compute on 16 bits types on a 8 bit machine.

This brings an interesting point: Will 64 bits architectures be "enough for everybody" ?
Will there ever be a point where we might want to go 128 bits or above ?

Thanks for your reply,

Re:Holy moley ! (1)

TheRaven64 (641858) | more than 4 years ago | (#30839594)

There are some neat things you can do with a 128-bit architecture. For example, you can assign an IPv6 subnet to your machine and pointers and IPv6 addresses interchangeably. That's more or less what SGI does with their high-end machines; each node stores a 48-bit local address space and a 16-bit node ID in each pointer. The kernel can then access memory on other machines transparently via a cache coherency protocol. For at least the next decade or so, however, the overhead of doing this on a global scale is going to outweigh the advantages. Probably even then, because if you need to access remote resources you want to use something a bit higher level than pointers.

By the way, when we went from 8-bit to 16-bit architectures, we got 16-bit integer registers. When we went to 32-bit, we got 32-bit registers. We already have 128-bit vector registers on most architectures, and most vector units can treat these as single 128-bit integer or floating point values already, so the only advantage of a 128-bit architecture would be for

Re:Holy moley ! (2, Funny)

ls671 (1122017) | more than 4 years ago | (#30839996)

> so the only advantage of a 128-bit architecture would be for

supporting the full length of a message on /. ?? ;-))

Thanks for your reply anyway,

Cheers,

Re:Holy moley ! (2, Interesting)

VGPowerlord (621254) | more than 4 years ago | (#30838478)

For best performance on x86-64, you want pointers to remain 32 bits, but still run in Long mode. The OS should make sure that everything is mapped below the 4GB line for the process. As far as I am aware, no operating systems actually support this mode of operation. Without that, for any process using less than 4GB of address space, you have some advantages and some disadvantages when running in 64-bit mode. Whether the advantages outweigh the disadvantages, or vice versa, depends on the code.

Whoa, wait just a second. Before asking if the operating system support this, shouldn't we first ask "does the hardware support this?" or more specifically "does Intel's implementation support this?" because as far as I can tell from Wikipedia [wikipedia.org] , it doesn't.

Re:Holy moley ! (1)

Carewolf (581105) | more than 4 years ago | (#30839352)

The architecture doesn't have to support it. It is a chastity vow from the program, that while it may use 64bit, it simply opts to only use 32bit while still running in 64bit mode. Sounds confusing but is really simple.

The register is still 64bit (because CPU is in 64bit mode).
The memory slot used to store pointers is 32bit (because no more is needed).
The 64bit instruction set still has "load 32bit from memory" which may be used to load 32bit pointers into 64bit registers.

Now: The reason no one is doing it is becaue the C api states that the pointers should be 64bit when in 64bit mode. If you use a trick like this, your application will no longer be following standards, making it unable to use standard libraries.

Re:Holy moley ! (2, Informative)

TheRaven64 (641858) | more than 4 years ago | (#30840344)

The reason no one is doing it is becaue the C api states that the pointers should be 64bit when in 64bit mode. If you use a trick like this, your application will no longer be following standards, making it unable to use standard libraries.

Correction: The C ABI says that, and the C ABI is defined on a per-platform basis (for example, FreeBSD and Linux use slightly different calling conventions on IA32). It's up to the operating system to define the ABI or ABIs that it supports. Solaris, IRIX, and most other commercial UNIX variants have been happily supporting 32-bit and 64-bit ABIs on 64-bit platforms for a couple of decades.

Re:Holy moley ! (1)

TheRaven64 (641858) | more than 4 years ago | (#30839522)

Of course we shouldn't ask that, because it would be a stupid thing to ask. The hardware doesn't care. If you use 32-bit pointers then you zero-extend them when you load them into 64-bit registers. From the hardware's perspective, you're using 64-bit pointers, but the top 32 bits are always 0. It's up to the OS (and compiler) and has absolutely nothing to do with the hardware. It is the responsibility of the OS to define the memory layout for the application and if the OS refuses to map anything above the 4GB line then the app can safely use 32-bit pointers everywhere.

Re:Holy moley ! (1)

loonicks (807801) | more than 4 years ago | (#30839824)

as far as I can tell from Wikipedia [wikipedia.org] , it doesn't.

nah, it does. i edited the wikipedia article to screw with you.

Re:Holy moley ! (0)

Anonymous Coward | more than 4 years ago | (#30839626)

Could you site some benchmarks? Specifically some memory bound application that can run maybe 20-50% faster on a 32bit system than the same 64bit system... Could you also point to a non-SIMD case where have 64bit data values is useful but is pointer bound such that 32bit pointers are more efficient?

On most systems that are 64bit, and I can really only think of one exception off the top of my head (the first 21064 had terrible cache and memory performance) the caching is optimized with 64bit values in mind. And it's really "values" the processor doesn't care if they are memory addresses or just numbers until they are operated upon. They typically have caches with longer lines and memory buses that are capable of filling the whole cache lines. Likewise compilers line code up to help with the rest of the system that is optimized that way, your 32bit code on a 64bit chip might still be 8byte alined in memory for best performance. Now it's theoretically possible that if you hand optimized it all and memory access and cache thrashing are your slow points you could make a 32bit version much faster on a 64bit chip by craming more "pointers" into a line of cache but I don't know that it's been done, generally.

I don't believe there is an x86_64 chip that behaves as you want.

There are, however, certain SIMD problems that benefit from what you're describing and the MMX/SSE extensions to the x86 family have supported that for years and years (64bit registers, 32bit memory access, maybe even 128bit registers with SSE, I'm not an expert at it) the thing is there aren't that many problems that benefit from it.
 

Re:Holy moley ! (1)

exomondo (1725132) | more than 4 years ago | (#30839918)

But you'll see - and the numbers in the article back this up - that the real performance impact of this is minimal and the performance benefits outweight the defecits in the majority of cases.

Re:Holy moley ! (1)

cyberthanasis12 (926691) | more than 4 years ago | (#30837438)

I have been using SuSE Linux 64 since 2005 with no problems.

Re:Holy moley ! (1)

ls671 (1122017) | more than 4 years ago | (#30837694)

> I have been using SuSE Linux 64 since 2005 with no problems.

Patrick Volkerding has just released the first version of Slackware 64 bits about 5 months ago and it doesn't seem to have had any impacts on the perception Slackware users have ;-))

Granted, there was unofficial ports before that ;-))

Thanks for letting me know it is stable on your side although ;-)

Re:Holy moley ! (2, Interesting)

GooberToo (74388) | more than 4 years ago | (#30838430)

Before seeing this benchmark I took for granted that 64 bits would be faster or at least come to par in all tests. How do you explain that 32 bits is faster in some tests?

For most, its generally considered a wash. Larger data structures require more cache and more memory and more memory to be accessed. On the other hand, you also get more registers in 64-bit mode. As a result, some things run slower and some things run faster, depending on the nature of the application. On average its likely to be a wash.

The big exception are those that use the PAE 32-bit extensions. Generally speaking, 64-bit is going to be a lot faster. Even still, there are some odd exceptions which will hopefully fuel the imagination of possibilities.

One such exception comes from the PostgreSQL guys. For example, on Windows, they strongly recommend running 32-bit PostgreSQL on 64-bit Windows. This seems really non-obvious at first but there is a good reason for it. If you use 64-bit OS, that means you get large pointers which can access large quantities of memory without using PAE tricks. But, since PostgreSQL spawns processes for each back-end, that means you can run more heavy hitting (very large data sets, heavy queries, etc), concurrent back-ends without taking a performance hit. Additionally, PostgreSQL relies heavily on the OS to cache files. With a 64-bit OS cache, large data sets can be readily cached by the OS and quickly return results to the 32-bit PostgreSQL. This means PostgreSQL directly benefits from 64-bit size file caches; despite running as a 32-bit application. And best of all, a 32-bit PostgreSQL means smaller data structures and more efficient cache use, with twice the available cache a 64-bit application would require. Its almost the best of both worlds.

As the above example illustrates, sometimes a mix can provide ideal results, but on average, consider it a break even unless you plan on having 4GB or more in your box. And even then... ;)

Re:Holy moley ! (1)

drinkypoo (153816) | more than 4 years ago | (#30840550)

Because Postgres is really a Unix-type program and not an NT-type program, you mean; NT has cheap thread creation and expensive process creation, while Unix generally features the reverse situation. If Postgres were NT-ized and used multiple threads instead of multiple processes... perhaps things would be different. The bit-width of the system makes no difference to the amount of RAM used for file caches; are you talking about how fast you can shovel data with a 64-bit processor? Data shoveling is the only thing that actually does get dramatically faster.

Re:Holy moley ! (2, Insightful)

nedlohs (1335013) | more than 4 years ago | (#30836580)

Where many is ~20% of them.

And why would that be surprising? 64 bit lets you address more memory and they did the tests in a machine with memory that 32 bits could address all of. 64 bit pointers are obviously larger too, so the 32 bit version has effectively more memory and better cache usage.

Some programs aren't going to take advantage of 64 bit registers and so on, but are going to suffer from worse cache performance.

Stick 8 or 12 GB of RAM in and things might be different

Re:Holy moley ! (1)

ls671 (1122017) | more than 4 years ago | (#30836704)

> 64 bit pointers are obviously larger too, so the 32 bit version has effectively more memory and better cache usage.

Very good point ;-))

Re:Holy moley ! (1)

Erikderzweite (1146485) | more than 4 years ago | (#30836732)

I'm sorry, what?!
What are "many tests" you speak of?
32-bit Debian Linux was notably better only on compilation (which isto be expected) and POVRay. A couple of tests have shown very small advantage towards 32-bit system, but 64-bit has won MOST of 27 test hands down.

Re:Holy moley ! (2, Informative)

thePowerOfGrayskull (905905) | more than 4 years ago | (#30838068)

Now, I am really surprised to see that Debian Linux 32 bits is actually faster than Debian Linux 64 bits in many tests !

I'm not so surprised to see that somebody didn't read the graphs very well. 32 bit was faster in only 4 out of 25 tests (16%). Further, 2 of those were only marginally faster to the point where they barely count as a clear lead. Conversely in the majority of cases, 64 bit was not only faster but significantly faster. To the point where I wonder if there were other configuration differences -- for example I don't understand why you'd see a much higher hard drive TPS rate under 64 bit (something like 4x) -- unless they're using a different IO scheduler...

All that said, is it really so unreasonable to ask for results to be laid out in a simple grid for all tests? Raw data is what we like here... (To answer my own question - of course it is. That would mean fewer page hits...)

Re:Holy moley ! (1)

ls671 (1122017) | more than 4 years ago | (#30839498)

Hehe, sorry, my fault. I used "many" to mean "more than one" and that was a mistake. After reviewing the English dictionary, it seems that in English, "more than one" is expressed by "several". I used to think that they were almost synonyms but "many" means more "a lot" than "several".

My God, how many times must I have sounded like bullshitting before ;-))

Again, my mistake, I even learned the real signification of the word "many" today !! ;-)) /. teaches me all kind of stuff, including getting better in English ;-)

Cheers,

Re:Holy moley ! (1)

drinkypoo (153816) | more than 4 years ago | (#30840582)

After reviewing the English dictionary, it seems that in English, "more than one" is expressed by "several".

Nope. "More than one" means "more than one", and it is a common figure of speech. "Several" means "enough to be worth mentioning."

sigh (0)

grub (11606) | more than 4 years ago | (#30836222)


Debian GNU/kFreeBSD may be running well, but it has a lot of catching up to do in terms of speed against Linux."

Yep, because we ALL KNOW speed is EVERYTHING when running a computer.

groan.

Re:sigh (2, Insightful)

MBGMorden (803437) | more than 4 years ago | (#30836298)

Yep, because we ALL KNOW speed is EVERYTHING when running a computer.

Of course it's not everything - but it IS a major part. Cost is another. We're at a tie there.

So what's left? User friendliness? These systems use the same apps - tie there too.

We're basically left with security and stability. If you want to write and article on those feel free - I'm sure Linux won't fare too bad there, but I'd like to see the results.

Still though, to dismiss speed as a criteria is just being naive.

Re:sigh (3, Insightful)

TheRaven64 (641858) | more than 4 years ago | (#30837190)

The speed difference is a few percent. For most people, that's not noticeable. My kernel CPU usage stays well below 10% most of the time, even when the CPU is busy, so even a 50% difference in kernel performance wouldn't be particularly important. Much less important, for example, than things like ZFS, DTrace, a decent kernel sound system, and so on.

Re:sigh (1)

gclef (96311) | more than 4 years ago | (#30837952)

It's not noticeable for most people...but for those of us in situations where it is noticeable that sort of difference is interesting. For example, my office has a debian box that runs at a continuous load average of around 5. Shave 10% off that & we'd notice.

Re:sigh (2, Insightful)

clarkn0va (807617) | more than 4 years ago | (#30836318)

I think speed is everything when you're writing an article for a benchmark site. Note that I'm not disagreeing with your ironic implication that there are other things to look at, but obviously it's a lot easier to churn out some graphs than to try to compare two OSes/suites/whatever on other important metrics, such as security or usability. Leave that to the media troll sites--there's no shortage of them.

Re:sigh (1)

ShieldW0lf (601553) | more than 4 years ago | (#30839410)

It would be interesting if this ends up being forked into a GPLv3 project and forms the basis for the first ever pure GPLv3 distribution.

Bad time for a holy war (2, Funny)

stokessd (89903) | more than 4 years ago | (#30836280)

We can't start a holy war now! My armor is at the cleaners.

Cue nerd rage

Sheldon

Mod Article Flamebait (5, Insightful)

TheRaven64 (641858) | more than 4 years ago | (#30836286)

Okay, so I only read the first couple of pages because it's Phoronix who have a history of inflamatory and misleading benchmarks, but from what I saw:
  • Sometimes Linux is faster.
  • Sometimes FreeBSD is faster.
  • Usually the difference between the two is smaller than the difference between IA32 and x86-64.
  • The tests were mostly either CPU- or I/O-bound, so there are lots of factors beyond the kernel that would affect the results.
  • Debian kFreeBSD uses an old FreeBSD kernel, not sure how old the Linux kernel is but it's probably not representative of the speed of recent releases of either kernel.

Re:Mod Article Flamebait (3, Informative)

Henk Poley (308046) | more than 4 years ago | (#30837268)

Linux 2.6.30 is from Jun 9 2009. The latest patchset 2.6.30.10 though is from December 3rd.

Re:Mod Article Flamebait (3, Insightful)

bark (582535) | more than 4 years ago | (#30837530)

It's NOT testing freebsd. the article tests the Debian world running with FreeBSD

Re:Mod Article Flamebait (1)

DiegoBravo (324012) | more than 4 years ago | (#30839116)

> # Sometimes Linux is faster, # Sometimes FreeBSD is faster. # Usually the difference between the two is smaller than the difference between IA32 and x86-64..,

That's what I would expect! A big difference would be something weird.

> The tests were mostly either CPU- or I/O-bound, so there are lots of factors beyond the kernel that would affect the results.

The benchmarks must be CPU or I/O bound... why should they benchmark sleeping apps?

>Debian kFreeBSD uses an old FreeBSD kernel, not sure how old the Linux kernel is but it's probably not representative of the speed of recent releases of either kernel

I really don't hope the last minute changes to the kernel, to do a big improve the system performance.

Re:Mod Article Flamebait (3, Insightful)

TheRaven64 (641858) | more than 4 years ago | (#30839464)

The benchmarks must be CPU or I/O bound... why should they benchmark sleeping apps?

If they're I/O bound, userspace and kernelspace are both waiting for the drive. The layout of the files on disk will have more of an impact than the kernel. You are right that things should be CPU-bound, I should clarify that I meant userspace CPU bound. You want to benchmark things that are systemcall-heavy, like concurrent apps that use lots of synchronisation primitives.

I really don't hope the last minute changes to the kernel, to do a big improve the system performance.

FreeBSD development follows three branches. -CURRENT is where all of the latest stuff is. -STABLE is where stuff that has been tested a bit in -CURRENT goes. -RELEASE branches are where only bug fixes (no new features) go. The 8.x series began development as 8-CURRENT shortly after 7.0 was released (about two years ago). Some features were then back-ported to the 7-STABLE branch, but only those that could be moved without invasive changes that might affect system stability.

8-RELEASE is the latest stable release and has had two years worth of new features on top of the one shipped with Debian, including, among other things:

  • Improvements to processor affinity and scalability in the scheduler.
  • A completely new USB stack.
  • A newer version of ZFS.
  • Improvements to the sound subsystem (now contains a full OSS 4 implementation, per-vchan volume control, a massively improved mixing algorithm, and other improvements)
  • A new NFS implementation, including NFSv4 support.
  • Network stack virtualisation for jails.

It's not a matter of last minute changes, it's a matter of not getting the last two years of improvements. I know that Debian likes the stable-and-tested versions of things, but they don't seem to apply that policy to the Linux kernel.

Re:Mod Article Flamebait (1)

DiegoBravo (324012) | more than 4 years ago | (#30839940)

> If they're I/O bound, userspace and kernelspace are both waiting for the drive

Filesystem strategies can impact severely the time the CPU is waiting for data. This is very important to people who runs databases.

> You want to benchmark things that are systemcall-heavy, like concurrent apps that use lots of synchronisation primitives.

Well, yes, for a pure kernel bench, and I accept it that seems to be the main purpose of TFA; but for me it's more interesting and useful a test of the system as a whole. For example, a GZIP test at 100%-userspace or the ImageMagick compilation can give me a hint about the whole set of wiseness and/or optimizations that the memory management (with help from the compiler) code could make in that platform.

Re:Mod Article Flamebait (0)

Anonymous Coward | more than 4 years ago | (#30839666)

Debian kFreeBSD uses an old FreeBSD kernel, not sure how old the Linux kernel is but it's probably not representative of the speed of recent releases of either kernel.

According to kernel.org and freebsd.org :
Linux stable: 2.6.30.10 2009-12-04
FreeBSD stable: 7 2008-02-27
FreeBSD stable: 8 2009-11-26

The comparison should have been done with FreeBSD 8 or an older version of debian using a kernel of the same vintage.

Phoronix (3, Interesting)

OverlordQ (264228) | more than 4 years ago | (#30836306)

While they're really the only group that does a lot of linux benchmarking, I'd put a *large* grain of salt in their results.

They have no problem blindly accepting something like this [phoronix.com] without investigating why it is so much faster and seeing if there's a problem with their testing.

Re:Phoronix (1)

machine321 (458769) | more than 4 years ago | (#30838856)

Perhaps because it was in line with their other, unrelated benchmarks? I note you don't identify any problems with their testing, you just imply there must be a problem and they didn't look for it.

Besides, you should have shown the PostMark benchmark, where it was a 10:1 improvement with 64-bit.

Wait a minute... glibc? (1)

Tinctorius (1529849) | more than 4 years ago | (#30836322)

Didn't Debian switch to eglibc because Drepper was being an asshole?

*BSD is Dying (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#30836348)

It is now 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 [samag.com] in the recent Sys Admin comprehensive networking test.

You don't need to be the Amazing Kreskin [amazingkreskin.com] 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 dabblers. *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

Article over 9 pages..... (0)

Anonymous Coward | more than 4 years ago | (#30836354)

.....fuck that! Tab got closed, comments get whinge added, going elsewhere.

I just wanted to see if ... (3, Funny)

sharkette66 (256044) | more than 4 years ago | (#30836444)

I don't use BSD, I just wanted to see if the "BSD is dying" troll still posted. It has been years, eh?

It does also seem to me that the FreeBSDk thing is meant to make certain features available to developers, maybe be more reliable, and "faster, faster" isn't being sold as part of the bill of goods. Yet, the talk returns to speed, speed, speed.

But what do I know... I work as a nurse. Although... I DO love a fast computer.

iPod/iPhone/OSX/etc (-1, Troll)

Anonymous Coward | more than 4 years ago | (#30836890)

BSD is not dying, it is LINUX that is dying. On the desktop, it is nearly dead, on servers it is starting to lose out badly to Windows 2008 and OpenSolaris, and in embedded work, BSD is eating its lunch. All of this can be put down to one thing and one thing only: the zealous use of the communistic GPL license that takes away freedom from everyone.

Re:I just wanted to see if ... (1)

brackishboy (1432215) | more than 4 years ago | (#30836960)

That meme died ages ago. Netcraft confirmed it.

Please educate me a bit. (3, Interesting)

santax (1541065) | more than 4 years ago | (#30836478)

As a long time debian user who also has to work with freebsd sometimes I don't get it. Why use freebsd with GNU apps, when you can just run freebsd? And why freebsd and not lets say, openbsd or netbsd? What is the advantage in using the freebsd-kernel instead of the linux-kernel? I have access to every linux app when I use freebsd and to be honest, if I knew my way around bsd as I do under debian I would probably switch. But I am missing the improvement for Debian here. Can someone please clear this up for me a bit?

Re:Please educate me a bit. (1)

Erikderzweite (1146485) | more than 4 years ago | (#30836756)

Well, why not? I don't feel I'm going to use it, but it's nice to have a choice.

Re:Please educate me a bit. (2, Informative)

BitZtream (692029) | more than 4 years ago | (#30836808)

'Because we can' is the answer you are looking for I think.

Considering what they've done (most of it anyway) can be accomplished with a few flags to make.conf anyway, its not exactly impressive. Tell the system to use glibc instead of its native libc, then rebuild world (to rebuild the built in GNU tools with glibc) and build the ports for other GNU tools you want and you've got what they made.

You could probably write a fairly trivial sh script to do this on a generic FBSD install.

This is just a typical 'We did it because we can and we wanted to' type of thing the way I see it.

You use the FBSD kernel because its going to have the largest driver base compared to the other two for hardware that people care about, although NetBSD can't be far behind it. OpenBSD is just a bitch thats not worth the effort to deal with for any reason since it has no real advantage over a FBSD 'Minimal' install, possibly with some config tweaks but it won't be many.

The one shining thing you can get, is a native ZFS implementation, though by using an old kernel they've kinda killed that idea since the version in that kernel is not really production ready. You get jails, which are nice for some purposes, but with paravirtualized linux on linux and enough ram its really not that big of a deal. They also claim that you get the advantage of the debian package system, but other than a gui I see no outstanding advantage over the FBSD package system, with the exception that I think they still don't make a screen package due to some kernel interface issues that break it when used with a kernel compiled with slightly different options, its never been a problem for me, I build and distribute screen internally to our BSD boxes without 'noticing' a problem.

TFA has more reasons why you might want to do it, but they all seem pretty weak to me, but I'm a FBSD person, and don't care for Linux that much, so my bias is probably not helping.

Re:Please educate me a bit. (1)

santax (1541065) | more than 4 years ago | (#30836990)

Thank you and the other people for giving your views. Because we can sounds like a perfect legitimate reason and I did my part of 'well, because I want to see if I can' myself. ZFS is indeed a value-improvement of debian I think and that is cool. (well I think that is cool). Still I am not really satisfied with the answers (sorry, please don't take this personal cause it isn't) I just hope the devs have some sort of great masterplan that totally makes sense.

Re:Please educate me a bit. (1)

mrsteveman1 (1010381) | more than 4 years ago | (#30837188)

As someone who is just now stepping into FreeBSD and who has managed Debian/Ubuntu systems for quite some time, i do find the front end tools for package management on Debian to be a bit nicer than pkg_add/pkg_delete on FreeBSD, but i know there are many other tools on FreeBSD for this purpose that i haven't found yet :)

Re:Please educate me a bit. (4, Informative)

vlm (69642) | more than 4 years ago | (#30837244)

but other than a gui I see no outstanding advantage over the FBSD package system

As a gauge of relative activity level in each package system:

The weekly list of UPDATED (and possibly NEW) BSD packages at

http://www.freshports.org/ports-new.php?interval=week [freshports.org]

is roughly equal in size to the weekly list of NEW Debian packages at

http://packages.debian.org/unstable/main/newpkg [debian.org]

So, each week, there is about as much new stuff added to Debian as there is updated preexisting stuff in BSD.

Re:Please educate me a bit. (0, Flamebait)

idiotnot (302133) | more than 4 years ago | (#30838436)

Not only that, they're cleanly managed with apt and dpkg. Ports has grown so unwieldy that when I do use FreeBSD these days (admittedly, it's pretty rare), I don't build anything from ports, and use pkgsrc [netbsd.org] . On the rare occasion that pkgsrc doesn't have something I need, I'll just build it from source manually. But, but, but, but portsupgrade!!!1! It sucks compared to apt/dpkg and pkgsrc. 8, 10 years ago, maybe it was great. But notsomuch anymore.

I also use pkgsrc on Slackware, OpenBSD, and OS X.

Re:Please educate me a bit. (0)

Anonymous Coward | more than 4 years ago | (#30839412)

Debian kFreeBSD leverages much more than the APT *tool*.
The huge chunk of work that Debian is doing is in the packaging process (validation, QA, security updates).

From a more practical POV, I would be happy if I could manage only Fbsd/Linux Debian systems instead of a tenth of OpenBSD and hundreds of Linux Debian.

Re:Please educate me a bit. (1)

machine321 (458769) | more than 4 years ago | (#30838920)

In other words, in FreeBSD they fix the shit that's there, in Debian they just keep shoveling in more shit.

FreeBSD ports can't be relied upon (1)

r00t (33219) | more than 4 years ago | (#30837504)

The other day, I was installing an old FreeBSD system for compatibility with some stuff I had. I figure it's like installing an old Linux, right?

Wrong. When I install an old Linux, I can install all the old software. The *.rpm or *.deb files exist. FreeBSD doesn't work like that. It has ports. If your system is old, you're screwed. The ports system is only 100% available for the latest release. For older releases, there is a sort of weak idea that maybe it kind of sort of ought to be maintained when somebody bothers, but probably it'll just FAIL.

Really, that's crap. An OS shouldn't become unavailable as it ages. I might need it!

Slackware from 1994 still works as well as it did back then, 16 years ago. What's FreeBSD's problem?

Re:FreeBSD ports can't be relied upon (2, Informative)

bark (582535) | more than 4 years ago | (#30837636)

This is wrong. the Ports system is based on CVS, so in essence, you can go back version by version, back to the beginning, and select version numbers of the software to install at will, without having to depend on precompile binaries. You use the supfile to select the port version you need http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvs-tags.html [freebsd.org] Gives you all the branch tags that you can check out via historical cvs. But Alter Relationship obviously didn't read the handbook, and started complaining without even reading the man pages.

Re:FreeBSD ports can't be relied upon (2, Insightful)

r00t (33219) | more than 4 years ago | (#30837910)

In theory, perhaps.

On that web page I see this: "The ports and doc trees use tags whose names begin with RELEASE tags." Excuse me, WTF? You're only going to tell me how the name begins and leave me to guess the end?

Can I go back 15 years? Can I do this for versions 1, 2, or 3?

What about all the stuff it drags in? Is the old source code actually there, or just the build system?

I sure hope that a CVS checkout isn't going to drag a bunch of old history with it. Gigabytes would be unfriendly.

I can go to Red Hat or Debian's site and just download the packages I want, either binary or source. Why does FreeBSD makes things so unusable?

Re:FreeBSD ports can't be relied upon (0)

Anonymous Coward | more than 4 years ago | (#30838368)

I'm sorry, FreeBSD doesn't make allowances for idiots. It's not their fault that you can't understand the docs.

Re:FreeBSD ports can't be relied upon (2, Funny)

Bluesman (104513) | more than 4 years ago | (#30838750)

I wish Alter Relationship would stop replying to himself.

He's almost as bad as that other troll, Friend of a Friend.

Re:FreeBSD ports can't be relied upon (0)

Anonymous Coward | more than 4 years ago | (#30840328)

Yes, your slackware from 1994 is full of security holes. The FAIL here is you trying to install an unsupported version of the OS and then complaining about it when it doesn't work.

Re:Please educate me a bit. (1)

morgan_greywolf (835522) | more than 4 years ago | (#30837932)

They also claim that you get the advantage of the debian package system, but other than a gui I see no outstanding advantage over the FBSD package system, with the exception that I think they still don't make a screen package due to some kernel interface issues that break it when used with a kernel compiled with slightly different options

What are you talking about? I have screen installed on FreeBSD 8, all I had to do to install it was 'pkg_add -r screen'.

Re:Please educate me a bit. (2, Interesting)

0racle (667029) | more than 4 years ago | (#30836838)

Off the top of my head, and pretty much pulled out of my ass:

The FreeBSD kernel can be faster the Linux, but there are a lot of poorly written apps that think they absolutely must run on Linux or were written expecting GNUisms. Now you can do that.

FreeBSD is generally the more generic and performance driven of the BSD's with a larger developer base then the othe BSD's. The odds for very good performance and good hardware support are in FreeBSD's favor over Open or Net.

Porting apps to different platforms can have the advantage of opening or exaggerating new or difficult bugs in software, the end result being that everyone gets a better final product out of it.

Finally, of course, why not?

Re:Please educate me a bit. (1)

Bill, Shooter of Bul (629286) | more than 4 years ago | (#30836852)

I prefer Gnu Userland. As for the kernel, its another option. Even though I prefer KDE, I wouldn't say that Gnome devs are wasting their time, or debian shouldn't allow users to install it. FreeBSD's kernel seems to be more performance tuned than Open BSD or Net BSD. Makes sense to me.

Re:Please educate me a bit. (4, Informative)

eqisow (877574) | more than 4 years ago | (#30836908)

Why use freebsd with GNU apps, when you can just run freebsd? And why freebsd and not lets say, openbsd or netbsd?

They actually have a NetBSD port [debian.org] as well as a Hurd port [debian.org] . They also have a nifty why NetBSD [debian.org] section. There doesn't seem to be a similar page for kFreeBSD, but I assume the reasons are similar.

Re:Please educate me a bit. (1)

santax (1541065) | more than 4 years ago | (#30837062)

Thank you for the link to the why-page. It does explains things for me.

Re:Please educate me a bit. (1)

machine321 (458769) | more than 4 years ago | (#30838972)

You mean GNU/NetBSD and GNU/Hurd, right?

Re:Please educate me a bit. (0)

Anonymous Coward | more than 4 years ago | (#30840460)

Actually, yes, that's what they call them, but the 'GNU' wasn't necessary or proper in that context.

Re:Please educate me a bit. (1)

Enleth (947766) | more than 4 years ago | (#30836954)

When George Mallory, the guy who attempted to climb Mount Everest several times (and almost succeeded, though the most successful attempt was also fatal in the end), was asked why exactly would he try to climb it, as it was extremely dangerous and he wasn't even a scientist or a cartographer, he said one simple thing.

"Because it's there."

Sure, there probably are some practical purposes for a version of Debian running the FreeBSD kernel, but whatever those might be, I think it's not a matter of "what for" but of "why", and this in turn is answered by the aforementioned quote.

Someone wanted to do that, probably just for the heck of it, someone else thought that it might be fun, they joined their efforts and did it. A good part of the whole FLOSS and academic research worlds works like that. Nothing wrong with that, IMHO.

Re:Please educate me a bit. (1)

ChipMonk (711367) | more than 4 years ago | (#30838462)

Along the same line, I'm reminded of JFK's challenge to put a man on the moon before 1970. After the Sputnik shock and the subsequent re-grouping, we were ready to push our limits, doing things "not because they are easy, but because they are hard." And by the time Apollo 11 returned, with everybody safe and sound, the benefits of the space program was reaching society at large.

With such a large challenge, overcoming the hurdles on the way produces benefits that often can't be quantified beforehand. And we are all better off for it.

Re:Please educate me a bit. (3, Informative)

vlm (69642) | more than 4 years ago | (#30837028)

Why use freebsd with GNU apps, when you can just run freebsd?

Then you'd be stuck with freebsd apps instead of GNU apps.

If you have a mighty herd of servers, desktops, and kiosks, all sharing various automation scripts, supporting both freebsd and GNU command line apps could be a pain, due to subtle differences in command line options, etc. Its possible to create a blizzard of "if then" to work around, but why bother.

But I am missing the improvement for Debian here.

Overall, none really. The way ports work on Debian, is if enough people volunteer to maintain a port, and they are successful, then we have a new port. Heck, that is the way everything works in the Debian project, if something meets a certain standard of excellence, its in, no matter if its a package, docs, artwork, shared VCS, human language translation, a network service, a mirror, or in this case, a port. Debian is thankfully not a deletionist stronghold like that dumpy embarrassment known as wikipedia.

This link provides a one page summary of each attempted Debian port, successful and ... not so successful :

http://www.debian.org/ports/ [debian.org]

Re:Please educate me a bit. (0)

Anonymous Coward | more than 4 years ago | (#30839956)

Debian is thankfully not a deletionist stronghold like that dumpy embarrassment known as wikipedia.

Calling Wikipedia a deletionist stronghold is like accusing Fox News of having a liberal bias. It says a lot about your prejudices, and nothing about reality.

In the real world, deletionists are (and always have been) a rather unsuccessful minority on Wikipedia. About the only victory they ever won was when they managed to get a bunch of webcomic articles deleted, and that was years ago. Schools? Inclusionists won. Pokemon? Inclusionists won. Pop songs? Inclusionists won. Etc.

Re:Please educate me a bit. (3, Informative)

TheRaven64 (641858) | more than 4 years ago | (#30837346)

The FreeBSD kernel gives you a few nice things. ZFS, DTrace, and a high-performance in-kernel sound system that eliminates the need to mess about with things like PulseAudio just to get half a dozen applications going 'bing' at the same time while another one plays music (although this got a lot of improvements in the FreeBSD 8 kernel, which isn't in Debian yet, as did ZFS). It also gives you the ULE scheduler, which has had several years of testing and refinement (unlike Linux's scheduler-of-the-week) and performs very well (was outperforming Linux by a large margin on 8+ cores, now they're pretty similar). It includes Jails, which are like chroot but with a complete environment inside so you can have a different IP, different users, and so on in a jail (and you can create them with a complete clone of a skeleton system almost instantly with ZFS clones).

As to why you'd use Debian rather than FreeBSD, the big difference is glibc rather than BSD libc. When people talk about Linuxisms in code, they most often really mean GNUisms and the code depends on something weird in glibc, rather than on anything specific to the kernel. It will therefore work with glibc on kFreeBSD just as it would with glibc on Linux. You may also prefer the GNU userland utilities. Some people install these on FreeBSD anyway, but with Debian they are the default ones. This means that a few other common GNUisms (e.g. assuming that /bin/sh is bash and that POSIX utilities accept GNU arguments in shell scripts) will work.

This means that it's easier to port crappy code (and there is a lot of it about) from GNU/Linux to GNU/kFreeBSD than to FreeBSD. I've written a bit about which bits are GNU and which bits are Linux [informit.com] before: most of what the user or developer interacts with is GNU.

Re:Please educate me a bit. (0)

Anonymous Coward | more than 4 years ago | (#30840154)

Why use freebsd with GNU apps, when you can just run freebsd?

Because fBSD has a terrible BSD-like userland stuffed full of all the BSD quirks, and most people strongly prefer GNU userland? Because fBSD has some great stuff in the kernel, but a Debian userland on top of it would make it suck less? Because Debian isn't Linux? Because the Linux kernel is starting to suffer from decades of driver bloat and the 2.6 series' declining stability is undermining the desire of the user base to stick with Linux?

Personally, I'd be much more interested in FreeBSD or one of the other BSDs if it weren't slathered with all those commands that kinda-sorta work sometimes except for not recognizing half the options I pass them. Slapping a GNU userland on it makes it more appealing.

Pick a reason, any reason. Make up your own if you like.

This benchmark is useless without ZFS (0)

Anonymous Coward | more than 4 years ago | (#30836484)

This benchmark is useless without ZFS.

Comparison with original FreeBSD? (2, Insightful)

maxwell demon (590494) | more than 4 years ago | (#30836754)

What about a performance comparison with original FreeBSD?

Re:Comparison with original FreeBSD? (0)

Anonymous Coward | more than 4 years ago | (#30836914)

There are FreeBSD 7.2/8.0 benchmarks being added to the comparison next week at Phoronix.

Re:Comparison with original FreeBSD? (1)

vlm (69642) | more than 4 years ago | (#30837316)

What about a performance comparison with original FreeBSD?

The "original"? Just for laughs, get the results for version 1.0 from 1993 along with 8.0-RELEASE and 9.0-CURRENT

http://en.wikipedia.org/wiki/FreeBSD#Version_history [wikipedia.org]

Flash? (2, Interesting)

xoundmind (932373) | more than 4 years ago | (#30837050)

So can I run Flash-enabled browser on this port?

Re:Flash? (1)

hhw (683423) | more than 4 years ago | (#30839052)

You've been able to use the linux adobe flash plugin with a native browser for quite some time now. Works just as well as it does in Linux (not necessarily saying much). The FreeBSD handbook is your friend:

http://www.freebsd.org/doc/handbook/desktop-browsers.html [freebsd.org]

glibc (1)

argent (18001) | more than 4 years ago | (#30837380)

glibc is a much more complex libc than the one FreeBSD uses. FreeBSD doesn't use libc as the "glue layer" nearly as much as Linux, so the extra overhead of glibc is wasted.

A marriage made in... (0)

Anonymous Coward | more than 4 years ago | (#30838438)

The unpolished GNU userland and GlibC (no offense, just compared to BSD's userland/libc or Solaris, they just tend to be weirder imo) combined with FreeBSD's stable but mostly unsupported kernel (Oh? You wanted ALSA? Sorry. You wanted Linux kernel modules? Oh, sorry. You need Linux hardware support? Oh sorry).

So I guess you get the worst of both worlds? Awesome.

And it's slow.

Great job guys :D

Question? (2, Insightful)

Murdoch5 (1563847) | more than 4 years ago | (#30839000)

Why even swap the kernel out? The Linux kernel supports more hardware and has better stock performance then the FreeBSD kernel. In fact most friends I have that use FreeBSD are snotty to Linux users anyway. I say give them there OS and it's sorry performance (at least I've never seen anything comparable) and I'll stick with my stage 1 Gentoo which is fast, optimized and ready to go.

Sorry if this offends any FreeBSD user as that's not my point but I've installed it a ton of times to try it out and I'm still waiting for an install that lets me say "Woah" from the get go. Sure you can optimize after the fact but that's not the point, fast out of the box, faster after the tweak! that's what I want and FreeBSD has never given that to me .

If your a FreeBSD user great and if you a Linux user great, but lets not mix the two please!

Re:Question? (2, Interesting)

RAMMS+EIN (578166) | more than 4 years ago | (#30840474)

``Why even swap the kernel out?''

It's good to have choices. Even if Linux is the best choice for you today, you can never know that it will be the best choice for you forever. Providing Debian GNU/kFreeBSD not only offers Debian users the option of using the FreeBSD kernel instead of Linux, but also offers FreeBSD users a way to use the GNU userland instead of FreeBSD's.

Moreover, in making different kernels and userlands work together, areas where this is problematic are identified and improved, so that other projects besides Debian can benefit, too.

The end result is that you gain more options to mix and match parts to build the system exactly the way you want it.

``I'll stick with my stage 1 Gentoo which is fast, optimized and ready to go.''

And you still have that option, too, of course.

Re:Question? (2, Insightful)

IMightB (533307) | more than 4 years ago | (#30840544)

I'm a Linux fan, but there's a first. A linux user complaining that he needs to tweak the OS to get the most out of it!

Here's a tip, ALL OS's require tweaking to get the most out of them.

This is a good thing (3, Insightful)

PhrstBrn (751463) | more than 4 years ago | (#30840410)

I can see a really good usage case for this.

You're a sysadmin, and you're running Debian almost exclusively. You have a large number of automation scripts that you use to do your job (security updates, auditing, provisioning, general maintenance, etc). All of them are expecting to run on Debian, because all you run is Debian. So you, as a sysadmin, decide you want to use ZFS somewhere.

You have a few options:

1) Run Solaris
2) Run some derivative of BSD (FreeBSD, OpenBSD, NetBSD, etc)
3) Run Debian w/ ZFS in Fuse
4) Run Debian kFreeBSD

Options 1 and 2 will most likely require you to tweak or rewrite a lot of your scripts. I shouldn't need to explain why option 3 is a bad idea. Since you're working with Debian userland, going with option 4 seems like it would be the path of least resistance. Seems pretty useful.

Re:This is a good thing (0)

Anonymous Coward | more than 4 years ago | (#30840800)

ah, but you forget about nexenta

Other Interesting Benchmarks (2, Interesting)

RAMMS+EIN (578166) | more than 4 years ago | (#30840604)

It would also be interesting to see benchmarks of functionality actually provided by the respective kernels. E.g. performance of fork, fork+exec, socket, accept, reads and writes on IPC, multiprocessor/multicore/hyperthreading performance, etc. Past benchmarks have shown that there can be dramatic differences between operating systems especially when large numbers of something (processes, filehandles, CPUs, etc.) are being used simultaneously.

Also, I am missing a description of exactly how they measured. Did they recompile the benchmark suite from scratch on each platform? Which compiler was used, and with which settings? Are they running the same binaries on both? How exactly did they arrive at the presented values? Is each bar the result of a single run, or did they run each benchmark multiple times and account for any variation in observed scores somehow?

As others have already mentioned, it would also be interesting to see how a regular FreeBSD system would fare.

All in all, interesting benchmarks. My conclusion: there isn't that much of a difference between the tested versions of Linux and kFreeBSD in there benchmarks. The difference between 32-bit and 64-bit is usually more pronounced. If you need the highest performance for your application, you'll still have to run your own tests.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...