I have not only looked at compiler output, but actually write assembly for things like atomic reference counting.
OK, what do you want me to say? That you suck? I'm sorry you're such a lousy programmer that you can't go faster than a compiler?
There are indeed lots of areas where compiler optimization can be improved, but the single example you gave isn't one of them.
Your knowledge of compiler design is bad too lol. The compiler can often check to see if the function is pure or not, and it certainly can be given the correct information for built-in functions.
Containers are even more dangerous than VMs since you lose even more virtualization. All these technologies sit on a spectrum of resource-cost-to-containment with the hardest containment being a different physical machine. Even process isolation yields some amount of containment (can't snoop cross-process memory) but this is typically trivial to breach for any malware.
If you have a server (in a container or whatever), with all your user's passwords going through it.....then it really doesn't matter if the malware can't get out of the container, it can still sniff the passwords as they go through.
There are too many new developers coming in. The older guys may know how to write secure code, but then you have a bunch of new people and they have to learn the lessons of security all over again.
There is no "magic bullet." Garbage collection won't save you, a container won't save you. In the end, you need to be thinking about security every line you write, or you'll end up with an integer overflow that allows hackers to take over your container.
Your main problem is you've never really looked at compiler output, and you've never really tried to do better than a compiler. If you did, you would change your mind and have no trouble beating the compiler.
I'll give you a simple example. Consider this code:
for(i=0; i<strlen(s);i++) {
s[i] = tolower[i];
}
In this example, the strlen() can be hoisted out of the loop, only called once. This is a simple improvement. And yet even with full optimization turned on, LLVM doesn't hoist it.
If you can't write better assembly code than a typical compiler, you're not even trying.
Sometimes people don't see things as unethical. It wouldn't surprise me if all the engineers thought, "stupid Americans and their regulations......we know how to make an engine that is clean enough."
For comparison, it might be unethical to work in the advertising industry. You're mainly just showing ads that annoy people, and you're also giving them malware. It might also be unethical to build weapons of war. A lot of what bankers do is unethical.
Yet people in all those industries have their own justification to explain why it's ok to work on those products. When I worked in ad-tech, I would ask a lot of my coworkers how they felt about it, and they had different justifications, but everyone had one. I'm not trying to condemn them here, just pointing out that what one person considers unethical, another feels perfectly fine with.
Eh, that just means you haven't written much assembly, and haven't looked at much output from compilers. Again:
The average programmer can't do better than a compiler, but
with a little practice, a good programmer can easily do better than a compiler. Compilers aren't magical.
Unfortunately, a big part of the current 'Java is slow' claim is from idiots who don't understand that different GC implementations are all on a spectrum trading throughput for latency and who then build big distributed systems where tail latency in the edge nodes is important, then run a throughput-optimised stop-the-world collector on the edges and wonder why it sucks.
More of the current "java is slow" claim comes from idiots who have never touched a profiler.........
On average they are better at optimizing than a human could ever be.
What? No way! If you want to do better than the compiler, follow these steps:
1) Compile your program, get the assembly output from the compiler.
2) Find improvements (this will not be hard). Profile to determine how much faster your changes are.
3) After many repetitions of this, you will get good enough to write faster than the compiler without getting the assembly output.
Compilers do better than an average human writing assembly, but that's only because most humans aren't good at writing assembly. It's not hard to get your skill level up to the point where you can beat a compiler regularly.
As for would it have been any faster if it was written in C or straight ASM, probably not worth chasing down that extra 1%.
Assembly can give you huge performance gains, much more than 1%. One of the reasons why is because it gives you more control of caching. Paul Hsieh has written quite a bit on this topic, it's worth checking out.
Really? Sounds a bit rich to claim that an interpreted language would be faster than a compiled one,
The reasoning is because any bottleneck in code will be in a loop (or recursion, or whatever).
Java is roughly only interpreted on the first iteration of a loop, when it gets compiled by JIT. After that, it's assembly code, just like C.
Add to that, there are some optimizations that can be done at run-time by the JIT that can't be done at compile time.
These are typically the reasons people claim Java is faster than C or C++.
Also, it seems the Java creators at Sun were really competitive and got upset when people said their language was slower than C++, so they spent a lot of time optimizing the efficiency of their standard library, more than the C++ compiler writers of the time.
I'll have to think about your idea of grammars to parse everything......that seems like overkill to me.
Certainly there things which are more easily parsed by regular expression.
That's the point, all dead animals decompose and release particles into the air.
The scientist in this study kept jars of different types of flesh, including pig, rabbit, turtle and mole, and let them decompose. She sampled the air from their jars, to see which particles only appeared in decomposing human flesh, and not in that of other animals.
The flies... OH MAN THE FLIES...
On a dairy, it's not the dead cows that attract the most flies....
Slashdot Mirror
The part where you do that first, before deploying them in production, seems to have been skipped with Linux
Don't worry, the systemd programmers will take care of that!
I have not only looked at compiler output, but actually write assembly for things like atomic reference counting.
OK, what do you want me to say? That you suck? I'm sorry you're such a lousy programmer that you can't go faster than a compiler?
There are indeed lots of areas where compiler optimization can be improved, but the single example you gave isn't one of them.
Your knowledge of compiler design is bad too lol. The compiler can often check to see if the function is pure or not, and it certainly can be given the correct information for built-in functions.
And there is a magic bullet. It's called "knowing what you're doing"
Sounds like......you have a genius idea there.
Containers are even more dangerous than VMs since you lose even more virtualization. All these technologies sit on a spectrum of resource-cost-to-containment with the hardest containment being a different physical machine. Even process isolation yields some amount of containment (can't snoop cross-process memory) but this is typically trivial to breach for any malware.
If you have a server (in a container or whatever), with all your user's passwords going through it.....then it really doesn't matter if the malware can't get out of the container, it can still sniff the passwords as they go through.
There are too many new developers coming in. The older guys may know how to write secure code, but then you have a bunch of new people and they have to learn the lessons of security all over again.
There is no "magic bullet." Garbage collection won't save you, a container won't save you. In the end, you need to be thinking about security every line you write, or you'll end up with an integer overflow that allows hackers to take over your container.
Your main problem is you've never really looked at compiler output, and you've never really tried to do better than a compiler. If you did, you would change your mind and have no trouble beating the compiler.
When I read the original article back in Feb, I kind of thought it would be cool if they found a few Tor vuln's to fix,
Maybe they did.
OK, so now even you are listing reasons compilers are inefficient. Good job, soon you'll wake up and realize you agree with me.
the act itself is either ethical or it is not
Problem is everyone has their own definition of ethical.
Germans are not known for their dislike of regulations.
You can't imagine they thought, "We are environmentally friendly. Our own regulations are better than the American's?"
I'll give you a simple example. Consider this code:
for(i=0; i<strlen(s);i++) {
s[i] = tolower[i];
}
In this example, the strlen() can be hoisted out of the loop, only called once. This is a simple improvement. And yet even with full optimization turned on, LLVM doesn't hoist it.
If you can't write better assembly code than a typical compiler, you're not even trying.
Sometimes people don't see things as unethical. It wouldn't surprise me if all the engineers thought, "stupid Americans and their regulations......we know how to make an engine that is clean enough."
For comparison, it might be unethical to work in the advertising industry. You're mainly just showing ads that annoy people, and you're also giving them malware. It might also be unethical to build weapons of war. A lot of what bankers do is unethical.
Yet people in all those industries have their own justification to explain why it's ok to work on those products. When I worked in ad-tech, I would ask a lot of my coworkers how they felt about it, and they had different justifications, but everyone had one. I'm not trying to condemn them here, just pointing out that what one person considers unethical, another feels perfectly fine with.
Sounds like something you'd read in Wired
Wow what kind of device was that? Where can I get one?
Eh, that just means you haven't written much assembly, and haven't looked at much output from compilers. Again:
The average programmer can't do better than a compiler, but
with a little practice, a good programmer can easily do better than a compiler. Compilers aren't magical.
Unfortunately, a big part of the current 'Java is slow' claim is from idiots who don't understand that different GC implementations are all on a spectrum trading throughput for latency and who then build big distributed systems where tail latency in the edge nodes is important, then run a throughput-optimised stop-the-world collector on the edges and wonder why it sucks.
More of the current "java is slow" claim comes from idiots who have never touched a profiler.........
The danger is they'll never move beyond Javascript. Your reasons are good, though.
I don't think you understand what I was trying to say. I'll try to say it again more clearly.
High school math is something anyone can succeed in. It's not something you need special 'talent' to learn.
That's a load of blatant BS. First, Java standard library is full of slow retarded crap (consider the dead horse example of the String.split()).
I hope you're not one of those idiots who assumes C++ is automatically faster because it has templates. If you haven't timed it, you don't know.
On average they are better at optimizing than a human could ever be.
What? No way! If you want to do better than the compiler, follow these steps:
1) Compile your program, get the assembly output from the compiler.
2) Find improvements (this will not be hard). Profile to determine how much faster your changes are.
3) After many repetitions of this, you will get good enough to write faster than the compiler without getting the assembly output.
Compilers do better than an average human writing assembly, but that's only because most humans aren't good at writing assembly. It's not hard to get your skill level up to the point where you can beat a compiler regularly.
As for would it have been any faster if it was written in C or straight ASM, probably not worth chasing down that extra 1%.
Assembly can give you huge performance gains, much more than 1%. One of the reasons why is because it gives you more control of caching. Paul Hsieh has written quite a bit on this topic, it's worth checking out.
Really? Sounds a bit rich to claim that an interpreted language would be faster than a compiled one,
The reasoning is because any bottleneck in code will be in a loop (or recursion, or whatever).
Java is roughly only interpreted on the first iteration of a loop, when it gets compiled by JIT. After that, it's assembly code, just like C.
Add to that, there are some optimizations that can be done at run-time by the JIT that can't be done at compile time.
These are typically the reasons people claim Java is faster than C or C++.
Also, it seems the Java creators at Sun were really competitive and got upset when people said their language was slower than C++, so they spent a lot of time optimizing the efficiency of their standard library, more than the C++ compiler writers of the time.
I'll have to think about your idea of grammars to parse everything......that seems like overkill to me.
Certainly there things which are more easily parsed by regular expression.
The scientist in this study kept jars of different types of flesh, including pig, rabbit, turtle and mole, and let them decompose. She sampled the air from their jars, to see which particles only appeared in decomposing human flesh, and not in that of other animals.
The flies... OH MAN THE FLIES...
On a dairy, it's not the dead cows that attract the most flies....
I still dont know why the desktop is and ever was a battle ground,
Because people buy desktop computers. That's the main reason.