GC so that if you are creating and destroying thousands, hundreds of thousands, or millions of variables the GC doesn't have to constantly collect.
Give an example of where this is needed.
If you're using a complex number class and doing a lot of computation on them. You could convert your code to modify values in place, but it's better to have this optimization performed automatically.
Also note that structs can be created, manipulated, and destroyed with Java with JNI and CNI.
That is clearly not an ideal way to program. Don't tell me you disagree.
Note that I don't think value types are useful. They make for confusing code because of the difference between value copying and reference copying semantics and the optimizations can be performed automatically by a compiler anyway. It's just that you don't seem to understand what the parent poster was talking about.
In.NET they are actually part of the backend. The VM. In Java, in the VM they're all just boxed objects. And lots of typecasts. Shitty. Google around for better explainations.
Java 1.5 has auto unboxing. Same thing.NET has. This was added on top of JSR-14. You are probably looking at the original generics design for Java 1.5 on googled pages. Its been updated.
Again, you have no idea what you're talking about. In Java, if you do ArrayList<int>, you'll create an collection that maintains references to individual java.lang.Integer objects. With CLR generics, it'll work a little more like C++ and you'll be using an array of 'int' value types. This is much, much, faster. It's also probably more memory efficient, even taking into consideration the replication of code. The unnecessary typecasting also slows things down a lot.
This is true, but there are two different issues here. The quote from Alan Cox probably refers to features in terms of general functionality. Sure, you're always catching up with people want.
With the CLR, two things are different. Firstly, you have to wait until MS has an implementation/specification before starting work on it. Secondly, you can't just provide similar functionality, you have to match the API exactly. This is tough when the API implicitly depends on Windows-specific features (from what I've read, an example of this might be S.W.F, though I don't know the internals).
It's tough to predict whether Mono will be able to keep up with Microsoft's platform. With something like that doesn't change as much, like POSIX, it's probably easier. With.NET, the target can move as fast as MS wants it to move. Though it feels like the gap is slowly closing after the initial torrent of new APIs and language features, the new Longhorn API will be another big piece that will take a while to implement (if it's even feasible).
On the other hand, Mono does provide a nice development platform that isn't necessarily compatible with the MS platform, and that's useful in itself.
ValueTypes (structs) are not supported in Java, which is a source of major pressure on the GC, an issue solved completely by the availability of it
on.NET
Since you know something about JIT compilation and GC, I'd like to ask you about the actual benefit of value types. At first I thought they were great but now I'm not so sure. There appears to be a couple ways to solve the GC and performance issues without creating a user-visible partition of the type hierarchy (and the potentially error-inducing difference between copying references vs. copying values).
Escape analysis can be used to figure out when an object stays within the bounds of a single thread's stack. That way, many objects can be allocated on the stack automatically.
Also, if the compiler can detect that a class is immutable, then the it would be free to copy instances around when they're sufficiently small (instead of passing a pointer).
Those two optimizations seem to be feasible, though the first probably requires intra-procedural analysis to perform well. Are there benefits to value types that these two optimizations don't nullify?
On the topic of Generics, the CLR implementation has a lot of advantages over the Java implementation (I especially like the runtime specialization for value types). However, currently Java has the convenient notion of covariance and contravariance of type parameters (though they chose really, really bloated syntax). This is one of those features that I expect will make it into the CLR pretty soon (or maybe it'll stop at the langauge level) because MS seems to have no problem adding features, which, as a side benefit, also pushed Sun to start adding stuff!
He's not saying XML is crap (though it is). He's just saying that the fact that XML was used doesn't have anything to do with the core idea. It makes just as much sense to say "Reducing Electricity Bills For Buildings with Intel processors" (if that's what the servers happened to be running).
No. Coalescing a bunch of 'delete' calls will not help much. Though the cache hit rate will probably go up, it will still be fundamentally different from the way GC works.
'new' and 'delete' are relatively expensive in that they have to maintain complex data structures to keep track of free space. A copying garbage collector only really needs a couple pointers. The allocation operation is very, very, very fast (pointer increment). The collection operation's running time is an increasing function of how much live data there is.
What they *could* do is try strapping on the Boehm GC to C++. But then they'd be comparing the JVM to a C++ setup that nobody uses.
I think Mac OS X is structured like a microkernel but everything's compiled and statically linked together for speed. With this setup, you can have your clean design but you still get rid of the context switches. That said, the design itself will impose some overhead (though the tradeoff may be worth it).
Another solution is to use a safe language to eliminate the need for address space separation and let the kernel JIT code when it's loaded. Compilation techniques for safe languages are getting better and better so performance is becoming less of an issue. One example is Brix, which runs everything in kernel space (even applications).
However, I don't know how you would deal with a misbehaving process in a shared address space (i.e. how would you write an OOM killer?). The Spin OS has a way of detecting badly-behaving code, but I think that dynamically-loadable code is restricted in what kind of functions it's allowed to perform.
You could have just linked to Joel's rant instead of copying it without attribution.
Anyway, I think that the way to go is to make the standard local-file-access API more powerful. That way, you can still have a unified API. Which is why "FtpOpenFile" isn't the best way to go.
And it doesn't necessarily have to be much harder to access local resources with the more powerful API. The common/simple cases can be streamlined. For example, language features like exceptions can let you ignore errors that you wont encounter when doing local stuff. (No, exception semantics aren't perfect (yet), but they do work well in many situations).
If you intend to write your tool entirely in regex, good luck to you. You already need some type analysis to match types to variables for field extraction. Parsing type declarations is not that difficult and then you just maintain a type tree and look things up when you need them. Really, if you have ever write a compiler, you'll discover that it is one of the simpler parts of the project.
The original post suggested that the marketing department was giving fancy names to simple search/replace operations. All I was saying is that conventional search/replace (even with regular expressions) is not powerful enough to perform those refactorings.
As you said, the editor would require functionality equivalent to the parsing and type-checking parts of a compiler. To perform clean refactorings, the editor would probably also have to analyze flow control to trace variable definition-use chains. Also, C++ is not easy to parse.
What if there is B::foo() as well? what if B::foo() is used in A?
B::foo() is a completely separate function from A::foo() and should not be renamed. It is easy to tell which one A wants to call because the call method would differ (b->foo() as opposed to foo()).
Sure, but what if you had 'x->foo()'? You have to know the type of variable 'x'. This is not a simple search/replace operation, unless you can do type analysis with a regex (you can't). Then again, maybe your editor does search/replace with CFGs.
Oh, what was that? C++ cannot be type-checked with a CFG either? Wow, you must have some sort of turing-complete search/replace. That is sooo awesome! Now all you have to do is write half a compiler every time you want to rename a method.
The fact that Novell is going to use QT is very telling. Novell is a software corporation whose existence past, present and future relies on selling software. That means that while they will throw the open source community a GPLed bone (Yast, Evolution) they will also offer up lots of closed source applications and some will be QT based.
How does this kind of stuff get modded up? I don't see how Qt makes any more sense than GTK. The main non-technical difference is that they wouldn't have to pay anything to use GTK. Sure, Novell is willing to pay, but I don't see why they'd be against getting it for free.
I think what he's saying is that the syntax isn't the only thing that defines a language. A language's type system probably plays a more important part in defining how the language works.
With.Net, it may seem like you have a lot of interoperating languages, but they're all basically the same language with different superficial characteristics. VB developers complain about how VB.Net is totally different from previous versions of Visual Basic. It's because they gutted its internals and implanted C#. I wouldn't be able to tell the difference because I see similar syntax, but someone who really knows the language will detect a different core.
That's not to say that different type systems cannot be emulated. Nice is a language with Java-like syntax but with a much better type system (among other things) and it still runs on an ordinary JVM. However, any interoperability will have to be at the level of the lowest common denominator. If you want to call Nice code from Java, your interface ends up losing or having to give up some power.
You really can't even share libraries between truely different languages. The STL just doesn't fit into the Java/C#-style type systems (though generics is a step towards accomodating the STL). Perl libraries are also distinct. Imagine dealing with a Haskell-style lazy list in your C# code. It just wont feel right.
Stock binaries are usually compiled for i386. When you compile your own, they will be optimized for whatever processor you have. I assumed that your first conclusion was that there was no significant difference in speed between these settings.
Whether or not this is true, I thought you were only ruling out the impact of different -march settings on GCC. I didn't realize that you ruled out the possibility that a totally different compiler might improve performance.
As a side note, was your subjective judgement made on machines running the same version of the kernel? I'm not a kernel person, but I've read that the "snappiness" (i.e. response latency) varies a lot between kernel versions.
Staying out of jail, and knowing what a compiler is doing, are *practical* arguments against using Intels compiler.
How is staying out of jail an argument against using Intel's compiler? It's only an argument against using ICC illegally. Same thing goes for distributing GCC under an incompatible license.
As for "knowing what your compiler is doing", you never made this argument in your original post. Even so, I assume you're getting at one of three things:
You don't trust Intel enough to run their binaries on your machine
You would like to know how the compiler works
You don't trust that the compiler is even working if you can't examine the source code
The first point is the only remotely valid argument, but I'm sure most people trust Intel enough to use their compiler, so they really don't care.
If you want to learn how a compiler works, that's great. No, you can't learn from ICC. However, this isn't an argument against using it.
As for the third interpretation, I'm sure ICC works just fine. For compilers, it's probably more feasible to validate functionality through test suites (as opposed to a code audit).
Don't get me wrong, I have this feeling that there will never be an open source implementation of java, and so I'm rooting for python
The biggest thing standing in the way is the lack of libraries. There are VMs and compilers available but the huge class library takes longer to replicate. The GNU Classpath project seems to be coming along nicely. I don't think the project will be abandoned any time soon either because lots of other projects depend on it.
Yes, I am fully aware that Jython outputs Java bytecode itself, but Sun's Java compiler does a lot better generating efficient Java bytecode out of Java than Jython does. Nothing inherent to Python or Jython, but when you've got a multi-billion dollar project like Java, when you consider what Sun puts into it
[snip]
The lack of static typing (inherent in the Python language) will make it slower. Methods will be looked up by name (in string form) instead of by VFT offset.
Man...I can't believe people just let this post go.
The fact is, X is an old protocol, designed to work on slow machines, and KDE3 is not supposed to be compared to Windows 98.
X does not need to be replaced.
Doesn't the availability of faster machines warrant consideration of possible replacements?
Then it goes: X is slow and bloated. Let me see... It has network transparency?! hmmm.. windows dont, so that must be it!! lets remove network transparency, then it'll be all better.
I don't know why you are saying this because the "Y" system is network transparent. The difference is that the protocol is at a higher level (at the level of UI controls instead of primitive graphics operations). This will make it faster when used over the network.
Personally, I would prefer an extensible protocol where the server can be extended with more high-level commands (i.e. other GUI toolkits that have libraries installed on both sides). But hey, I'm not the one who decided to get off of this ass and write a GUI system so I don't get to make the design choices.
Slashdot Mirror
If you're using a complex number class and doing a lot of computation on them. You could convert your code to modify values in place, but it's better to have this optimization performed automatically.
That is clearly not an ideal way to program. Don't tell me you disagree.
Note that I don't think value types are useful. They make for confusing code because of the difference between value copying and reference copying semantics and the optimizations can be performed automatically by a compiler anyway. It's just that you don't seem to understand what the parent poster was talking about.
Again, you have no idea what you're talking about. In Java, if you do ArrayList<int>, you'll create an collection that maintains references to individual java.lang.Integer objects. With CLR generics, it'll work a little more like C++ and you'll be using an array of 'int' value types. This is much, much, faster. It's also probably more memory efficient, even taking into consideration the replication of code. The unnecessary typecasting also slows things down a lot.
This is true, but there are two different issues here. The quote from Alan Cox probably refers to features in terms of general functionality. Sure, you're always catching up with people want.
With the CLR, two things are different. Firstly, you have to wait until MS has an implementation/specification before starting work on it. Secondly, you can't just provide similar functionality, you have to match the API exactly. This is tough when the API implicitly depends on Windows-specific features (from what I've read, an example of this might be S.W.F, though I don't know the internals).
It's tough to predict whether Mono will be able to keep up with Microsoft's platform. With something like that doesn't change as much, like POSIX, it's probably easier. With .NET, the target can move as fast as MS wants it to move. Though it feels like the gap is slowly closing after the initial torrent of new APIs and language features, the new Longhorn API will be another big piece that will take a while to implement (if it's even feasible).
On the other hand, Mono does provide a nice development platform that isn't necessarily compatible with the MS platform, and that's useful in itself.
Since you know something about JIT compilation and GC, I'd like to ask you about the actual benefit of value types. At first I thought they were great but now I'm not so sure. There appears to be a couple ways to solve the GC and performance issues without creating a user-visible partition of the type hierarchy (and the potentially error-inducing difference between copying references vs. copying values).
Escape analysis can be used to figure out when an object stays within the bounds of a single thread's stack. That way, many objects can be allocated on the stack automatically.
Also, if the compiler can detect that a class is immutable, then the it would be free to copy instances around when they're sufficiently small (instead of passing a pointer).
Those two optimizations seem to be feasible, though the first probably requires intra-procedural analysis to perform well. Are there benefits to value types that these two optimizations don't nullify?
On the topic of Generics, the CLR implementation has a lot of advantages over the Java implementation (I especially like the runtime specialization for value types). However, currently Java has the convenient notion of covariance and contravariance of type parameters (though they chose really, really bloated syntax). This is one of those features that I expect will make it into the CLR pretty soon (or maybe it'll stop at the langauge level) because MS seems to have no problem adding features, which, as a side benefit, also pushed Sun to start adding stuff!
He's not saying XML is crap (though it is). He's just saying that the fact that XML was used doesn't have anything to do with the core idea. It makes just as much sense to say "Reducing Electricity Bills For Buildings with Intel processors" (if that's what the servers happened to be running).
I think he was talking about C++ (where pooling would help).
No. Coalescing a bunch of 'delete' calls will not help much. Though the cache hit rate will probably go up, it will still be fundamentally different from the way GC works.
'new' and 'delete' are relatively expensive in that they have to maintain complex data structures to keep track of free space. A copying garbage collector only really needs a couple pointers. The allocation operation is very, very, very fast (pointer increment). The collection operation's running time is an increasing function of how much live data there is.
What they *could* do is try strapping on the Boehm GC to C++. But then they'd be comparing the JVM to a C++ setup that nobody uses.
I think Mac OS X is structured like a microkernel but everything's compiled and statically linked together for speed. With this setup, you can have your clean design but you still get rid of the context switches. That said, the design itself will impose some overhead (though the tradeoff may be worth it).
Another solution is to use a safe language to eliminate the need for address space separation and let the kernel JIT code when it's loaded. Compilation techniques for safe languages are getting better and better so performance is becoming less of an issue. One example is Brix, which runs everything in kernel space (even applications).
However, I don't know how you would deal with a misbehaving process in a shared address space (i.e. how would you write an OOM killer?). The Spin OS has a way of detecting badly-behaving code, but I think that dynamically-loadable code is restricted in what kind of functions it's allowed to perform.
You could have just linked to Joel's rant instead of copying it without attribution.
Anyway, I think that the way to go is to make the standard local-file-access API more powerful. That way, you can still have a unified API. Which is why "FtpOpenFile" isn't the best way to go.
And it doesn't necessarily have to be much harder to access local resources with the more powerful API. The common/simple cases can be streamlined. For example, language features like exceptions can let you ignore errors that you wont encounter when doing local stuff. (No, exception semantics aren't perfect (yet), but they do work well in many situations).
I don't think the parent poster had a problem understanding big-Oh. He was just responding to this statement of yours:
The situation he presented is one in which bubble sort would be preferable.
The original post suggested that the marketing department was giving fancy names to simple search/replace operations. All I was saying is that conventional search/replace (even with regular expressions) is not powerful enough to perform those refactorings.
As you said, the editor would require functionality equivalent to the parsing and type-checking parts of a compiler. To perform clean refactorings, the editor would probably also have to analyze flow control to trace variable definition-use chains. Also, C++ is not easy to parse.
Sure, but what if you had 'x->foo()'? You have to know the type of variable 'x'. This is not a simple search/replace operation, unless you can do type analysis with a regex (you can't). Then again, maybe your editor does search/replace with CFGs.
Oh, what was that? C++ cannot be type-checked with a CFG either? Wow, you must have some sort of turing-complete search/replace. That is sooo awesome! Now all you have to do is write half a compiler every time you want to rename a method.
With a patent this stupid, I don't think it matters who holds it.
How does this kind of stuff get modded up? I don't see how Qt makes any more sense than GTK. The main non-technical difference is that they wouldn't have to pay anything to use GTK. Sure, Novell is willing to pay, but I don't see why they'd be against getting it for free.
By solving the halting problem. Duh!
I think what he's saying is that the syntax isn't the only thing that defines a language. A language's type system probably plays a more important part in defining how the language works.
With .Net, it may seem like you have a lot of interoperating languages, but they're all basically the same language with different superficial characteristics. VB developers complain about how VB.Net is totally different from previous versions of Visual Basic. It's because they gutted its internals and implanted C#. I wouldn't be able to tell the difference because I see similar syntax, but someone who really knows the language will detect a different core.
That's not to say that different type systems cannot be emulated. Nice is a language with Java-like syntax but with a much better type system (among other things) and it still runs on an ordinary JVM. However, any interoperability will have to be at the level of the lowest common denominator. If you want to call Nice code from Java, your interface ends up losing or having to give up some power.
You really can't even share libraries between truely different languages. The STL just doesn't fit into the Java/C#-style type systems (though generics is a step towards accomodating the STL). Perl libraries are also distinct. Imagine dealing with a Haskell-style lazy list in your C# code. It just wont feel right.
Looks like we were both wrong. It was the other Unix guy, Ken Thompson.
Stock binaries are usually compiled for i386. When you compile your own, they will be optimized for whatever processor you have. I assumed that your first conclusion was that there was no significant difference in speed between these settings.
Whether or not this is true, I thought you were only ruling out the impact of different -march settings on GCC. I didn't realize that you ruled out the possibility that a totally different compiler might improve performance.
As a side note, was your subjective judgement made on machines running the same version of the kernel? I'm not a kernel person, but I've read that the "snappiness" (i.e. response latency) varies a lot between kernel versions.
I think it was Brian Kernighan (one of the Unix guys).
How is staying out of jail an argument against using Intel's compiler? It's only an argument against using ICC illegally. Same thing goes for distributing GCC under an incompatible license.
As for "knowing what your compiler is doing", you never made this argument in your original post. Even so, I assume you're getting at one of three things:
The first point is the only remotely valid argument, but I'm sure most people trust Intel enough to use their compiler, so they really don't care.
If you want to learn how a compiler works, that's great. No, you can't learn from ICC. However, this isn't an argument against using it.
As for the third interpretation, I'm sure ICC works just fine. For compilers, it's probably more feasible to validate functionality through test suites (as opposed to a code audit).
That's a strange conclusion. The Gentoo comparision is a comparison of two -march settings on GCC. ICC is a whole different compiler.
Um...that URL is for a Linux machine.
I guess "far off" is relative, but take a look at GNOME Storage. It's pure theory either; look at the pretty screenshots.
The biggest thing standing in the way is the lack of libraries. There are VMs and compilers available but the huge class library takes longer to replicate. The GNU Classpath project seems to be coming along nicely. I don't think the project will be abandoned any time soon either because lots of other projects depend on it.
The lack of static typing (inherent in the Python language) will make it slower. Methods will be looked up by name (in string form) instead of by VFT offset.
Man...I can't believe people just let this post go.
Doesn't the availability of faster machines warrant consideration of possible replacements?
I don't know why you are saying this because the "Y" system is network transparent. The difference is that the protocol is at a higher level (at the level of UI controls instead of primitive graphics operations). This will make it faster when used over the network.
Personally, I would prefer an extensible protocol where the server can be extended with more high-level commands (i.e. other GUI toolkits that have libraries installed on both sides). But hey, I'm not the one who decided to get off of this ass and write a GUI system so I don't get to make the design choices.