This is a blog article that essentially says "on linux you have this gcc compiler, and you use opengl instead of directx for games". How useful! I'm sure most people didn't already know that. Not slashdot worthy at all.
You're naive if you think that mercurial can do all that git does. The only ones that believe this are the mercurial developers, and it's becayse they never used git seriously.
You realize even the Amazon Kindle (supposedly the most evil device) does none of those things, right? I have one, have never connected it to the Internet, and all the ebooks I have were downloaded online.
A GPU, even a GTX Titan, simply isn't 7 times faster than a modern 32-core x86 CPU in real life. Most of the gain probably comes from just general optimization that could have been done on the CPU too.
Number crunching rarely involve any pointers in the critical parts, the only exception I can think of is sparse matrices, which is actually usually done with fixed-size indexes rather than pointers. Game engines however probably have a lot of trees of pointers for their scene graph, so they could be affected. But if they're well-optimized, they're designed to that each level fits exactly inside a cache line, and changing the size of the pointers will mess that up.
Any application that does heavy-numerical computation should not be affected by much by the ABI if at all. All function calls are inlined inside the critical loop.
Regardless of what you think about homosexuality, he behaved against the law that was in place at the time. It's a shame we lost a great man because of this, but law is arbitrary, and sometimes it destroys some people.
He wasn't wrongly accused or anything. This is only being done out of pressure to make a statement. It is legally entirely stupid.
They probably convert a high-level representation to asm.js, not machine code. Seriously dude, they don't even have sized integer and floating-point types...
It is a lie, or maybe they don't know what "at worst" means. It's easy to come up with a C snippet that is 2 times faster with one compiler than another compiler. Likewise it should be trivial to come up with a snippet that is 2 times faster with a C compiler than with asm.js.
I was just pointing out that not all of the French agree to what the above poster said. The funny thing is that while Sarkozy is considered hardcore rightwing in France, in the US he would probably be considered a democrat. That's just how different the two countries are.
I am a former researcher affiliated to a CNRS laboratory and I am now an entrepreneur with an innovative start-up. Without the incentives (which are relatively hard to get, unreliable and require a tremendous amount of effort and paperwork), I wouldn't even have considered creating a company in France due to the enormous welfare costs (60% of salaries, and that's without income tax which is very variable, but usually around 15%) and society being generally hostile to entrepreneurs (impossible to get loans or even rent an apartment). The tax lay-offs for research have been gradually reduced from 50% to 30% (with a possible lowering to 20% for some research being re-qualified as merely innovation), so even that is becoming less useful every day. Investors only play it secure and will rarely invest in ideas that were not proven by establishing a profitable company first. Getting a research grant (be it from regions, the state or from the UN) is also a huge effort unlikely to pay off, the only strategy to make it profitable is to join another company's project and let spend all the man-hours necessary to present the project, but of course it doesn't work if everyone does that.
There is no question that the US is much better at fostering entrepreneurship and creating new businesses, as it is easier for both businesses and research to get money there, and the administration doesn't try to prevent you from doing your job everyday. The French government relies on public spending to run the economy (20% of the active population are permanent government workers) instead of using that money to encourage private parties to create autonomous economic activity. Even when the French government gives 100 million to entrepreneurs, 70 million out of these go to government workers whose role is to distribute this money. If it wanted to embrace capitalism, it should try to be at least a bit more efficient.
I'm French. France is definitely socialist, and so-called innovations happened in spite of that, not because of it. True capitalism is the best thing that could happen to France.
The optimizations I highlighted all will affect the data access pattern
That's not quite true. Only some of the highlighted ones will, the others keep the same general pattern (unrolling in particular, which isn't so high level).
As I said in another part of the thread, those high level transformations you speak of don't really happen in the real world, and are not reliable (hence the "I don't know what world you live in"). Compiler authors can claim all they want, but having done a lot of looking at assembly and optimizing manually, I can tell you it's still quite far from what an expert can do. With the Intel compiler, I've even had issues with scalar replacement as soon as you have enough object encapsulation.
Compiler authors and researchers like to claim their software performs all kinds of optimizations automatically. I remember being told of a conference not so long ago where a colleague explained several transformations he did to his C code of a simple filter algorithm that multiplied performance by several levels of magnitude on POWER, and an IBM guy said their compiler should take care of all those transformations automatically. Well clearly, it didn't.
I'm quite aware of the state of the art, I have in particular seen the work of the researchers who worked on the polyhedric model for loop optimization which was relatively recently added to llvm and gcc. It can indeed do tiling or loop fusion, or even split your loops in several ones to identify the parallel sections, assuming you have full alias analysis information, your loops have simple boundaries and regular control flow, and you have enough time to find that this is the right transformation to make among the whole space of possible transformations.
I also know that in the real world, it doesn't work so well unless you explicitly program for it or guide it with pragmas. Automatic vectorization isn't reliable, compilers even fail at unrolling most of the time. Why would you rely on much more complex transformations to occur magically?
Sorry, but in your example the fact that dst and src overlap or not is irrelevant for vectorization. Even for dst[i+j] = src[i] with j small enough it's irrelevant too. Sure, vectorization and other optimizations change memory access ordering (loadx4 computex4 storex4 instead of (load compute store)x4), but I was talking about the pattern, which doesn't change.
For good software, all you should need to do is recompile and test.
This is a blog article that essentially says "on linux you have this gcc compiler, and you use opengl instead of directx for games".
How useful! I'm sure most people didn't already know that. Not slashdot worthy at all.
Foreigners are normally much better at grammar than natives.
You're naive if you think that mercurial can do all that git does. The only ones that believe this are the mercurial developers, and it's becayse they never used git seriously.
You realize even the Amazon Kindle (supposedly the most evil device) does none of those things, right?
I have one, have never connected it to the Internet, and all the ebooks I have were downloaded online.
ebooks have the font size you want.
How about shorter novels? We could make them short enough to be a sentence. We could call them 'tweets'!
A GPU, even a GTX Titan, simply isn't 7 times faster than a modern 32-core x86 CPU in real life. Most of the gain probably comes from just general optimization that could have been done on the CPU too.
You mean like VAT?
Number crunching rarely involve any pointers in the critical parts, the only exception I can think of is sparse matrices, which is actually usually done with fixed-size indexes rather than pointers.
Game engines however probably have a lot of trees of pointers for their scene graph, so they could be affected. But if they're well-optimized, they're designed to that each level fits exactly inside a cache line, and changing the size of the pointers will mess that up.
Any application that does heavy-numerical computation should not be affected by much by the ABI if at all. All function calls are inlined inside the critical loop.
This way you'll be able to make it magically much faster when building it for x32 or amd64.
Regardless of what you think about homosexuality, he behaved against the law that was in place at the time.
It's a shame we lost a great man because of this, but law is arbitrary, and sometimes it destroys some people.
He wasn't wrongly accused or anything. This is only being done out of pressure to make a statement. It is legally entirely stupid.
That joke doesn't work if you pronounce Amen correctly.
They probably convert a high-level representation to asm.js, not machine code.
Seriously dude, they don't even have sized integer and floating-point types...
Lots of people can make your code 1.5 times faster for a price, no need to kill.
It is a lie, or maybe they don't know what "at worst" means.
It's easy to come up with a C snippet that is 2 times faster with one compiler than another compiler. Likewise it should be trivial to come up with a snippet that is 2 times faster with a C compiler than with asm.js.
I was just pointing out that not all of the French agree to what the above poster said.
The funny thing is that while Sarkozy is considered hardcore rightwing in France, in the US he would probably be considered a democrat. That's just how different the two countries are.
I am a former researcher affiliated to a CNRS laboratory and I am now an entrepreneur with an innovative start-up. Without the incentives (which are relatively hard to get, unreliable and require a tremendous amount of effort and paperwork), I wouldn't even have considered creating a company in France due to the enormous welfare costs (60% of salaries, and that's without income tax which is very variable, but usually around 15%) and society being generally hostile to entrepreneurs (impossible to get loans or even rent an apartment). The tax lay-offs for research have been gradually reduced from 50% to 30% (with a possible lowering to 20% for some research being re-qualified as merely innovation), so even that is becoming less useful every day. Investors only play it secure and will rarely invest in ideas that were not proven by establishing a profitable company first. Getting a research grant (be it from regions, the state or from the UN) is also a huge effort unlikely to pay off, the only strategy to make it profitable is to join another company's project and let spend all the man-hours necessary to present the project, but of course it doesn't work if everyone does that.
There is no question that the US is much better at fostering entrepreneurship and creating new businesses, as it is easier for both businesses and research to get money there, and the administration doesn't try to prevent you from doing your job everyday.
The French government relies on public spending to run the economy (20% of the active population are permanent government workers) instead of using that money to encourage private parties to create autonomous economic activity. Even when the French government gives 100 million to entrepreneurs, 70 million out of these go to government workers whose role is to distribute this money. If it wanted to embrace capitalism, it should try to be at least a bit more efficient.
Because Southern Europe tends to like capitalism less, which is what the US embodies.
I'm French. France is definitely socialist, and so-called innovations happened in spite of that, not because of it. True capitalism is the best thing that could happen to France.
Northern Europe is indeed more friendly towards the US than Southern or even Western Europe.
That's not quite true. Only some of the highlighted ones will, the others keep the same general pattern (unrolling in particular, which isn't so high level).
As I said in another part of the thread, those high level transformations you speak of don't really happen in the real world, and are not reliable (hence the "I don't know what world you live in"). Compiler authors can claim all they want, but having done a lot of looking at assembly and optimizing manually, I can tell you it's still quite far from what an expert can do. With the Intel compiler, I've even had issues with scalar replacement as soon as you have enough object encapsulation.
Compiler authors and researchers like to claim their software performs all kinds of optimizations automatically. I remember being told of a conference not so long ago where a colleague explained several transformations he did to his C code of a simple filter algorithm that multiplied performance by several levels of magnitude on POWER, and an IBM guy said their compiler should take care of all those transformations automatically. Well clearly, it didn't.
I'm quite aware of the state of the art, I have in particular seen the work of the researchers who worked on the polyhedric model for loop optimization which was relatively recently added to llvm and gcc. It can indeed do tiling or loop fusion, or even split your loops in several ones to identify the parallel sections, assuming you have full alias analysis information, your loops have simple boundaries and regular control flow, and you have enough time to find that this is the right transformation to make among the whole space of possible transformations.
I also know that in the real world, it doesn't work so well unless you explicitly program for it or guide it with pragmas. Automatic vectorization isn't reliable, compilers even fail at unrolling most of the time. Why would you rely on much more complex transformations to occur magically?
Sorry, but in your example the fact that dst and src overlap or not is irrelevant for vectorization. Even for dst[i+j] = src[i] with j small enough it's irrelevant too.
Sure, vectorization and other optimizations change memory access ordering (loadx4 computex4 storex4 instead of (load compute store)x4), but I was talking about the pattern, which doesn't change.
But that's a change of algorithm, not something a compiler can do.