Over the last twenty years, periodically, a new technology comes out which is to "bring the end of SQL" - or at least offer a serious competitor. Early adopters start new projects or even migrate away from SQL to their new data store messiah. One to five years later, most everyone quietly migrates back to SQL. When asked, they quietly admit they were an idiot following fad.
Furthermore, EVERYONE I've spoken with who have considered a NoSQL based solution clearly don't even understand what they are giving up in exchange for their new found features. Meaning, everyone I've spoken with, which frankly isn't many, looks fully equipped to be migrating back to SQL in the next one to five years.
At this point, there is absolutely no evidence we're not looking at yet another group of idiots following the latest anti-SQL fad. Not one bit. None. Nadda. To be clear, there absolutely are cases where NoSQL technology has its place. SQL is not perfect and does not adequately cover every use case well. But the vast, vast, vast majority of people will absolutely be better off with a SQL based solution rather than following the latest, cyclic fad. And frankly, most people are not even remotely qualified to be making such decisions based on technological merit; which only adds to the pool for future migrations, who will likely blame everything but themselves.
Schedulers are extremely complex. Changing priorities can have very surprising and often, completely undesirable side effects, including things like
Simply changing priorities of processes without understanding their impact is not something the average Joe should be doing. Likewise, chances are assumptions which would be made by, "reasonable priorities", are almost certain to be wrong for a large number of users and their workloads. And in fact, would be far, far worse than the current situation with the existing, implementations.
Actually, its well known some types of food contaminations can create gases within its storage vessel. Cans are well known to bloat and distort in shape. If its a glass container it can burst or "explode" fairly forcefully since it can't give until critical failure. Handling such a container is likely to encourage structural failure if its already near the breaking point.
If the guy is simply not attempting to commit fraud with his claim, its very likely the food was contaminated with something. If so, its possible the exploding container saved his life.
So you could have got the exact same performance improvement in this test by doing
"nice make -j64 whatever"
No!
That would lower the priority but you would still have 64 jobs, plus everything else that was already running, all receiving their equal share of scheduling; well, these with a lessor priority. That's not the same thing as what the patch/scripts do.
Couldn't agree more! I can't begin to tell you how much data I've lost with VSS. The worst thing is, you typically don't know or understand how completely boned you are until you actually attempt to check out your source.
Users who willingly use VSS have likely experienced some sort of de-evolution. I wouldn't be surprised if their knuckles actually drag the ground.
Statement 1: The ONLY reasonable explanation is that they are cheating. Or there is an optimisation bug which screws performance.
Dumb statement since that was already addressed. If placing a null op completely destroyed performance, they would be completely unable to perform - ever. If placing an unused variable completely destroyed performance, they would be completely unable to perform ever. Both of which completely ignore that both of these optimizations are some of the most basic and most obvious which ever get coded. Which brings us full circle. The ONLY likely explanation is they are cheating. Period.
Its so frustrating when people who have absolutely no idea what they are talking about attempt to dispute something based on the fact they have absolutely no idea what they are talking about. Defacto on slashdot these days...
Everyone uses because it is a fairly objective benchmark.
For the record, I caught wind of this a month or two ago and posted it here in a firefox performance article. I was trolled and troll moderated despite pointing to the Mozilla team's own experiments.
The ONLY reasonable explanation, assuming you actually understand the implications of what is it you're (generalized readers, not your specifically) reading, which based on previous happenings is questionable, is that Microsoft is cheating their asses off by identifying the exact benchmark and returning a pre-computed value. Either that, or this is indicative of a horrible optimization bug which would negatively effect all javascript in their browser and it would be impossible for them to be competitive in the least. Given there is no evidence to support the later, the only reasonable conclusion is they are cheating their asses off in these benchmarks.
And none of that reflects reality. There is also a lot of surround threads which properly light the scene. My depiction is spot on accurate.
He choose CFS over SD because SD behaviour was inconstant among users' computers
That's why people claim bullshit because CFS was even worse. He was hypocritical. Everyone knows this.
Con would argue with people sending him problems rather then accept them as problems with his code
Yes and no. That's not entirely true. Con would "argue" with people to explain what it was they saw. Scheduling is very complex. When people saw a result which differed from their expectations, they cried error. Some were legitimate. Most were not. Some were biased for server genre. The "legitimate" complaints were always addressed AFAIK.
Linus didn't want code in the kernel that would only work well for certain users
And yet he choose the option which created the largest deviation - which was his own option - CFS. Hypocritical to say the least.
Linus didn't want code maintained by someone that was so hostile to others' critique
This is the gruff skill set to which I spoke. But people ignore that he was full of bullshit. Con has YEARS of proof to show that Linus was completely full of shit in this regard.
Linus states that he believes the desktop is an important platform
Of course it is - until it demands a compromise to the detriment of server performance - which he's endlessly on record more or less saying.
So basically, your representation does not accurately reflect the situation in the least and shows no ability to read between the lines or any knowledge of context outside of the thread in question.
You make it sound like its the only game in town. Its not. For your typical Mom, CFS works fairly well too. Generally speaking, most people are not multi-taskers. As such, CFS work great for them too.
Besides, its widely believed that Linux desktops have been terribly under represented. Some estimates actually place it on par with Apple desktops. Aside from that, its server presence is massive. Linux has clearly caught on with the masses. The hair splitting allowed is where the actual desktop numbers lay. Are they closer to the general estimates everyone knows are wrong and too low or are they actually on par with Apple?
You are conflating several issues. They made a conscious decision to favor server throughput and to allow for scalability. Like it or not, desktop use is a minority use case for Linux. As such, it makes absolute sense to favor your target audience. Realistically, making the "right" decision is almost always the right decision. The real problem isn't that they desired high throughput in the CFS scheduler. The problem is, they decided to give throughput consideration to obscure server workloads over and above those of typical desktop workloads. Again, not hard to figure out why.
The problem with BFS is that is really scales okay to about four CPUs but has a lot of inefficiency to show for it. Things start falling off pretty quickly afterwards. By the time you hit 16 cores, you've reached all but a wall. At least, that was the result from the last benchmarks I've seen.
If I say "switch windows now" and I have to wait a quarter second, there's a problem with the software
But that doesn't necessarily mean someone made a poor choice. That simply means someone made a choice which favors different priorities. Besides, we already know the existing Linux scheduler can be improved. This story is one such example.
Lastly, at the end of the day, don't forget that scheduling is an extremely complex subject in which objective merits must always been considered; usually to the detriment of another consideration. The difficulty is finding a balance which covers the entire spectrum of user experience. To wit, we all know CFS does not currently provide.
Ouch. Your experience surprises me. I would have thought BFS would be a great option for an older, single core box, seemingly being used for classic desktop-user activities.
Its been fairly well documented as to what happened. Linus is an egotist; as are many smart people, including others on the LKML. It seems Con has a fair ego himself with somewhat gruff interpersonal skills. The combination put him at odds with a lot of people. Generally speaking, people with large egos, don't like others who know more than they do, especially when its their pet project. Furthermore, Linus already had some people he trusted, who also had their ego's hurt by Con's work.
So the line was drawn. Linus and his trusted lieutenants on one side and Con on the other. Linus with his lieutenants, all with hurt egos from a slightly abrasive developer who clearly understood the problem domain better than all of them, simply decided he preferred his pride and undue ego over that of Con's potential contributions.
Not surprisingly, this type stuff happens ALL THE TIME amongst developers. I can't tell you how many times I've seen personal pride and ego take priority over extremely well documented and well understood solutions. Not to mention, frequently, the same documentation which explains why its a good decision, also explains why the decision of pride is an incredibly bad decision; with a long history of being very dumb. Despite that, egos frequently rule the day. So its hardly surprising that Linus isn't immune.
BFS makes the classic trade offs which Linus and almost all others absolutely agree is a bad decision for core inclusion. BFS trades performance for latency. Basically you get really good interactive performance in exchange for massively losses in over all throughput and efficiency. Furthermore, BFS sits on a horribly slippery slope in that the level of *inefficiency* scales wonderfully with core count. Basically, the more cores you add, the more time BFS spends BF*cking around.
Basically BFS only makes sense on single or dual core systems which will primarily be used as a desktop. After that, it better be a dedicated desktop system because compared to the stock kernel, performance is going to royally suck, despite latency being fairly good. But then again, BFS was never really designed to address scalability - its always focused on latency and a superior interactive desktop experience. By most measures it works, but at a heavy cost.
Fair enough. My emphasis was primarily addressing the fact that a language on top of JVM does not in of itself imply java-like speeds. In fact, its scary easy to wind up with solutions which are sadly, extremely slow. Furthermore, some languages are just not a good for for the JVM, and as such, will always have some degree of overhead above what may be possible with other VMs.
Its been a while since I last looked at ruby performance, so some of my information is likely aged at this point. I appreciate you getting me currently.
jruby is faster than ruby because they seemingly have a good team working on optimizing their implementation. In fact, optimization has been their primary focus behind the jruby implementation. Python, on the other hand, has far more language features. Also, I don't know if there is a difference between team sizes and/or man-hour contributions. Regardless, the jython guys spend considerable time just creating language coverage so time for optimization appears to be almost nil. As a result, on average, last I've seen, jruby (though some corner cases clearly place jruby far ahead) is on par with cpython and jython is ridiculously slow.
Basically, simply targeting the JVM is not a silver bullet for performance. It likely doesn't help that idioms commonly used in the python byte code frequently don't translate well to the JVM. Not to mention, jython doesn't have a GIL, so I have no idea what their locking overhead incurs on generalized performance. These are of course, reasons why many languages ignore the JVM for their VM - because the VM is not generalized and is frequently an extremely poor target for some languages.
This is something most people don't seem to really understand. Jython is roughly 2-4x slower than cpython. That means to truly be better off with jython, on average, you need to have at least four cores, and possibly five or more, continuously maxed out on CPU bound tasks to even beat cpython, let alone java + hotspot. And all that ignores using something like cython or psyco plus the traditional cpython.
Long story short, jython is an idiots choice unless the goal is to strictly expose a scripting language in a java application. Outside of that, jython has absolutely no value to anyone.
Nope. Not at all. Some of the frameworks, such as TurboGears, have not been around that long. Which means, antiquated distributions such as RHEL, require much more tedious support and frankly, are a huge pain in the ass - which is a constantly recurring issue with RHEL, in that almost nothing is modern about it - until now. Which means, unless you ONLY plan on running something like Apache, chances as your ass is going to be rubbed raw with RHEL - until recently.
There is a huge difference between distribution stability and antiquity. The problem has largely been with RHEL; first and foremost.
I read elsewhere that TurboGears was progressively included this time around. For those that don't know, TG is the software powering the new front end for Source Forge, among many other sites. This is worth mentioning because as other comments will indicate, RHEL is notorious for containing nothing new or relevant for modern development and frequently lags many, many years behind modern distributions. The fact RHEL includes a powerful, modern, and highly scalable web framework is certainly good news.
Hopefully this is the beginning of a new trend for RHEL to remain relevant for modern web infrastructure.
Power is torque. HP is work. You can have a more "powerful" engine despite having less peak HP. That's entirely why diesels are popular for work trucks. But frankly, "powerful" is a highly subjective claim anyways.
Read my other replies in this thread to become enlightened.
You're conflating several items and are completely wrong. Read my other reply in this read. You're also conflating peak HP/torque with a usable torque/HP band.
Torque isn't abstract enough for valid comparisons.
And frankly, that statement is just dumb. Hp is an abstract and so much so, its useless for comparison of different engines (read original context - which you dumped). Furthermore, HP is a function of torque. So if you know the torque and its curve, you know the HP.
Furthermore, the biggest problem with citing HP numbers is you are citing peak. Peak is almost always an absolutely useless number. Furthermore, if speed is important, the shift point is typically far short of peak HP numbers - somewhere between peak torque and peak HP.
Furthermore, quoting HP has completely different meaning when talking about two completely different engine technologies (example, large displacement, low RPM vs small displacement, high RPM); plus everything in between. Plus, without a torque curve, you have absolutely no idea how long it took to build the associated RPM. So if it takes you 30-seconds to reach peak HP, the race is lost. Likewise, HP numbers say nothing of everything else which makes a car a car (traction, gearing, transmission, shit points, etc).
Basically, anyone who believes HP numbers are a good basis of comparison (for different engines - as stated in original context) prove themselves to be completely ignorant of the topic at hand.
Torque is the useful metric. Furthermore, as HP is directly derived from torque. So if you know the torque curve, you know the HP curve. Regardless, neither provide much meaning without a corresponding torque curve.
Which is faster? And engine with 100 HP or an engine with 1000000 HP? If you can answer correctly, then you're smarter than the rest of humanity. If you can't answer, then you now understand exactly why HP by it self is a completely useless metric for comparison for laymen.
Basically, anyone who goes around quoting HP numbers, without lots and lots of additional context, are putting themselves out there to be an idiot. Which is, after all, entirely my complaint of religious Car and Driver readers. They read and spew and bunch of crap, but have absolutely no idea what it is they speak about.
Slashdot Mirror
Over the last twenty years, periodically, a new technology comes out which is to "bring the end of SQL" - or at least offer a serious competitor. Early adopters start new projects or even migrate away from SQL to their new data store messiah. One to five years later, most everyone quietly migrates back to SQL. When asked, they quietly admit they were an idiot following fad.
Furthermore, EVERYONE I've spoken with who have considered a NoSQL based solution clearly don't even understand what they are giving up in exchange for their new found features. Meaning, everyone I've spoken with, which frankly isn't many, looks fully equipped to be migrating back to SQL in the next one to five years.
At this point, there is absolutely no evidence we're not looking at yet another group of idiots following the latest anti-SQL fad. Not one bit. None. Nadda. To be clear, there absolutely are cases where NoSQL technology has its place. SQL is not perfect and does not adequately cover every use case well. But the vast, vast, vast majority of people will absolutely be better off with a SQL based solution rather than following the latest, cyclic fad. And frankly, most people are not even remotely qualified to be making such decisions based on technological merit; which only adds to the pool for future migrations, who will likely blame everything but themselves.
Schedulers are extremely complex. Changing priorities can have very surprising and often, completely undesirable side effects, including things like
Simply changing priorities of processes without understanding their impact is not something the average Joe should be doing. Likewise, chances are assumptions which would be made by, "reasonable priorities", are almost certain to be wrong for a large number of users and their workloads. And in fact, would be far, far worse than the current situation with the existing, implementations.
Actually, its well known some types of food contaminations can create gases within its storage vessel. Cans are well known to bloat and distort in shape. If its a glass container it can burst or "explode" fairly forcefully since it can't give until critical failure. Handling such a container is likely to encourage structural failure if its already near the breaking point.
If the guy is simply not attempting to commit fraud with his claim, its very likely the food was contaminated with something. If so, its possible the exploding container saved his life.
So you could have got the exact same performance improvement in this test by doing
"nice make -j64 whatever"
No!
That would lower the priority but you would still have 64 jobs, plus everything else that was already running, all receiving their equal share of scheduling; well, these with a lessor priority. That's not the same thing as what the patch/scripts do.
Under most common workloads, hyperthreading actually costs 20%-30%. The majority of users should have hyperthreading disabled.
They were cities built with stone. They've found pottery and stone-work tools. Its probably safe to say they were intended to be fairly permanent.
That's not really true. The number of port cities that have sunk below sea level is quite small, even over the span of thousands of years.
I recently saw a show on History channel that said just in the Mediterranean alone, several hundred cities lay under the waves now.
Imagine an entire city needing a new hull as the passage of time and storms takes their toll.
The engineers specifically state the intended usable life is 100-years; which matches that of current construction concrete.
Couldn't agree more! I can't begin to tell you how much data I've lost with VSS. The worst thing is, you typically don't know or understand how completely boned you are until you actually attempt to check out your source.
Users who willingly use VSS have likely experienced some sort of de-evolution. I wouldn't be surprised if their knuckles actually drag the ground.
Statement 1: The ONLY reasonable explanation is that they are cheating. Or there is an optimisation bug which screws performance.
Dumb statement since that was already addressed. If placing a null op completely destroyed performance, they would be completely unable to perform - ever. If placing an unused variable completely destroyed performance, they would be completely unable to perform ever. Both of which completely ignore that both of these optimizations are some of the most basic and most obvious which ever get coded. Which brings us full circle. The ONLY likely explanation is they are cheating. Period.
Its so frustrating when people who have absolutely no idea what they are talking about attempt to dispute something based on the fact they have absolutely no idea what they are talking about. Defacto on slashdot these days...
Everyone uses because it is a fairly objective benchmark.
For the record, I caught wind of this a month or two ago and posted it here in a firefox performance article. I was trolled and troll moderated despite pointing to the Mozilla team's own experiments.
The ONLY reasonable explanation, assuming you actually understand the implications of what is it you're (generalized readers, not your specifically) reading, which based on previous happenings is questionable, is that Microsoft is cheating their asses off by identifying the exact benchmark and returning a pre-computed value. Either that, or this is indicative of a horrible optimization bug which would negatively effect all javascript in their browser and it would be impossible for them to be competitive in the least. Given there is no evidence to support the later, the only reasonable conclusion is they are cheating their asses off in these benchmarks.
And none of that reflects reality. There is also a lot of surround threads which properly light the scene. My depiction is spot on accurate.
He choose CFS over SD because SD behaviour was inconstant among users' computers
That's why people claim bullshit because CFS was even worse. He was hypocritical. Everyone knows this.
Con would argue with people sending him problems rather then accept them as problems with his code
Yes and no. That's not entirely true. Con would "argue" with people to explain what it was they saw. Scheduling is very complex. When people saw a result which differed from their expectations, they cried error. Some were legitimate. Most were not. Some were biased for server genre. The "legitimate" complaints were always addressed AFAIK.
Linus didn't want code in the kernel that would only work well for certain users
And yet he choose the option which created the largest deviation - which was his own option - CFS. Hypocritical to say the least.
Linus didn't want code maintained by someone that was so hostile to others' critique
This is the gruff skill set to which I spoke. But people ignore that he was full of bullshit. Con has YEARS of proof to show that Linus was completely full of shit in this regard.
Linus states that he believes the desktop is an important platform
Of course it is - until it demands a compromise to the detriment of server performance - which he's endlessly on record more or less saying.
So basically, your representation does not accurately reflect the situation in the least and shows no ability to read between the lines or any knowledge of context outside of the thread in question.
You make it sound like its the only game in town. Its not. For your typical Mom, CFS works fairly well too. Generally speaking, most people are not multi-taskers. As such, CFS work great for them too.
Besides, its widely believed that Linux desktops have been terribly under represented. Some estimates actually place it on par with Apple desktops. Aside from that, its server presence is massive. Linux has clearly caught on with the masses. The hair splitting allowed is where the actual desktop numbers lay. Are they closer to the general estimates everyone knows are wrong and too low or are they actually on par with Apple?
This has nothing to do with open vs closed. This happens all the time in the corporate world. It has to do with simply being human.
This is typical for a "computer scientist".
You are conflating several issues. They made a conscious decision to favor server throughput and to allow for scalability. Like it or not, desktop use is a minority use case for Linux. As such, it makes absolute sense to favor your target audience. Realistically, making the "right" decision is almost always the right decision. The real problem isn't that they desired high throughput in the CFS scheduler. The problem is, they decided to give throughput consideration to obscure server workloads over and above those of typical desktop workloads. Again, not hard to figure out why.
The problem with BFS is that is really scales okay to about four CPUs but has a lot of inefficiency to show for it. Things start falling off pretty quickly afterwards. By the time you hit 16 cores, you've reached all but a wall. At least, that was the result from the last benchmarks I've seen.
If I say "switch windows now" and I have to wait a quarter second, there's a problem with the software
But that doesn't necessarily mean someone made a poor choice. That simply means someone made a choice which favors different priorities. Besides, we already know the existing Linux scheduler can be improved. This story is one such example.
Lastly, at the end of the day, don't forget that scheduling is an extremely complex subject in which objective merits must always been considered; usually to the detriment of another consideration. The difficulty is finding a balance which covers the entire spectrum of user experience. To wit, we all know CFS does not currently provide.
Ouch. Your experience surprises me. I would have thought BFS would be a great option for an older, single core box, seemingly being used for classic desktop-user activities.
Its been fairly well documented as to what happened. Linus is an egotist; as are many smart people, including others on the LKML. It seems Con has a fair ego himself with somewhat gruff interpersonal skills. The combination put him at odds with a lot of people. Generally speaking, people with large egos, don't like others who know more than they do, especially when its their pet project. Furthermore, Linus already had some people he trusted, who also had their ego's hurt by Con's work.
So the line was drawn. Linus and his trusted lieutenants on one side and Con on the other. Linus with his lieutenants, all with hurt egos from a slightly abrasive developer who clearly understood the problem domain better than all of them, simply decided he preferred his pride and undue ego over that of Con's potential contributions.
Not surprisingly, this type stuff happens ALL THE TIME amongst developers. I can't tell you how many times I've seen personal pride and ego take priority over extremely well documented and well understood solutions. Not to mention, frequently, the same documentation which explains why its a good decision, also explains why the decision of pride is an incredibly bad decision; with a long history of being very dumb. Despite that, egos frequently rule the day. So its hardly surprising that Linus isn't immune.
BFS makes the classic trade offs which Linus and almost all others absolutely agree is a bad decision for core inclusion. BFS trades performance for latency. Basically you get really good interactive performance in exchange for massively losses in over all throughput and efficiency. Furthermore, BFS sits on a horribly slippery slope in that the level of *inefficiency* scales wonderfully with core count. Basically, the more cores you add, the more time BFS spends BF*cking around.
Basically BFS only makes sense on single or dual core systems which will primarily be used as a desktop. After that, it better be a dedicated desktop system because compared to the stock kernel, performance is going to royally suck, despite latency being fairly good. But then again, BFS was never really designed to address scalability - its always focused on latency and a superior interactive desktop experience. By most measures it works, but at a heavy cost.
Fair enough. My emphasis was primarily addressing the fact that a language on top of JVM does not in of itself imply java-like speeds. In fact, its scary easy to wind up with solutions which are sadly, extremely slow. Furthermore, some languages are just not a good for for the JVM, and as such, will always have some degree of overhead above what may be possible with other VMs.
Its been a while since I last looked at ruby performance, so some of my information is likely aged at this point. I appreciate you getting me currently.
jruby is faster than ruby because they seemingly have a good team working on optimizing their implementation. In fact, optimization has been their primary focus behind the jruby implementation. Python, on the other hand, has far more language features. Also, I don't know if there is a difference between team sizes and/or man-hour contributions. Regardless, the jython guys spend considerable time just creating language coverage so time for optimization appears to be almost nil. As a result, on average, last I've seen, jruby (though some corner cases clearly place jruby far ahead) is on par with cpython and jython is ridiculously slow.
Basically, simply targeting the JVM is not a silver bullet for performance. It likely doesn't help that idioms commonly used in the python byte code frequently don't translate well to the JVM. Not to mention, jython doesn't have a GIL, so I have no idea what their locking overhead incurs on generalized performance. These are of course, reasons why many languages ignore the JVM for their VM - because the VM is not generalized and is frequently an extremely poor target for some languages.
This is something most people don't seem to really understand. Jython is roughly 2-4x slower than cpython. That means to truly be better off with jython, on average, you need to have at least four cores, and possibly five or more, continuously maxed out on CPU bound tasks to even beat cpython, let alone java + hotspot. And all that ignores using something like cython or psyco plus the traditional cpython.
Long story short, jython is an idiots choice unless the goal is to strictly expose a scripting language in a java application. Outside of that, jython has absolutely no value to anyone.
Nope. Not at all. Some of the frameworks, such as TurboGears, have not been around that long. Which means, antiquated distributions such as RHEL, require much more tedious support and frankly, are a huge pain in the ass - which is a constantly recurring issue with RHEL, in that almost nothing is modern about it - until now. Which means, unless you ONLY plan on running something like Apache, chances as your ass is going to be rubbed raw with RHEL - until recently.
There is a huge difference between distribution stability and antiquity. The problem has largely been with RHEL; first and foremost.
I read elsewhere that TurboGears was progressively included this time around. For those that don't know, TG is the software powering the new front end for Source Forge, among many other sites. This is worth mentioning because as other comments will indicate, RHEL is notorious for containing nothing new or relevant for modern development and frequently lags many, many years behind modern distributions. The fact RHEL includes a powerful, modern, and highly scalable web framework is certainly good news.
Hopefully this is the beginning of a new trend for RHEL to remain relevant for modern web infrastructure.
Power is torque. HP is work. You can have a more "powerful" engine despite having less peak HP. That's entirely why diesels are popular for work trucks. But frankly, "powerful" is a highly subjective claim anyways.
Read my other replies in this thread to become enlightened.
You're conflating several items and are completely wrong. Read my other reply in this read. You're also conflating peak HP/torque with a usable torque/HP band.
Torque isn't abstract enough for valid comparisons.
And frankly, that statement is just dumb. Hp is an abstract and so much so, its useless for comparison of different engines (read original context - which you dumped). Furthermore, HP is a function of torque. So if you know the torque and its curve, you know the HP.
Furthermore, the biggest problem with citing HP numbers is you are citing peak. Peak is almost always an absolutely useless number. Furthermore, if speed is important, the shift point is typically far short of peak HP numbers - somewhere between peak torque and peak HP.
Furthermore, quoting HP has completely different meaning when talking about two completely different engine technologies (example, large displacement, low RPM vs small displacement, high RPM); plus everything in between. Plus, without a torque curve, you have absolutely no idea how long it took to build the associated RPM. So if it takes you 30-seconds to reach peak HP, the race is lost. Likewise, HP numbers say nothing of everything else which makes a car a car (traction, gearing, transmission, shit points, etc).
Basically, anyone who believes HP numbers are a good basis of comparison (for different engines - as stated in original context) prove themselves to be completely ignorant of the topic at hand.
Absolutely wrong!
Torque is the useful metric. Furthermore, as HP is directly derived from torque. So if you know the torque curve, you know the HP curve. Regardless, neither provide much meaning without a corresponding torque curve.
Which is faster? And engine with 100 HP or an engine with 1000000 HP? If you can answer correctly, then you're smarter than the rest of humanity. If you can't answer, then you now understand exactly why HP by it self is a completely useless metric for comparison for laymen.
Basically, anyone who goes around quoting HP numbers, without lots and lots of additional context, are putting themselves out there to be an idiot. Which is, after all, entirely my complaint of religious Car and Driver readers. They read and spew and bunch of crap, but have absolutely no idea what it is they speak about.