Try statically linking a program that uses just a few glibc calls and it's pushing 800k. Now add in libc++, Qt/gtk, Xlib, kde, boost, xml, etc and you're talking a lot of memory. This is what gets me about people who say "well Java performs okay now, but it uses so much memory".
A typical C/C++ based app uses just as much memory, it's just shared between processes. And for that matter, startup time of the first thing using kde/gnome isn't all that great either. Isn't it about time some effort was put into making Java or Mono part of the system, so it can be shared like C apps do?
Yes.NET falls into the "things like Java" category.
However, CLR does not have the potential to be as fast as Java on a multi-core processor since, due to it's native code interface and unsafe code, the GC can run less often in parallel with the other threads (it blocks significantly more often getting access to the pinned object memory). Also, CLR based applications have fewer opportunities for hotspot-like optimization due to its bytecode format being difficult to interpret efficiently; Java can run an optimizer on another core and get more use from the other processor in that way, and faster code. In addition, betas of the new JVM put temporary objects on the stack automatically (often detected as a result of optimization). This also allows the GC to run in parallel more often (.NET can only do this with value classes, ie structures, that the programmer has to explicitly declare... much like 'register' or other archaic attempts at optimization).
I've got a dual-core and it doesn't really help much since pretty much all the software I use regularly is single-threaded. Occasionally the disk io happens in another core from other processing, so for example rar'ing might be say 5% faster than on a single core. It is nice that I can rar huge file without impacting performance of the 'main' thing I am working on, but that doesn't happen very often.
Overall, the only thing I've really noticed that is significantly faster is Java. Most Java apps use threads, and if nothing else the GC seems to run on the 2nd CPU. For example, the graphics demo takes 100% of both cores if you set the delay to 0ms between frames. That's about the only program I've seen actually use both cores.
As a side note, I predict with more cores we will see greater use of things like Java. It may run at say 80% C speed, but 80% + 80% is still much more than 100% on one cpu and 0% on another.
Re:Dynamic typing
on
Beyond Java
·
· Score: 2, Insightful
The comparison of bug rates is false, because it assume the same programmers are doing work in both types of languages. They aren't.
Fundamentally, what you perceive as "power" or "expressibility" in a dynamically typed language is due to lack of structure. For example, in Smalltalk one can add a new method onto Object and then one can call this method on any instance of any type. This means you can solve some requirements in such a dynamically typed language in a very small amount of code, by tweaking how the system works.
But there is no free lunch. This "power" means that you cannot take an arbitrary program and know what it does without considering then entire system it resides in. Or in the dynamically-typed languages that do not allow modification of the common classes, you cannot usually take a subset of the program and know what it does without considering the entire whole. Static typing acts as a barrier, allowing code to be isolated from the rest.
You have to realize that, for the vast majority of programmers, that the structure is necessary. Those programmers working in dynamically-typed languages fail; they produce spaghetti. Sure, you *can* maintain structure in a dynamically typed language such as Smalltalk or Ruby. But programming is a constant struggle to keep the code from descending into chaos.... and the harder the language makes this the fewer that will be able to use it effectively. That's why these languages typically are used for scripting or for projects only done by an elite few of highly competent developers (fyi most web development work is basically scripting).
Why just virtualization? put a kernel and small initrd on windows' ntfs and it can mount a normal linux disto from a loopback file. Then you can dual boot, run linux as a user process, run in vmware-player, etc. The killer app would be a linux user distro that people can run like an app, wich a big "replace Windows" button that booted into it as the full os. You could even store user data in a separate loopback file and ship updates to the OS using rsync.
The only important difference to me is between natural and artificial minds. Whether it runs on a computer or not just affects whether it is simulated or real. This solves the upcoming problem over basic human rights too... only natural minds have human rights, whether real or simulated. So if somebody gets brain-scanned into a computer and simulated then they should have all the normal rights that other computer-minds will not have.
Of course the fact that we will soon be able to simulate a person's mind in a computer begs the question of whether we are also simulated without our even knowing it -- you know, mandelbrot style. Also, according to Occam's Razor this is the best explanation for quantum physics.
GPL <= 2 has a critical flaw at the top, in that you can recompile the code from source, but if you can never actually run that code then having the source is completely moot. So then the counter-attack to GPL is to restrict the hardward to only booting from authorized codes. Then you restrict the system to only run authorized codes; this could come first as a "warning: running unsigned code", then require admin privileges, and then just not run. Signing could be a quick, free, automatic online process that takes just seconds -- the point is to be able to revoke ability to run programs later or to specific users (for instance the authors of troublesome software).
Without this clause in the GPL, a company such as Intel or Dell can fork Linux, publish their code, but through signing only allow their compiles of the code to run on a system. That effectively prevents other people from changing code, so for example if it includes an audio driver that fingerprints its output and checks on the net to see if you have paid for the music then you can't play your mp3s you ripped previously. You can't remove that driver, you're stuck with it. Does that sound like open source to you?
With Intel's new boot system that Apple is using (and is a sure bet to be the future standard) the system can be restricted to only boot from certain signed code. These systems are shipping now. In a few years it will be possible to retro-fit systems (by Congressional fiat for example) to only boot an authorized os that only runs authorized code. People should realize this before criticizing GPL 3.
So under GPL 3 I can't make a kernel with hard-coded program keys/signatures... whoever gets my kernel code has to be able to generate and use their own. That is such an incredibly minor drawback compared to not being able to run any code at all without authorization.
Page 1: reference list of book opcodes Page 2: program to produce page 2 text... Page N: md5 sums of pages 2-N used to check for possible reading comprehension problems Epilogue: "Now grasshopper is one with computer."
Now that's a book that will let them know what computers are all about.
Another take on this could be that the Google Founders are using their market cap for good, by just controlling more of the advertising space.
For instance, recently Dean had a billboard all paid for and the contract signed, and it basically just said some republican congressman should focus on winning iraq instead of name-calling murtha/cleland/gore/etc. The ad was refused and the contract canceled, with no reason given other than the company just didn't want to put it up. Who knew it was legal/ethical/moral to accept swift boat style ads but reject fairly non-contentious ads from democrats? I wonder what radio ads have been rejected like this?
So as far as I'm concerned, the more google ads the better... err wiat a minute... well maybe they'll replace them with TTD radio ads that are easy to ignore.
What you said is true, but it also really sucks. Ximian and company could have made a JVM and classes, copying Sun instead of copying Microsoft. Lets be honest, the reason why they didn't is because Linux programmers are, by the large, antagonistic to Java. C#.NET is basically the same things as Java, only worse.
And that's the sad part. We get a crappy NamingConvention that does tell the reader anything, unlike Java's where the namingConvention actually tells the reader something useful (class vs method/variable). We get crappy delegates (method pointers) instead of inner classes, so your winforms for instance have many times more methods and it's just a mess. We get a bytecode format and native code interface basically make advanced optimizations like hotspot impossible, so making it fast is going to take a lot more work. You get C++-type generics that bloat the vm with types leading to slower operation (instanceof can take for freakin ever).... etc.
So mark this troll. Fine. And there are some good things about C# (like value types and properties), but mostly it is just a crappy copy of Java in a lot more ways. And it really sucks that the unix crowd are going to adopt it basically because of their bias and prejudice. It's ironic, but if Sun hadn't ported the jvm to linux we'd all be using an oss version of it now. And be better off for it.
Having actually *used* Reiser4 for a while I can give anecdotal evidence backing this benchmark showing very slow times (although the reality here is probably that it is updating the access time whereas the others weren't, or doing data journaling, something like that). I used r4 with gentoo, so LOTS of tiny files from portage, and vmware so lots of LARGE files that get their contents modified and occasionally expanded, and many emerge world so LOTS of opportunities to scatter data all over the disk.
At first and for a while reiser4 was blazing fast. I'd untar some source code and it would be done writing thousands of files before the return key was even released. But then it started getting *really* slow. More and more frequently the fs would, I presume, rebalance it's trees causing all IO to lock up for 10+ seconds. This was particularly annoying because doing ":wq" in vi would often cause this (I suppose due to a sync/fsync operation). Whatever reiser4 was doing in these lockups, it must not have succeded since it kept happening. All around, the performance just tanked. So if this guy's benchmarks recreated the conditions that cause reiser4 to asplode I can completely believe the results. I've since reformatted with ext3 and it's fairly fast, but mostly the benefit is that it is predictable and consistent.
Also I was using JFS once on a data-partition and was copying things around to redo the partitioning. I assume this is linux's fault, but the whole memory would fill up with unwritten data and then performance would tank almost as if the copies I was doing were reading 4k, then writing 4k (the source and dest were on different IDE chains so you'd think it would at least overlap these...). So I tried doing "while:; do sync; done" and amazingly this made the speed *much faster* (like 30mb/s I would expect instead of like 1mb/s after a while). Only problem is half-way through the jfs filesystem being copied to just gave up the ghost. No power fluctuation or loss, nothing. The files were just not there and I got error messages. Reboot and it couldn't even mount or fsck the jfs partition. Just another anecdote fyi... other than that jfs seems to rock hardcore.
This could be good for designing new filesystems for example to maximize throughput or minimize seeks. It's hard to get an overall feeling for how much work each design choice causes for the drive itself, especially with factors like automatically remapped dead sectors.
Helium is just a place-holder. You make some ships and prove that they work and are cheap, then you replace the helium with hydrogen. It can even be generated from the ship's fuel if there are slow leaks. The hindenberg's shell burned, not the hydrogen. Hydrogen can plenty safe in airships with the right designs... far safer than using thousands of gallons of jet fuel. You aren't going to shoot a hydrogen airship with a handgun (or a rocket for that matter) and have it explode.
"Current operating systems cannot leverage parralelism very well for anything but hyper-specialized applications." ...you freaking don't know what you are talking about. Windows and Linux are both multi-threaded operating systems. My copy of Windows XP 'leverages' paralellism just fine, as my CPU is dual core. The OS gets both CPUs working, all the time.
An operating system *could* compact and garbage collect an application's memory when it is blocked on IO. An operating system *could* do this with another CPU if there's a single-threaded program running (perhaps the algorithm in use doesn't allow for parallelism, for example a priority queue). An operating system *could* use a single memory map, so multiple processors could work in parallel at a finer-grained level more efficiently (ie without TLB flush overhead). An operating system *could* have a 50-cycle task switch instead of a 1200+ cycle task switch. An operating system *could* spend idle time specially-optimizing hotspots and critical paths for what the user is having the code actually do.
They don't because they are based on C and other unsafe, 'non-managed' languages. The vast majority of all processor time, single and multi, is spent idle and current operating system essentially do *nothing* with that time where they *could* be 'priming' the system for immediate responsiveness once things start moving again.
So saying Windows XP or Linux's use of multiple cpus is 'just fine' is either ignorant or pretty low standards.
Except those inequalites assume that information doesn't travel faster than light, which is almost certainly untrue of a classical simulation where any amount of information can travel in no time at all simply by pausing the simulation. They also assume that objects have a well defined state (ie complete information), which is also not typically true of simulations. Consider for instance that a simulation could keep quantum-level state in a cache of some sort. Then our experiments would 'succeed' in observing this cached data and the cached data would cause the expected overall effects.
What all this means is that if we are in a simulation then abusing the simulation environment may have no effects we could possibly perceive, but our actions (building person-sized teleporters for instance) may overload the simulation and cause it to be canceled / reset. Of course with a simulated universe this big, everything is bound to happen sooner or later...
It's much easier to learn object-oriented design from Java. Sun is basically an engineering company, and they make nice clean hardware and software from a theoretical standpoint. You'll see examples throughout the API and language, often with explanations why the design was chosen (for example why the collections are designed the way they are). You can read the discussions at the Java Community Process and find out why changes were made and what lesser designs were considered.
If you want to write okay code that works, VB-style, go with C#/.NET. Microsoft tends to slap together code in any way that works, without much thought to good design... or rather they just don't know good design (they have no sense of taste). You'll see a lot of marketing-inspired APIs and code that behaves strangely because it is tied to their old Win32 apis. But, your results will work better on Windows.
The real measure of Java's failure as an open, modern application programming platform is the fact that no desktop environment has adopted it
To me that's more of a failure of the desktop environments; we're stuck with C/C++ based ones because of network effects not because of merit. What sense does it make to program a window manager in Java when it has to speak X11 to actually do anything? I'd bet that there is nobody in the whole world who could program a ICCCM compliant window manager from scratch, from memory. So you would have to study some notoriously confusing spec to implement one in Java or port lots of low-level bit-flipping code from C. Or you could lift code from twm or other and start hacking on it, which is what people do.
If one of the major desktop environments were implemented in Java, it would represent a massive victory. If not, it's more likely than not just another sad but understandable failure of markets, like the dvorak keyboard for instance.
And List> is a subtype of List> which basically means that you have as many types as there are uses of the generic class. That's the C++ school of thought, which just takes it one step further and generates code for each (most) uses. I could load one class that creates an arbitrary number of new types within the JVM. That's very bad from a practical standpoint.
So then is Hashtable<B,B> a subtype of Hashtable<B,A> and Hashtable<A,B>, which is multiple inheritance, or a subtype of Hashtable<A,A>, which leads to basically a parallel tree of types over every independent variable in every generic type and recursively since parameters can themselves be generic types? All this basically means that it is extremely hard to do instanceof operations in any reasonable time.
So are Java's generics really so bad, or are they just one of another good compromise between practicality and formalism that makes Java so great? I say the latter.
The language shootout is fundamentally flawed when it comes to Java performance. I've written about this before, but basically it measures the time for a fixed number of iterations instead of throughput in a given time. So, the difference in fast languages is dominated by the much smaller differences in startup time (only very grossly accounted for in the benchmark) and for slow languages it results in fewer datapoints, where the program took too long and was killed).
C typically ranges from 1.2x to 4x faster than Java. It's a huge mistake to group Java in with other bytecode engines since due to the IP advantage (hotspot, stack allocations, etc) Java is far faster. So in other words if the average for bytecode engines is 7-12, the others are much slower than 7-12 and Java much faster.
The proper grouping is compiled languages, static bytecode engines, dynamic bytecode engines, and interpreters. Of course a language can be implemented in more than one of those categories, for example Java can run on any of those four categories (compiled with gcj). Python/Ruby cannot be compiled or run under a static bytecode engine since they are dynamic languages.
Check sourceforge... the majority of Java projects are not in the Web category of trove. Azureus is not a web application. Gcj and classpath now have about 95% of the Java core implemented as totally free software. Your post is just not based on the facts.
Java generics are not deeply flawed, except for making the classic C++ mistake of having generic variables identified with letters (ie, "public class List {... A getIndex(int index)... };" wtf does A mean?). But that's where Java's generics shine: if you don't want to use them, just don't use them. You can use somebody's library who used generics without you also having to. It's not a language virus like C# generics are.
The scientific community is still often using FORTRAN for heaven's sake. I think blaming Sun for not doing what nobody else could (or wanted to) do either is more than a bit of a rant.
Seriously what competition is there for Java other than C#? Java beats C# hands down in terms of performance (C# only competes because a significant part of its standard API is written in C), and the betas already put objects on the stack instead of allocating them, which will make it the speed of C for pretty much all real code. These algorithms are patented, and C# bytecode is less friendly to dynamic optimizations such as those, so C# has a huge uphill battle in that regard. With java 1.5's syntax additions, C#'s winning on ease of coding is debatable... properties vs having to specifically mark methods overridden methods.
That's why Java has been so successful. It made a compromise between performance and ease. It made a compromise between compiled and interpreted. It made a compromise between local applications and applets. It made a compromise between easy-of-use and formalism.
C++, which Bruce used to love, made *no* compromises, except to run C code. It wanted to include anything possible as long as it was fast, and it did except that it was so freakin complicated that even to this day sometimes compilers can't interpret the source correctly. In the same way, Ruby (and Smalltalk) also do not make compromises. They say 'everything is an object' even though that means computations are 20x slower even after decades of optimization. They say 'no type checking' (if it acts like a duck it is) even though it is pretty much a necessity for large or reliable systems.
Regardless of the level of hype, the real world of programming is about compromises. It's about Java, and C#. Sure there will be plenty of work at the edges for Ruby/Smalltalk and C++/C, but Java-like languages will be the center of programming for decades yet.
The real lockdown could happen right now if the industries actually embraced technology like the internet. All you need to do is embed an individualized watermark in a movie or sound file that can survive most A/D conversions. Then you just download the files on P2P and sue the person who ripped it (you know who they are because when you apply the watermarks you save the customer info).
The coding can be varied regularly before tools are developed to remove it, so only 'old' content can be copied without fear of lawsuit. But even then you have to wonder what 'stealth code' is in the movie that hasn't been detected yet. I mean it took like 20 years to analyze the laser printer codes. It could be as simple as missing frames scattered though a movie, or turning off the 'pitch correction machine' for a split second on Brittainy cds.
Slashdot Mirror
Try statically linking a program that uses just a few glibc calls and it's pushing 800k. Now add in libc++, Qt/gtk, Xlib, kde, boost, xml, etc and you're talking a lot of memory. This is what gets me about people who say "well Java performs okay now, but it uses so much memory".
A typical C/C++ based app uses just as much memory, it's just shared between processes. And for that matter, startup time of the first thing using kde/gnome isn't all that great either. Isn't it about time some effort was put into making Java or Mono part of the system, so it can be shared like C apps do?
Yes .NET falls into the "things like Java" category.
However, CLR does not have the potential to be as fast as Java on a multi-core processor since, due to it's native code interface and unsafe code, the GC can run less often in parallel with the other threads (it blocks significantly more often getting access to the pinned object memory). Also, CLR based applications have fewer opportunities for hotspot-like optimization due to its bytecode format being difficult to interpret efficiently; Java can run an optimizer on another core and get more use from the other processor in that way, and faster code. In addition, betas of the new JVM put temporary objects on the stack automatically (often detected as a result of optimization). This also allows the GC to run in parallel more often (.NET can only do this with value classes, ie structures, that the programmer has to explicitly declare... much like 'register' or other archaic attempts at optimization).
Not a big multitasker eh? I run linux. And I have kernel preemption turned on. So I don't really understand the question?
I've got a dual-core and it doesn't really help much since pretty much all the software I use regularly is single-threaded. Occasionally the disk io happens in another core from other processing, so for example rar'ing might be say 5% faster than on a single core. It is nice that I can rar huge file without impacting performance of the 'main' thing I am working on, but that doesn't happen very often.
Overall, the only thing I've really noticed that is significantly faster is Java. Most Java apps use threads, and if nothing else the GC seems to run on the 2nd CPU. For example, the graphics demo takes 100% of both cores if you set the delay to 0ms between frames. That's about the only program I've seen actually use both cores.
As a side note, I predict with more cores we will see greater use of things like Java. It may run at say 80% C speed, but 80% + 80% is still much more than 100% on one cpu and 0% on another.
The comparison of bug rates is false, because it assume the same programmers are doing work in both types of languages. They aren't.
Fundamentally, what you perceive as "power" or "expressibility" in a dynamically typed language is due to lack of structure. For example, in Smalltalk one can add a new method onto Object and then one can call this method on any instance of any type. This means you can solve some requirements in such a dynamically typed language in a very small amount of code, by tweaking how the system works.
But there is no free lunch. This "power" means that you cannot take an arbitrary program and know what it does without considering then entire system it resides in. Or in the dynamically-typed languages that do not allow modification of the common classes, you cannot usually take a subset of the program and know what it does without considering the entire whole. Static typing acts as a barrier, allowing code to be isolated from the rest.
You have to realize that, for the vast majority of programmers, that the structure is necessary. Those programmers working in dynamically-typed languages fail; they produce spaghetti. Sure, you *can* maintain structure in a dynamically typed language such as Smalltalk or Ruby. But programming is a constant struggle to keep the code from descending into chaos.... and the harder the language makes this the fewer that will be able to use it effectively. That's why these languages typically are used for scripting or for projects only done by an elite few of highly competent developers (fyi most web development work is basically scripting).
Why just virtualization? put a kernel and small initrd on windows' ntfs and it can mount a normal linux disto from a loopback file. Then you can dual boot, run linux as a user process, run in vmware-player, etc. The killer app would be a linux user distro that people can run like an app, wich a big "replace Windows" button that booted into it as the full os. You could even store user data in a separate loopback file and ship updates to the OS using rsync.
The only important difference to me is between natural and artificial minds. Whether it runs on a computer or not just affects whether it is simulated or real. This solves the upcoming problem over basic human rights too... only natural minds have human rights, whether real or simulated. So if somebody gets brain-scanned into a computer and simulated then they should have all the normal rights that other computer-minds will not have.
Of course the fact that we will soon be able to simulate a person's mind in a computer begs the question of whether we are also simulated without our even knowing it -- you know, mandelbrot style. Also, according to Occam's Razor this is the best explanation for quantum physics.
GPL <= 2 has a critical flaw at the top, in that you can recompile the code from source, but if you can never actually run that code then having the source is completely moot. So then the counter-attack to GPL is to restrict the hardward to only booting from authorized codes. Then you restrict the system to only run authorized codes; this could come first as a "warning: running unsigned code", then require admin privileges, and then just not run. Signing could be a quick, free, automatic online process that takes just seconds -- the point is to be able to revoke ability to run programs later or to specific users (for instance the authors of troublesome software).
Without this clause in the GPL, a company such as Intel or Dell can fork Linux, publish their code, but through signing only allow their compiles of the code to run on a system. That effectively prevents other people from changing code, so for example if it includes an audio driver that fingerprints its output and checks on the net to see if you have paid for the music then you can't play your mp3s you ripped previously. You can't remove that driver, you're stuck with it. Does that sound like open source to you?
With Intel's new boot system that Apple is using (and is a sure bet to be the future standard) the system can be restricted to only boot from certain signed code. These systems are shipping now. In a few years it will be possible to retro-fit systems (by Congressional fiat for example) to only boot an authorized os that only runs authorized code. People should realize this before criticizing GPL 3.
So under GPL 3 I can't make a kernel with hard-coded program keys/signatures... whoever gets my kernel code has to be able to generate and use their own. That is such an incredibly minor drawback compared to not being able to run any code at all without authorization.
Page 1: reference list of book opcodes ...
Page 2: program to produce page 2 text
Page N: md5 sums of pages 2-N used to check for possible reading comprehension problems
Epilogue: "Now grasshopper is one with computer."
Now that's a book that will let them know what computers are all about.
Another take on this could be that the Google Founders are using their market cap for good, by just controlling more of the advertising space.
For instance, recently Dean had a billboard all paid for and the contract signed, and it basically just said some republican congressman should focus on winning iraq instead of name-calling murtha/cleland/gore/etc. The ad was refused and the contract canceled, with no reason given other than the company just didn't want to put it up. Who knew it was legal/ethical/moral to accept swift boat style ads but reject fairly non-contentious ads from democrats? I wonder what radio ads have been rejected like this?
So as far as I'm concerned, the more google ads the better... err wiat a minute... well maybe they'll replace them with TTD radio ads that are easy to ignore.
And I'm sure "TacoCmdr" logged into World of Warcraft all day has nothing to do with it... right...
What you said is true, but it also really sucks. Ximian and company could have made a JVM and classes, copying Sun instead of copying Microsoft. Lets be honest, the reason why they didn't is because Linux programmers are, by the large, antagonistic to Java. C#.NET is basically the same things as Java, only worse.
... etc.
And that's the sad part. We get a crappy NamingConvention that does tell the reader anything, unlike Java's where the namingConvention actually tells the reader something useful (class vs method/variable). We get crappy delegates (method pointers) instead of inner classes, so your winforms for instance have many times more methods and it's just a mess. We get a bytecode format and native code interface basically make advanced optimizations like hotspot impossible, so making it fast is going to take a lot more work. You get C++-type generics that bloat the vm with types leading to slower operation (instanceof can take for freakin ever).
So mark this troll. Fine. And there are some good things about C# (like value types and properties), but mostly it is just a crappy copy of Java in a lot more ways. And it really sucks that the unix crowd are going to adopt it basically because of their bias and prejudice. It's ironic, but if Sun hadn't ported the jvm to linux we'd all be using an oss version of it now. And be better off for it.
Having actually *used* Reiser4 for a while I can give anecdotal evidence backing this benchmark showing very slow times (although the reality here is probably that it is updating the access time whereas the others weren't, or doing data journaling, something like that). I used r4 with gentoo, so LOTS of tiny files from portage, and vmware so lots of LARGE files that get their contents modified and occasionally expanded, and many emerge world so LOTS of opportunities to scatter data all over the disk.
:; do sync; done" and amazingly this made the speed *much faster* (like 30mb/s I would expect instead of like 1mb/s after a while). Only problem is half-way through the jfs filesystem being copied to just gave up the ghost. No power fluctuation or loss, nothing. The files were just not there and I got error messages. Reboot and it couldn't even mount or fsck the jfs partition. Just another anecdote fyi... other than that jfs seems to rock hardcore.
At first and for a while reiser4 was blazing fast. I'd untar some source code and it would be done writing thousands of files before the return key was even released. But then it started getting *really* slow. More and more frequently the fs would, I presume, rebalance it's trees causing all IO to lock up for 10+ seconds. This was particularly annoying because doing ":wq" in vi would often cause this (I suppose due to a sync/fsync operation). Whatever reiser4 was doing in these lockups, it must not have succeded since it kept happening. All around, the performance just tanked. So if this guy's benchmarks recreated the conditions that cause reiser4 to asplode I can completely believe the results. I've since reformatted with ext3 and it's fairly fast, but mostly the benefit is that it is predictable and consistent.
Also I was using JFS once on a data-partition and was copying things around to redo the partitioning. I assume this is linux's fault, but the whole memory would fill up with unwritten data and then performance would tank almost as if the copies I was doing were reading 4k, then writing 4k (the source and dest were on different IDE chains so you'd think it would at least overlap these...). So I tried doing "while
This could be good for designing new filesystems for example to maximize throughput or minimize seeks. It's hard to get an overall feeling for how much work each design choice causes for the drive itself, especially with factors like automatically remapped dead sectors.
Helium is just a place-holder. You make some ships and prove that they work and are cheap, then you replace the helium with hydrogen. It can even be generated from the ship's fuel if there are slow leaks. The hindenberg's shell burned, not the hydrogen. Hydrogen can plenty safe in airships with the right designs... far safer than using thousands of gallons of jet fuel. You aren't going to shoot a hydrogen airship with a handgun (or a rocket for that matter) and have it explode.
Or you could just compress the helium. And if the tank is inside the "air-sub" theb loss from helium leaking through the container would be minimized.
An operating system *could* compact and garbage collect an application's memory when it is blocked on IO. An operating system *could* do this with another CPU if there's a single-threaded program running (perhaps the algorithm in use doesn't allow for parallelism, for example a priority queue). An operating system *could* use a single memory map, so multiple processors could work in parallel at a finer-grained level more efficiently (ie without TLB flush overhead). An operating system *could* have a 50-cycle task switch instead of a 1200+ cycle task switch. An operating system *could* spend idle time specially-optimizing hotspots and critical paths for what the user is having the code actually do.
They don't because they are based on C and other unsafe, 'non-managed' languages. The vast majority of all processor time, single and multi, is spent idle and current operating system essentially do *nothing* with that time where they *could* be 'priming' the system for immediate responsiveness once things start moving again.
So saying Windows XP or Linux's use of multiple cpus is 'just fine' is either ignorant or pretty low standards.
Except those inequalites assume that information doesn't travel faster than light, which is almost certainly untrue of a classical simulation where any amount of information can travel in no time at all simply by pausing the simulation. They also assume that objects have a well defined state (ie complete information), which is also not typically true of simulations. Consider for instance that a simulation could keep quantum-level state in a cache of some sort. Then our experiments would 'succeed' in observing this cached data and the cached data would cause the expected overall effects.
What all this means is that if we are in a simulation then abusing the simulation environment may have no effects we could possibly perceive, but our actions (building person-sized teleporters for instance) may overload the simulation and cause it to be canceled / reset. Of course with a simulated universe this big, everything is bound to happen sooner or later...
It's much easier to learn object-oriented design from Java. Sun is basically an engineering company, and they make nice clean hardware and software from a theoretical standpoint. You'll see examples throughout the API and language, often with explanations why the design was chosen (for example why the collections are designed the way they are). You can read the discussions at the Java Community Process and find out why changes were made and what lesser designs were considered.
If you want to write okay code that works, VB-style, go with C#/.NET. Microsoft tends to slap together code in any way that works, without much thought to good design... or rather they just don't know good design (they have no sense of taste). You'll see a lot of marketing-inspired APIs and code that behaves strangely because it is tied to their old Win32 apis. But, your results will work better on Windows.
The real measure of Java's failure as an open, modern application programming platform is the fact that no desktop environment has adopted it
To me that's more of a failure of the desktop environments; we're stuck with C/C++ based ones because of network effects not because of merit. What sense does it make to program a window manager in Java when it has to speak X11 to actually do anything? I'd bet that there is nobody in the whole world who could program a ICCCM compliant window manager from scratch, from memory. So you would have to study some notoriously confusing spec to implement one in Java or port lots of low-level bit-flipping code from C. Or you could lift code from twm or other and start hacking on it, which is what people do.
If one of the major desktop environments were implemented in Java, it would represent a massive victory. If not, it's more likely than not just another sad but understandable failure of markets, like the dvorak keyboard for instance.
And List> is a subtype of List> which basically means that you have as many types as there are uses of the generic class. That's the C++ school of thought, which just takes it one step further and generates code for each (most) uses. I could load one class that creates an arbitrary number of new types within the JVM. That's very bad from a practical standpoint.
So then is Hashtable<B,B> a subtype of Hashtable<B,A> and Hashtable<A,B>, which is multiple inheritance, or a subtype of Hashtable<A,A>, which leads to basically a parallel tree of types over every independent variable in every generic type and recursively since parameters can themselves be generic types? All this basically means that it is extremely hard to do instanceof operations in any reasonable time.
So are Java's generics really so bad, or are they just one of another good compromise between practicality and formalism that makes Java so great? I say the latter.
The language shootout is fundamentally flawed when it comes to Java performance. I've written about this before, but basically it measures the time for a fixed number of iterations instead of throughput in a given time. So, the difference in fast languages is dominated by the much smaller differences in startup time (only very grossly accounted for in the benchmark) and for slow languages it results in fewer datapoints, where the program took too long and was killed).
C typically ranges from 1.2x to 4x faster than Java. It's a huge mistake to group Java in with other bytecode engines since due to the IP advantage (hotspot, stack allocations, etc) Java is far faster. So in other words if the average for bytecode engines is 7-12, the others are much slower than 7-12 and Java much faster.
The proper grouping is compiled languages, static bytecode engines, dynamic bytecode engines, and interpreters. Of course a language can be implemented in more than one of those categories, for example Java can run on any of those four categories (compiled with gcj). Python/Ruby cannot be compiled or run under a static bytecode engine since they are dynamic languages.
Check sourceforge... the majority of Java projects are not in the Web category of trove. Azureus is not a web application. Gcj and classpath now have about 95% of the Java core implemented as totally free software. Your post is just not based on the facts.
... A getIndex(int index) ... };" wtf does A mean?). But that's where Java's generics shine: if you don't want to use them, just don't use them. You can use somebody's library who used generics without you also having to. It's not a language virus like C# generics are.
Java generics are not deeply flawed, except for making the classic C++ mistake of having generic variables identified with letters (ie, "public class List {
The scientific community is still often using FORTRAN for heaven's sake. I think blaming Sun for not doing what nobody else could (or wanted to) do either is more than a bit of a rant.
Seriously what competition is there for Java other than C#? Java beats C# hands down in terms of performance (C# only competes because a significant part of its standard API is written in C), and the betas already put objects on the stack instead of allocating them, which will make it the speed of C for pretty much all real code. These algorithms are patented, and C# bytecode is less friendly to dynamic optimizations such as those, so C# has a huge uphill battle in that regard. With java 1.5's syntax additions, C#'s winning on ease of coding is debatable... properties vs having to specifically mark methods overridden methods.
That's why Java has been so successful. It made a compromise between performance and ease. It made a compromise between compiled and interpreted. It made a compromise between local applications and applets. It made a compromise between easy-of-use and formalism.
C++, which Bruce used to love, made *no* compromises, except to run C code. It wanted to include anything possible as long as it was fast, and it did except that it was so freakin complicated that even to this day sometimes compilers can't interpret the source correctly. In the same way, Ruby (and Smalltalk) also do not make compromises. They say 'everything is an object' even though that means computations are 20x slower even after decades of optimization. They say 'no type checking' (if it acts like a duck it is) even though it is pretty much a necessity for large or reliable systems.
Regardless of the level of hype, the real world of programming is about compromises. It's about Java, and C#. Sure there will be plenty of work at the edges for Ruby/Smalltalk and C++/C, but Java-like languages will be the center of programming for decades yet.
The real lockdown could happen right now if the industries actually embraced technology like the internet. All you need to do is embed an individualized watermark in a movie or sound file that can survive most A/D conversions. Then you just download the files on P2P and sue the person who ripped it (you know who they are because when you apply the watermarks you save the customer info).
The coding can be varied regularly before tools are developed to remove it, so only 'old' content can be copied without fear of lawsuit. But even then you have to wonder what 'stealth code' is in the movie that hasn't been detected yet. I mean it took like 20 years to analyze the laser printer codes. It could be as simple as missing frames scattered though a movie, or turning off the 'pitch correction machine' for a split second on Brittainy cds.