I've come to like a mixed type system: static typing with inference and optional duck typing. Take a look at Boo to see a nice application of such a system.
For the record, though, Javascript is turning into this without any need for a language change. The compiler determines types to the best of its ability and then compiles with those assumptions in mind. At future accesses, those assumptions are checked for validity, and the process continues. In this way, we can cut down on the cost of object type checks, pushing them to compile time in most cases. This is done by the DLR to great success, but there's still a lot of work to be done.
"i'm sure i could make any bog standard application run as fast as it's c counterpart if i throw resources at it"
That was what I was referring to. Yes, using more memory affects performance, but you were saying that the/reason/ more memory was used was for the purpose of performance.
The use of more memory really has nothing to do with performance at all. It's that you've got a decent bit of overhead on every object and it adds up. In addition to the objects themselves being bigger (say, a string being represented as a refcount, a length, and then the data), you have the memory the GC uses.
In the end, we pay for the convenience of these objects in memory, but it really has very little to do with performance. You could, of course, argue that you have multiple forms of the code in memory due to JITing, but that's negligible compared to the data handled by these applications.
Aaaaaaactually, this is one place where such languages can shine. I don't know about the JS implementation in Firefox, but I know that MS.NET does memory allocation voodoo where an app domain will preallocate memory for objects. That way when you want to actually instantiate an object, you don't have the allocation step. In addition, when the GC runs and deletes objects, the memory gets put back into the pool. It leads to impressive performance for creation of a large number of objects.
Well, you're on the right trail, but not quite right. The key difference between Javascript and C, from an optimization standpoint, is the type system. The overhead of dynamic types is quite immense even at its most optimal. I suggest looking into the architecture of the DLR -- it really shows the key problems behind compiling dynamic languages and how they're being solved.
I wish that was true of anywhere (anywhere worth living, that is) in CA, really. When I lived in San Diego I was paying $1200/mo for a pretty terrible 1br apartment. Now in PA, I'm paying $500/mo for a nice 2br house.
Actually, there is. Emulating the individual components is fairly easy (most of it is well documented) but managing the synchronization between all the chips is incredibly difficult. The fact that the emulators out there work as well as they do is quite amazing.
Microsoft is giving them support and all of the licenses involved have patent release clauses. MS wouldn't have a leg to stand on legally here (not that that's stopped companies with lots of money from burying the competition in legal fees before).
Not only that, the DLR and IronRuby are both released under the MS-PL, which is OSI-approved. If anything depends on proprietary libraries, it can be swapped out with a free alternative.
Oh, so Qt4 allows for complex runtime code generation? It allows you to deploy a single binary on multiple platforms? You're not just comparing comparing two completely different things here, you're comparing two completely different classes of things.
Perhaps doing a bit more research before posting is a Good Thing (TM).
RISC processors usually (always, in practice) have higher performance for the same clock speed when compared to CISC processors. Although they require multiple instructions to do things, these are almost always 1 or 2 cycles each. That means that although it may have to execute 3 instructions to do the same as 1 CISC instruction, it's often done it in half the clock cycles.
It has one particularly complicated shifting and masking instruction that makes me think that they decided to add programmatic access to the load data aligner in the data cache. Ugh, PPC is full of shit like that. I'm implementing a PPC core as part of my emulation platform ( http://sourceforge.net/projects/ironbabel/ ) right now, and instructions like rlwinmx, srawx, srwx, slwx, cntlzwx, crxor are just painful. PPC/Power is really well designed, but god it's painful to deal with.
It's not at all hard to find a real practical purpose. If you take one step into the emulation world, it's all around you. Self-modifying code is not just the norm but an absolute requirement.
These people need to learn the difference between codecs and DRM schemes. WMA support means the hardware can decode it, not decrypt the data. You're going to force Apple to license Microsoft's DRM? That's retarded.
Have you ever considered that it's not just memory state? You have to bring all devices to their previous state as well, which happens on a per-device basis. Please learn about what you're talking about before bitching. Thanks.
All that needs to be done to make PyMusique again is to reverse-engineer the algorithm used to encrypt the store pages behind ssl, the algorithm that manipulates their keys, and the simple algorithm used to encrypt the files as they're transferred from the store (before per-user DRM is applied).
Not very difficult at all, just a bit time consuming.
(From the original author of PyTunes, which PyMusique is a GUI frontend to:P )
I got my start on Freenode many, many years ago, and now have been involved with dozens, possibly hundreds of projects, all on freenode. I've talked with Lilo many times and have never had a bad experience. One of the kindest and most helpful people I've ever met.
Slashdot Mirror
I've come to like a mixed type system: static typing with inference and optional duck typing. Take a look at Boo to see a nice application of such a system.
For the record, though, Javascript is turning into this without any need for a language change. The compiler determines types to the best of its ability and then compiles with those assumptions in mind. At future accesses, those assumptions are checked for validity, and the process continues. In this way, we can cut down on the cost of object type checks, pushing them to compile time in most cases. This is done by the DLR to great success, but there's still a lot of work to be done.
"i'm sure i could make any bog standard application run as fast as it's c counterpart if i throw resources at it" That was what I was referring to. Yes, using more memory affects performance, but you were saying that the /reason/ more memory was used was for the purpose of performance.
The use of more memory really has nothing to do with performance at all. It's that you've got a decent bit of overhead on every object and it adds up. In addition to the objects themselves being bigger (say, a string being represented as a refcount, a length, and then the data), you have the memory the GC uses. In the end, we pay for the convenience of these objects in memory, but it really has very little to do with performance. You could, of course, argue that you have multiple forms of the code in memory due to JITing, but that's negligible compared to the data handled by these applications.
Aaaaaaactually, this is one place where such languages can shine. I don't know about the JS implementation in Firefox, but I know that MS.NET does memory allocation voodoo where an app domain will preallocate memory for objects. That way when you want to actually instantiate an object, you don't have the allocation step. In addition, when the GC runs and deletes objects, the memory gets put back into the pool. It leads to impressive performance for creation of a large number of objects.
Well, you're on the right trail, but not quite right. The key difference between Javascript and C, from an optimization standpoint, is the type system. The overhead of dynamic types is quite immense even at its most optimal. I suggest looking into the architecture of the DLR -- it really shows the key problems behind compiling dynamic languages and how they're being solved.
I heard it through the sandvine.
I wish that was true of anywhere (anywhere worth living, that is) in CA, really. When I lived in San Diego I was paying $1200/mo for a pretty terrible 1br apartment. Now in PA, I'm paying $500/mo for a nice 2br house.
Actually, there is. Emulating the individual components is fairly easy (most of it is well documented) but managing the synchronization between all the chips is incredibly difficult. The fact that the emulators out there work as well as they do is quite amazing.
Microsoft is giving them support and all of the licenses involved have patent release clauses. MS wouldn't have a leg to stand on legally here (not that that's stopped companies with lots of money from burying the competition in legal fees before).
Not only that, the DLR and IronRuby are both released under the MS-PL, which is OSI-approved. If anything depends on proprietary libraries, it can be swapped out with a free alternative.
The DLR and IronRuby are released under the MS-PL which is OSI-approved. Stop spreading FUD, asshat.
Oh, so Qt4 allows for complex runtime code generation? It allows you to deploy a single binary on multiple platforms? You're not just comparing comparing two completely different things here, you're comparing two completely different classes of things.
Perhaps doing a bit more research before posting is a Good Thing (TM).
RISC processors usually (always, in practice) have higher performance for the same clock speed when compared to CISC processors. Although they require multiple instructions to do things, these are almost always 1 or 2 cycles each. That means that although it may have to execute 3 instructions to do the same as 1 CISC instruction, it's often done it in half the clock cycles.
Also can't forget the conditional prefixes on instructions. Makes hacking on ARM code easy, but damn it makes things more complex.
ACPI is even easier and it's far more portable (that is, less specific to a given hardware configuration)
It's not at all hard to find a real practical purpose. If you take one step into the emulation world, it's all around you. Self-modifying code is not just the norm but an absolute requirement.
MySQL is the fastest DB engine... ?
Protected WMA, yes. They pay for the WMA licensing with portalplayer AFAIK.
These people need to learn the difference between codecs and DRM schemes. WMA support means the hardware can decode it, not decrypt the data. You're going to force Apple to license Microsoft's DRM? That's retarded.
I came.
Have you ever considered that it's not just memory state? You have to bring all devices to their previous state as well, which happens on a per-device basis. Please learn about what you're talking about before bitching. Thanks.
All that needs to be done to make PyMusique again is to reverse-engineer the algorithm used to encrypt the store pages behind ssl, the algorithm that manipulates their keys, and the simple algorithm used to encrypt the files as they're transferred from the store (before per-user DRM is applied).
:P )
Not very difficult at all, just a bit time consuming.
(From the original author of PyTunes, which PyMusique is a GUI frontend to
I got my start on Freenode many, many years ago, and now have been involved with dozens, possibly hundreds of projects, all on freenode. I've talked with Lilo many times and have never had a bad experience. One of the kindest and most helpful people I've ever met.
My Condolences go out to his family.
RIP lilo
You know what they call a quarter-pounder with cheese?