I blame the people for electing politicians that are essentially open for sale.
Given a high enough concentration of wealth at the top, an increasingly expensive political process, and a tame corporate media that would otherwise be the only effective watchdog against shenanigans, all politicians are now open for sale.
If the choice is only between 'bad' and 'worse', one shouldn't expect 'good' to be the result.
would you happen to know anyone who would trade salt or yeast for squirrel pelts?
Nice rant you got there AC, there's just one problem: the GP wasn't bitching about paper money, he's complaining about the insanity that is the modern stock & bond markets.
Fact #1: Whenever someone's harkening back to the good old days it's never as good as they imagine.
Now thats true enough.
the economic landscape is formed by legislators who are usually lawyers
No, the problem is that legislators are usually available for purchase to the highest bidder. Unfortunately, the "winners" from the crazy roulette wheel of the stock/bond markets are always the ones who can bid the highest.
was that the future price of the oil sitting in the ground went up massively
No, and the GP is wrong too.
The important thing to remember about the oil "market" is that its a "futures" market, driven by medium to long term *speculation* going 6 months to a year out or beyond. Its driven (now) primarily by *fear*, because the market isn't just focused on crude oil, but the refined products derived from it (gasoline/heating oil), and there is a growing problem with both the supply of crude oil, and refinery capacity.
Anything that impacts the flow of oil or the flow coming out of the world's refineries will cause jitters in the oil market. This is mainly because the supply/demand ratio was extremely tight just before the global recession, the world was very near to consuming it faster than it could pump it out of the ground and refine it (some countries also have tight refining capacity - like the US).
The recession took a lot of the pressure off, but despite the world not having recovered yet from the recession, oil is creeping back up. Why? Because, as soon as the world economy gets rolling again, we'll hit the Peak Oil wall head-on, where consumption begins to consistently out-pace supply... and the oil traders *know* this is coming, thats why they're perpetually nervous about any kind of disruption to global oil supply.
Before the recession, we were on the way to $200 a barrel oil, even though the supply was still (somewhat) ahead of demand. The reason the price was escalating then was because the oil traders saw what was coming - they were looking a year or so into the future and saw the shadow of that wall looming...
Yea, I had a feeling what you were talking about was either in asm work itself, or most likely an optimization done *within* some kind of compiler or special-purpose context.
If I had looked at the posts below yours before responding to yours, I would have realised you weren't the only one to go "offtopic", strictly speaking. Had I noticed you weren't the only one to start drifting, I probably wouldn't have bothered to say anything.
My comment was really aimed at readers like the OP, so they knew this was not generally what they should be trying to do for general-purpose programming work, especially newcomers to programming like the OP, i.e., get the basics down first before worrying about optimizing.
Frankly, from the journalistic point of view, I don't see what's the point of talking about the "Digital Hadron Calorimeter" at the beginning of the news
Wait, did you just make a reference to journalism and/. in the same sentence?
A1: You'll *need* string theory just to get those two things together in one sentence without creating a miniature black hole that swallows the Earth, or
How do you know? It seems entirely plausible to me that significantly better compiler optimization could reduce the level of manual optimization needed for embedded systems, and thus reduce the time-to-market.
The *summary* is bollocks because it doesn't mention the "embedded" part, nor does it mention that this is app seems to be really for the compiler *authors* not the compiler *users*. This is from their PDF doc:
Using MILEPOST GCC, after a few weeks training, we were able to learn a model that automatically improves the execution time of MiBench benchmark by 11% demonstrating the use of our machine learning based compiler.
A few WEEKS of training!?!?
More than likely, this could be used by the GCC folks to figure out the best default set of opts for a given -Ox level on a given arch by running it over some representative set of real-world code to find the best set of opts.
However, I share the GP's skepticism on this: Doesn't this depend an awful lot on the code you use for the "training"? If you fed it a *lot* of real-world code for the "training" (and waited a few weeks!) wouldn't it end up giving a very conservative set of opts for that arch (to handle the complexity and corner-cases in real-world code), which is basically what we have now?
And since I doubt most people will be willing/able to dedicate their machine for compiling and recompiling something for a week to just find optimal opt flags that will only give an average 10% boost if they're lucky, I suspect this won't get used by desktop compiler "users", which is something else the summary didn't to bother to mention... [must... resist... Gentoo(1) Ricer joke... here...]
Yes, it'll probably help us all in the end (maybe), but the GP is still right, this article's summary is an EPIC FAIL.
(1) Yes, I am a Gentoo user:), but I'll be damned if I'm going to compile anything for a week or more for just a 10% improvement.
If I use a movl to copy the value into a second register
At which point we're talking about inline assembly at least, not a "simple" in-compiled-language optimization, e.g. C mul expr -> C shift/add expr, which is what the entire preceding thread has been talking about. And if you're talking about writing code in assembly, that also has no place in a thread about *compiler* optimizations.:)
Never mind that you're now using another register, which depending on the specific circumstances, may be a bad thing, e.g. the compiler might find a better use for that register than your use of it as a temp, and this is especially true on the x86 arch with its relative paucity of GP regs.
See, this is an example (an optimization that might have an unintended regression by using a valuable GP reg - preventing the compiler from optimizing your code in an even better way) of why it usually just a good idea nowadays to leave out this kind of low-level optimization.
Modern compilers, and the geeks/gurus that write them, *generally* know your hardware better than you do. Hardwiring opts like this into your source now generally means that either the compiler can't do the same thing itself, or it prevents the compiler from doing some other opt that would be even more useful.
Just write code that uses the "right" algorithms, is maintainable, easy to grok, and leave optimizations like this to the compiler. Oh, and remember folks: Premature Optimization Is The Root Of All Evil.:)
Frankly, I don't even understand what point you're trying to make.
Subjective truth is subjective, and "more bits is always better" is a subjective truth.
No one is arguing about the "more bits" part, what I'm arguing about is the "is always better" part. That part depends not only on each individual's own sensory system (we all don't see/hear exactly the same way!), but our own values, desires, and preferences. Those things are inheriently subjective.
I'm not debating whether or not you can see the difference. Honestly, I don't care that you can't
As long as you don't care about the difference between empirical truth ("more bits") and subjective truth ("is always better"), then you'll never understand why something can be true for you, yet false for someone else.
And until you and the other BD fans grok that distinction, you'll never understand why BD hasn't gone anywhere in the market, and in its present form, probably never will.
Sure, maybe that's not enough to make it appealing to you, but that's no reason to act like it's not true.
What's the difference between MP3-320k and FLAC for me? ABSOLUTELY NOTHING. Don't show me the bits, I don't give a damn, my ears say there IS NO DIFFERENCE.
It is *your* implicit assumption of "better quality due to more bits" that is in fact the problem here, because for many people like me and Draek, that assumption is utterly FALSE.
Think about it: are you really wanting to claim that all a painter has to do to make a better painting is to throw more paint on the canvas? More paint *always* means a better painting?!?
Jeez, will all you BD shills please, PLEASE, repeat after me:
Please, just read at -1. Slashdot moderation is completely broken anyway,
Not as badly broken as trying to read a website with 8-12+ threads a day, with each one usually well over a hundred comments. Never mind the absurd 800 comment monsters (gave up on politics./. a *long* time ago).
Your advice worked in the good 'ole days of/. when we were a smaller and *relatively* more well-behaved group... but no more.
Filter at +1 or higher, and kill the ACs, your sanity will thank you.
The most important GPL software in Mac OS X is arguably the GNU compiler, gcc.
Not anymore. GCC on Apple is a Dead Man Walking, because Apple won't work with the GPLv3, which the FSF's GCC project has already upgraded to.
Apple is a major contributor to the LLVM project
Of course, because this is what they intend to replace GCC with, and when this happens GCC-on-Apple and ObjC-in-GCC both go into a slow death spiral. Apple has already ceased providing any significant patches to the FSF GCC project. For example, GCC still doesn't support ObjC v2, two years after its release. There just doesn't appear to be enough developer interest outside of Apple to keep FSF GCC updated.
Apple's implementation of the Cocoa Framework is not an open source framework, but it is based on an open specification, although it has evolved past the specification.
If it has evolved *past* an open specification, and is not open source, then its not open... anything. So your point is?
There is an alternative, open source implementation
there is no hope of GNUstep guaranteeing that we shall maintain compatibility with an Apple API that is constantly changing
Cocoa is full-on, closed-source, proprietary... full-stop. GNUSTEP would have the same problem Mono has (always playing catchup to MS's changes), only worse: they can't even look at the code. So they don't even try. Ergo:
So what if corporations are just using FOSS to get what they want? Isn't that what we wanted in the first place when FOSS was invented? It doesn't matter how it is used, just so long as everyone has access to the source.
+1 Common Sense
And as long as the corps end up making the software *better*, than no one should really care one whit whether a project has corp help or not, its irrelevent.
But hey, this is/., the kids didn't come here to read common sensical stuff, they want to see blood on the floor.:)
One thing neither FOSS or Microsoft can fix is difficulty in aligning hardware and software designs when both are moving targets and only one is in your control
To some, handing control over *both* aspects to one company is not a "fix", its just twice as bad a mistake as giving one company absolute control over one of them.
Giving one company control over both the hardware and software does only one fundamental thing: it gives them more *control*. That's ALL. They can do positive things with that extra control, but as we all know from the history of personal computers, companies can also do very *negative* things with that enhanced control.
FWIW, I don't think this is really the best line of argument (giving the Overlord 2X the control is 2X *better*) that you should be trying to use in a thread thats ostensibly about FOSS.:)
They are also built on a rock-solid UNIX foundation. Tell me why you need Linux for Open Source.
Because I already *have* hardware? And its *my* hardware, of *my* choosing, and therefore better than Apple's hardware for those subsystems that matter to me?
Seriously, whats the point of your response, really? It would only make sense if you could get Apple's "rock-solid" software for non-Apple hardware.
but I suggest that anyone who doubts this to download Intel's compiler (it's free as in beer) and try it out.
...unless you're running an AMD system, in which case don't bother, because ICC won't show your code nearly as much love as it would for a Genuine-Intel-Inside (or so I've heard)...
At least you must admit that GCC is fair in its handling of its backends: it provides mediocre performance in equal doses.:)
improving performance on its most popular platforms if they want to remain relevant...
You don't understand, GCC's portability is the reason for its very existence. Thats not optional. GCC has got more than 20 backends (architectures) and 8-10 frontends (languages) for goodness sake, no freakin' wonder its a little slower than MSVC/ICC, those latter guys only have to worry about 2 backends (x86/x86_64) and 2 frontends (C/C++).
GCC's wide portability is what currently guaranttees its relevancy. The minute GCC starts chasing clock cycles on the x86 platform (at the expense of the others), that will be its curtain-call...
The real Messiah might have been Dennis Kucinich, and coincidentally he got crucified... both by the DNC *and* voters.
What we *really* need is to get people to stop thinking that only the Presidency makes a difference. There is no Messiah, its the 60 votes in the Senate that controls all.
you don't get revolution unless a significant part of the population (I'd guess about half) are actively starving, and have nothing left to lose.
Two counter-examples off the top of my head: the American Revolution (no starving masses, yet violent revolution), and North Korea of the last two decades or so (plenty of starving masses, but no violent revolution). I've even heard claims that the reason for the latter example is that starving people are too weak to fight.
Who's right? Don't know myself. Even if your theory is the 'rule', there still appears to be plenty of 'exceptions' to it, or else it, like real life, is a little more complicated and nuanced then we think.
I believe AMD wanted to bring one of the two chipset manufacturers in house so they could have better coupling between their processors and their chipsets.
That's probably part of the reason, but AMD is looking long term, and they see Larrabee on the horizon, so they're also working towards the eventual marriage of the CPU and GPU at some point in the future. In the short term, they're heading towards putting the CPU and GPU on the same die, last I read, they codenamed it 'Fusion'. Just google 'AMD Fusion', you should find references.
Slashdot Mirror
pepsi declined the offer and reported it as a theft of trade secrets
I'll bet it was the recipe for New Coke, so no wonder Pepsi turned it down!
I blame the people for electing politicians that are essentially open for sale.
Given a high enough concentration of wealth at the top, an increasingly expensive political process, and a tame corporate media that would otherwise be the only effective watchdog against shenanigans, all politicians are now open for sale.
If the choice is only between 'bad' and 'worse', one shouldn't expect 'good' to be the result.
would you happen to know anyone who would trade salt or yeast for squirrel pelts?
Nice rant you got there AC, there's just one problem: the GP wasn't bitching about paper money, he's complaining about the insanity that is the modern stock & bond markets.
Fact #1: Whenever someone's harkening back to the good old days it's never as good as they imagine.
Now thats true enough.
the economic landscape is formed by legislators who are usually lawyers
No, the problem is that legislators are usually available for purchase to the highest bidder. Unfortunately, the "winners" from the crazy roulette wheel of the stock/bond markets are always the ones who can bid the highest.
was that the future price of the oil sitting in the ground went up massively
No, and the GP is wrong too.
The important thing to remember about the oil "market" is that its a "futures" market, driven by medium to long term *speculation* going 6 months to a year out or beyond. Its driven (now) primarily by *fear*, because the market isn't just focused on crude oil, but the refined products derived from it (gasoline/heating oil), and there is a growing problem with both the supply of crude oil, and refinery capacity.
Anything that impacts the flow of oil or the flow coming out of the world's refineries will cause jitters in the oil market. This is mainly because the supply/demand ratio was extremely tight just before the global recession, the world was very near to consuming it faster than it could pump it out of the ground and refine it (some countries also have tight refining capacity - like the US).
The recession took a lot of the pressure off, but despite the world not having recovered yet from the recession, oil is creeping back up. Why? Because, as soon as the world economy gets rolling again, we'll hit the Peak Oil wall head-on, where consumption begins to consistently out-pace supply... and the oil traders *know* this is coming, thats why they're perpetually nervous about any kind of disruption to global oil supply.
Before the recession, we were on the way to $200 a barrel oil, even though the supply was still (somewhat) ahead of demand. The reason the price was escalating then was because the oil traders saw what was coming - they were looking a year or so into the future and saw the shadow of that wall looming...
Yea, I had a feeling what you were talking about was either in asm work itself, or most likely an optimization done *within* some kind of compiler or special-purpose context.
If I had looked at the posts below yours before responding to yours, I would have realised you weren't the only one to go "offtopic", strictly speaking. Had I noticed you weren't the only one to start drifting, I probably wouldn't have bothered to say anything.
My comment was really aimed at readers like the OP, so they knew this was not generally what they should be trying to do for general-purpose programming work, especially newcomers to programming like the OP, i.e., get the basics down first before worrying about optimizing.
My bad, carry on. :)
Frankly, from the journalistic point of view, I don't see what's the point of talking about the "Digital Hadron Calorimeter" at the beginning of the news
Wait, did you just make a reference to journalism and /. in the same sentence?
A1: You'll *need* string theory just to get those two things together in one sentence without creating a miniature black hole that swallows the Earth, or
A2: You really *are* new here, aren't you?
I love MS bashing as much as the rest of you, however
Nice way of carefully easing in to a defense of MS on /.! :)
the way I heard it was that it was a network issue.
They initially referred to a "connectivity issue", but they later ruled that out. Their final excuse:
"It was software-related, a coincidence, due to two processes we couldn't have foreseen,"
Note they also explicitly rule out the high-volume traffic as being the problem.
Nice try though, but MS-bashing definitely remains cleared for in-bound landings. :)
No need to consider this any further folks. *This* is why they were prosecuted instead of any other 2bit, small-time, porn house.
Obscene porn is one thing, but in this country, right or wrong, as soon as you mess with Jesus, the knives come out...
And no, this isn't a troll, I live in the Bible Belt, I know...
The summary is complete bollocks.
How do you know? It seems entirely plausible to me that significantly better compiler optimization could reduce the level of manual optimization needed for embedded systems, and thus reduce the time-to-market.
The *summary* is bollocks because it doesn't mention the "embedded" part, nor does it mention that this is app seems to be really for the compiler *authors* not the compiler *users*. This is from their PDF doc:
Using MILEPOST GCC, after a few weeks training, we were able to learn a model that automatically improves the execution time of MiBench benchmark by 11% demonstrating the use of our machine learning based compiler.
A few WEEKS of training!?!?
More than likely, this could be used by the GCC folks to figure out the best default set of opts for a given -Ox level on a given arch by running it over some representative set of real-world code to find the best set of opts.
However, I share the GP's skepticism on this: Doesn't this depend an awful lot on the code you use for the "training"? If you fed it a *lot* of real-world code for the "training" (and waited a few weeks!) wouldn't it end up giving a very conservative set of opts for that arch (to handle the complexity and corner-cases in real-world code), which is basically what we have now?
And since I doubt most people will be willing/able to dedicate their machine for compiling and recompiling something for a week to just find optimal opt flags that will only give an average 10% boost if they're lucky, I suspect this won't get used by desktop compiler "users", which is something else the summary didn't to bother to mention... [must... resist... Gentoo(1) Ricer joke... here...]
Yes, it'll probably help us all in the end (maybe), but the GP is still right, this article's summary is an EPIC FAIL.
(1) Yes, I am a Gentoo user :), but I'll be damned if I'm going to compile anything for a week or more for just a 10% improvement.
Will it fix Crysis and Vangaurd?
So that the games run on a normal machine?
Ah geez man, at least ask for something within the realm of possibility... like a release date for DNF.
If I use a movl to copy the value into a second register
At which point we're talking about inline assembly at least, not a "simple" in-compiled-language optimization, e.g. C mul expr -> C shift/add expr, which is what the entire preceding thread has been talking about. And if you're talking about writing code in assembly, that also has no place in a thread about *compiler* optimizations. :)
Never mind that you're now using another register, which depending on the specific circumstances, may be a bad thing, e.g. the compiler might find a better use for that register than your use of it as a temp, and this is especially true on the x86 arch with its relative paucity of GP regs.
See, this is an example (an optimization that might have an unintended regression by using a valuable GP reg - preventing the compiler from optimizing your code in an even better way) of why it usually just a good idea nowadays to leave out this kind of low-level optimization.
Modern compilers, and the geeks/gurus that write them, *generally* know your hardware better than you do. Hardwiring opts like this into your source now generally means that either the compiler can't do the same thing itself, or it prevents the compiler from doing some other opt that would be even more useful.
Just write code that uses the "right" algorithms, is maintainable, easy to grok, and leave optimizations like this to the compiler. Oh, and remember folks: Premature Optimization Is The Root Of All Evil. :)
+1 dont-read-this-post-while-drinking-from-open-container-funny
Frankly, I don't even understand what point you're trying to make.
Subjective truth is subjective, and "more bits is always better" is a subjective truth.
No one is arguing about the "more bits" part, what I'm arguing about is the "is always better" part. That part depends not only on each individual's own sensory system (we all don't see/hear exactly the same way!), but our own values, desires, and preferences. Those things are inheriently subjective.
I'm not debating whether or not you can see the difference. Honestly, I don't care that you can't
As long as you don't care about the difference between empirical truth ("more bits") and subjective truth ("is always better"), then you'll never understand why something can be true for you, yet false for someone else.
And until you and the other BD fans grok that distinction, you'll never understand why BD hasn't gone anywhere in the market, and in its present form, probably never will.
Sure, maybe that's not enough to make it appealing to you, but that's no reason to act like it's not true.
What's the difference between MP3-320k and FLAC for me? ABSOLUTELY NOTHING. Don't show me the bits, I don't give a damn, my ears say there IS NO DIFFERENCE.
It is *your* implicit assumption of "better quality due to more bits" that is in fact the problem here, because for many people like me and Draek, that assumption is utterly FALSE.
Think about it: are you really wanting to claim that all a painter has to do to make a better painting is to throw more paint on the canvas? More paint *always* means a better painting?!?
Jeez, will all you BD shills please, PLEASE, repeat after me:
Subjective truth is, well... SUBJECTIVE !
And I thought you *could* train monkeys.
You can, but the training is only cost-effective when you provide an undo function...
Please, just read at -1. Slashdot moderation is completely broken anyway,
Not as badly broken as trying to read a website with 8-12+ threads a day, with each one usually well over a hundred comments. Never mind the absurd 800 comment monsters (gave up on politics./. a *long* time ago).
Your advice worked in the good 'ole days of /. when we were a smaller and *relatively* more well-behaved group... but no more.
Filter at +1 or higher, and kill the ACs, your sanity will thank you.
The most important GPL software in Mac OS X is arguably the GNU compiler, gcc.
Not anymore. GCC on Apple is a Dead Man Walking, because Apple won't work with the GPLv3, which the FSF's GCC project has already upgraded to.
Apple is a major contributor to the LLVM project
Of course, because this is what they intend to replace GCC with, and when this happens GCC-on-Apple and ObjC-in-GCC both go into a slow death spiral. Apple has already ceased providing any significant patches to the FSF GCC project. For example, GCC still doesn't support ObjC v2, two years after its release. There just doesn't appear to be enough developer interest outside of Apple to keep FSF GCC updated.
Apple's implementation of the Cocoa Framework is not an open source framework, but it is based on an open specification, although it has evolved past the specification.
If it has evolved *past* an open specification, and is not open source, then its not open... anything. So your point is?
There is an alternative, open source implementation
Not Exactly:
Cocoa is full-on, closed-source, proprietary... full-stop. GNUSTEP would have the same problem Mono has (always playing catchup to MS's changes), only worse: they can't even look at the code. So they don't even try. Ergo:
GnuStep != Cocoa
There. Fixed it for you.
Not Exactly.
So what if corporations are just using FOSS to get what they want? Isn't that what we wanted in the first place when FOSS was invented? It doesn't matter how it is used, just so long as everyone has access to the source.
+1 Common Sense
And as long as the corps end up making the software *better*, than no one should really care one whit whether a project has corp help or not, its irrelevent.
But hey, this is /., the kids didn't come here to read common sensical stuff, they want to see blood on the floor. :)
One thing neither FOSS or Microsoft can fix is difficulty in aligning hardware and software designs when both are moving targets and only one is in your control
To some, handing control over *both* aspects to one company is not a "fix", its just twice as bad a mistake as giving one company absolute control over one of them.
Giving one company control over both the hardware and software does only one fundamental thing: it gives them more *control*. That's ALL. They can do positive things with that extra control, but as we all know from the history of personal computers, companies can also do very *negative* things with that enhanced control.
FWIW, I don't think this is really the best line of argument (giving the Overlord 2X the control is 2X *better*) that you should be trying to use in a thread thats ostensibly about FOSS. :)
They are also built on a rock-solid UNIX foundation. Tell me why you need Linux for Open Source.
Because I already *have* hardware? And its *my* hardware, of *my* choosing, and therefore better than Apple's hardware for those subsystems that matter to me?
Seriously, whats the point of your response, really? It would only make sense if you could get Apple's "rock-solid" software for non-Apple hardware.
but I suggest that anyone who doubts this to download Intel's compiler (it's free as in beer) and try it out.
...unless you're running an AMD system, in which case don't bother, because ICC won't show your code nearly as much love as it would for a Genuine-Intel-Inside (or so I've heard)...
At least you must admit that GCC is fair in its handling of its backends: it provides mediocre performance in equal doses. :)
improving performance on its most popular platforms if they want to remain relevant...
You don't understand, GCC's portability is the reason for its very existence. Thats not optional. GCC has got more than 20 backends (architectures) and 8-10 frontends (languages) for goodness sake, no freakin' wonder its a little slower than MSVC/ICC, those latter guys only have to worry about 2 backends (x86/x86_64) and 2 frontends (C/C++).
GCC's wide portability is what currently guaranttees its relevancy. The minute GCC starts chasing clock cycles on the x86 platform (at the expense of the others), that will be its curtain-call...
The real Messiah might have been Dennis Kucinich, and coincidentally he got crucified... both by the DNC *and* voters.
What we *really* need is to get people to stop thinking that only the Presidency makes a difference. There is no Messiah, its the 60 votes in the Senate that controls all.
you don't get revolution unless a significant part of the population (I'd guess about half) are actively starving, and have nothing left to lose.
Two counter-examples off the top of my head: the American Revolution (no starving masses, yet violent revolution), and North Korea of the last two decades or so (plenty of starving masses, but no violent revolution). I've even heard claims that the reason for the latter example is that starving people are too weak to fight.
Who's right? Don't know myself. Even if your theory is the 'rule', there still appears to be plenty of 'exceptions' to it, or else it, like real life, is a little more complicated and nuanced then we think.
I believe AMD wanted to bring one of the two chipset manufacturers in house so they could have better coupling between their processors and their chipsets.
That's probably part of the reason, but AMD is looking long term, and they see Larrabee on the horizon, so they're also working towards the eventual marriage of the CPU and GPU at some point in the future. In the short term, they're heading towards putting the CPU and GPU on the same die, last I read, they codenamed it 'Fusion'. Just google 'AMD Fusion', you should find references.