I usually take "released" to mean there is an implementation that is publicly available. Unless I am somehow just missing it, it doesn't seem to have been released yet...
87% does seem surprisingly high. For some reason I thought only vector machines like Earth Simulator and Cray could get that close to theoretical peak performance, while clustered microprocessors languished at 75% and below.
But now that I think about it, wouldn't the ratio be driven primarily by link bandwidth, not processor architecture?
Jack originally believed that the images found on his computer were from a previous owner -- he'd bought the machine on an eBay auction. But he now thinks a browser hijacker may have been responsible.
If he was really getting pounded with tons of porn popups whenever he started a browser, why would he ever have believed the images were from a previous owner? Sounds like he's jumping on a convenient new excuse that happens to be making the rounds in the media.
So when both boxes are idle the PM is taking 6W and the Athlon-XP is basically taking the full power.
That seems a little hard to believe. If that were the case, Athlon XP's would have the same temperature at full load as they do at idle, and that's certainly not the case.
Check out the VGC-RAxx desktops... pretty slick looking. Looks like there is some crazy cooling scheme going on too, with air intake slots in the middle of the chassis and a heatpipe CPU cooler; check out these pics.
Interesting how P4 Northwood did so well against Athlon XP, mainly because of Intel's "speed demon" approach (trading IPC for higher clock speeds). Whereas Pentium-M brings them back in line with the kinds of IPC we see from AMD and IBM.
I won't pretend I know anything more about CPU design, maybe someone who does can comment on whether this means Intel made a bad bet with the long pipelines or whether there's some other reason why P-M holds more promise than P4...?
I think it's also a little bit of a stretch to call that "six lines" of perl code. To most programmers that would imply, more or less, six statements... looks like there are just a lot of hard returns missing where, in any other context, any sane programmer would put them in.
Not that it's not still a really nifty piece of code.
I've spent most of the past 5 years doing Java-based web development. I fully agree that PHP is a nightmare compared to (insert favorite combination of Java frameworks and toolkits here).
However, I think ASP.NET is better. It's a huge shift from ASP; you could say ASP to ASP.NET is like PHP to JSF. (In fact, I believe JSF was created entirely as a response to ASP.NET, though they didn't do nearly as nice a job.) ASP was (iirc) a fully interpreted HTML embedded language. ASP.NET pages are precompiled (a la JSP) and represent much more than embedded code; it is a rich framework for transparently mapping client state and events onto the server side, and provides extremely clean mechanisms to react to those events in ways that modify the UI.
I do a lot of rich client GUI work now, the kind of work where those MVC patterns originated, and I can tell you for sure that ASP.NET makes it possible to track much more closely to that model than you can with the current state of the art in Java land.
Big caveat: I do have to admit I haven't actually used ASP.NET for a real app, only read the book and played around with it. (For all the elegance of the framework and programming model, I can't bear the thought of actually deploying a webapp on a Windows server.) But everyone I've talked to who has done both Java and ASP.NET development has thought the latter was better.
You should definitely at least learn JSP first. For all its faults, it's still the standard templating mechanism for J2EE, and you can't really call yourself a Java web developer if you don't know it.
Once you learn it and loathe it, then you can move on to others.
I personally think GroovyPages looks like it could be a much better solution than anything else I've seen in the Java world. But then I like having the option to write powerful code in the presentation layer, while the whole point of Velocity is to take that power away from you.
Regarding the problem in the journal entry linked from your sig, you can use JavaScript to emit the HTML.
<script language="JavaScript"> a = "crosoft.com"; b = "bi"; c = "llg@mi"; d = b + c + a; document.write('<a href="mailto:' + d + '">' + d + '</a>'); </script> <noscript>Turn on JavaScript to see my e-mail address.</noscript>
Unless the spambot actually interprets JavaScript, it won't detect your e-mail address.
I've only had an account with them for a few weeks, but so far, VPSCenter.com has been great; $19.95 for 2GB and 25GB xfer. They use H-Sphere as their control panel software. (I didn't know about linode though.)
Sorry, I didn't realize you were talking about containers of non-primitives. I agree that the fact that C# jits distinct native code based on primitive types does not, in and of itself, make the non-primitive case any faster.
Though, AC poster at this level pointed out that the fact that the CLR does not erase the type information the way the JVM does could let you skip a cast. (Not likely to make much of a difference, IMO...)
Yes, but this is apparently because it is *better written*, not "because it can do primitives" which the Slashdot writeup suggests. In theory it could be slightly faster if it *didn't* do primitives due to some slight simplification of the generics code (though if intelligently written it would just be the same speed as now).
This is not true at all. C# generics can be faster for primitives because the JITter compiles a separate native image when the type parameter is a primitive. It sounds like you think the generic collection classes in C# have some kind of conditional logic in it to deal with primitives vs. objects. In fact it's nothing like that... the JIT compiler separates the different cases out at JIT time, and creates distinct classes in memory as necessary. The classes that target primitives, unlike their Java counterparts, don't need primitive values to be boxed/wrapped... so they can be faster and use less memory.
The only (good) reason Java doesn't support this in their impl of generics is for backward compatibility with older JVM's.
It's not simply that primitives go through optimized code in collections. Primitives in Java are fundamentally different than objects in that they are stored inline with their context (either the stack, an array, or the object they're a member of), whereas objects are always referred to by reference and stored somewhere on the heap.
<oversimplification>So for example, an int[10] takes 40 contiguous bytes (4 bytes per int) on the heap. That block contains the actual values of the ints. An Integer[10] also takes 40 continguous bytes on the heap, but now those are just references (4 bytes per object ref, on x86 at least) to 10 4-byte blocks, potentially scattered around the heap.</oversimplification>
Imagine how much longer it takes to compare two Integer[]'s than two int[]'s. The former involves a following a reference to get each value, the latter is just pointer addition. Furthermore, primitives allow the JIT compiler to create far more optimized native code. (Your hypothetical "bit of work" would have to fall back any time a public method takes an int argument, and ripple from there on inward whenever that reference is passed.)
Not to say there isn't a class of problems/programmers for which subclassable "primitives" may be appropriate and valuable. If you truly find yourself in that situation, it might be time to consider Python or Ruby.
In C#, no conversion/wrapping/boxing, whether manual or automatic, will be necessary. The parameterized type will actually store the values in their unvarnished, primitive form.
C# generics are smart enough to treat value types differently than reference types (or what you're calling a "first class Object"), while Java generics are not.
For as long as I have been a Java programmer (4 years) at least, there have been collection libraries for Java that are specialized for primitive types. One of their main reasons for existence is to avoid the performance overhead of boxing.
You can get a very rough idea of the performance gain here (scroll down to "Trove Primitive Collections"). It's a significant difference.
Of course, for most apps that people are writing for Java (i.e. webapps for business), an optimization of this magnitude won't be noticable--all the time is spent in the DB or network. On the other hand, IIUC, MS intends to write large sections of Longhorn in C#.
I hope you're being sarcastic. Take a look at her accomplishments at Lucent. She's the one who made them practically a household name.
And at least give her credit for getting the merger done, in spite of Walter Hewlett throwing all of his force behind stopping it.
She's taken a huge risk with HP, and we'll all have to wait and see whether she was right. But either way I think so far she's done a commendable job. There's a reason she's the most powerful female in American business.
I think designers will be most affected by this in relation to Flash. There's plenty you can do in Flash that would be inconvenient or impossible to do in js/DHTML. And Linux and Mac users can use Flash.
We use Connected at the small software startup I work for, and it pisses the hell out of me. The main reason is because the client software is kind of kludgy. It's much harder than it should be to specify that you want to backup a certain set of folders--you basically have to mess with inclusion/exclusion rules. And when a backup begins at the worst possible time, as it is wont to do, it often takes a LONG time between you clicking Cancel and it actually deciding to cancel.
OTOH, the situation is exacerbated by the fact that I am a software programmer on a laptop. In other words, all day we need all the performance we can get, and then at night the laptops aren't on/connected. I imagine if you are backing up desktop machines, you can just set it to run at 3am every night and forget it, and never see the client software.
It's actually not very hard or expensive (I guess that's relative) to build a relatively quiet P4 or Athlon based system. Heatsink manufacturers are getting quite good at building thin-fin copper/aluminum heatsinks with big slow fans on them {123}. Or even without any fan at all.
VIA now offers an EPIA board that takes a P4 or Celeron (only up to 533MHz frontside bus though). At $185 (mobo only), it's a lot pricier than their C3 based solutions (which are IIRC $100-150 with proc included), but throw a P4 2.6GHz in there and you won't be "just a little short of processor horsepower" for anything.;)
When operating on native integer types, Java does in fact perform comparably to compiled code - as it should, since the JIT compilers should produce very very similar code.
True, but it's worth pointing out that once you start talking about arrays of ints, the picture changes dramatically since Java does runtime checks for out-of-bounds conditions on every array access.
GC is required, and is slower than heap management.
Just a technicality, but, my understanding is that GC is actually faster than heap management (at least in theory). With GC, you don't pay for memory deallocation until you need it, and when that time comes, the cost is proportional not to the amount of garbage you've created, but to the amount of non-garbage that needs to be preserved. (That's true with copying garbage collectors, at least, which is the kind Sun's JVM uses most often.) And since most real-world apps' memory usage patterns tend to create 10X more short-lived objects than long-lived ones, you should be able to end up with a net savings most of the time by using GC.
Maybe what you meant was that GC is slower than stack management, or that GC causes unpredictable pauses during long "stop-the-world" collection operations (that plagued early versions of Java but are pretty rare now, due to some hard work by the folks at Sun).
-lack of documented/fixed object layout precludes direct memory manipulation of data - mostly a problem in I/O. This makes block-based I/O virtually impossible without serializing.
I'm not familiar with this problem. Could you elaborate?
-The 'Design Patterns' that have been adopted as Gospel by most in the Java community (at least the J2EE community) are very inefficient - too many layers, too much indirection, too many object copies etc.
I hate J2EE "Design Patterns" too, but in most real world enterprise apps, your performance is generally going to be totally dominated by either network I/O or database queries--stuff like in-memory object copies or indirection is like line noise.
Slashdot Mirror
I usually take "released" to mean there is an implementation that is publicly available. Unless I am somehow just missing it, it doesn't seem to have been released yet...
87% does seem surprisingly high. For some reason I thought only vector machines like Earth Simulator and Cray could get that close to theoretical peak performance, while clustered microprocessors languished at 75% and below.
But now that I think about it, wouldn't the ratio be driven primarily by link bandwidth, not processor architecture?
Jack originally believed that the images found on his computer were from a previous owner -- he'd bought the machine on an eBay auction. But he now thinks a browser hijacker may have been responsible.
If he was really getting pounded with tons of porn popups whenever he started a browser, why would he ever have believed the images were from a previous owner? Sounds like he's jumping on a convenient new excuse that happens to be making the rounds in the media.
So when both boxes are idle the PM is taking 6W and the Athlon-XP is basically taking the full power. That seems a little hard to believe. If that were the case, Athlon XP's would have the same temperature at full load as they do at idle, and that's certainly not the case.
Check out the VGC-RAxx desktops... pretty slick looking. Looks like there is some crazy cooling scheme going on too, with air intake slots in the middle of the chassis and a heatpipe CPU cooler; check out these pics.
And VIA's EPIA processors are all named after Old Testament prophets: Samuel, Ezra, Nehemiah...
Interesting how P4 Northwood did so well against Athlon XP, mainly because of Intel's "speed demon" approach (trading IPC for higher clock speeds). Whereas Pentium-M brings them back in line with the kinds of IPC we see from AMD and IBM.
I won't pretend I know anything more about CPU design, maybe someone who does can comment on whether this means Intel made a bad bet with the long pipelines or whether there's some other reason why P-M holds more promise than P4...?
Not that it's not still a really nifty piece of code.
However, I think ASP.NET is better. It's a huge shift from ASP; you could say ASP to ASP.NET is like PHP to JSF. (In fact, I believe JSF was created entirely as a response to ASP.NET, though they didn't do nearly as nice a job.) ASP was (iirc) a fully interpreted HTML embedded language. ASP.NET pages are precompiled (a la JSP) and represent much more than embedded code; it is a rich framework for transparently mapping client state and events onto the server side, and provides extremely clean mechanisms to react to those events in ways that modify the UI.
I do a lot of rich client GUI work now, the kind of work where those MVC patterns originated, and I can tell you for sure that ASP.NET makes it possible to track much more closely to that model than you can with the current state of the art in Java land.
Big caveat: I do have to admit I haven't actually used ASP.NET for a real app, only read the book and played around with it. (For all the elegance of the framework and programming model, I can't bear the thought of actually deploying a webapp on a Windows server.) But everyone I've talked to who has done both Java and ASP.NET development has thought the latter was better.
You should definitely at least learn JSP first. For all its faults, it's still the standard templating mechanism for J2EE, and you can't really call yourself a Java web developer if you don't know it.
Once you learn it and loathe it, then you can move on to others.
I personally think GroovyPages looks like it could be a much better solution than anything else I've seen in the Java world. But then I like having the option to write powerful code in the presentation layer, while the whole point of Velocity is to take that power away from you.
Regarding the problem in the journal entry linked from your sig, you can use JavaScript to emit the HTML.
Unless the spambot actually interprets JavaScript, it won't detect your e-mail address.
I've only had an account with them for a few weeks, but so far, VPSCenter.com has been great; $19.95 for 2GB and 25GB xfer. They use H-Sphere as their control panel software. (I didn't know about linode though.)
Though, AC poster at this level pointed out that the fact that the CLR does not erase the type information the way the JVM does could let you skip a cast. (Not likely to make much of a difference, IMO...)
This is not true at all. C# generics can be faster for primitives because the JITter compiles a separate native image when the type parameter is a primitive. It sounds like you think the generic collection classes in C# have some kind of conditional logic in it to deal with primitives vs. objects. In fact it's nothing like that... the JIT compiler separates the different cases out at JIT time, and creates distinct classes in memory as necessary. The classes that target primitives, unlike their Java counterparts, don't need primitive values to be boxed/wrapped... so they can be faster and use less memory.
The only (good) reason Java doesn't support this in their impl of generics is for backward compatibility with older JVM's.
<oversimplification>So for example, an int[10] takes 40 contiguous bytes (4 bytes per int) on the heap. That block contains the actual values of the ints. An Integer[10] also takes 40 continguous bytes on the heap, but now those are just references (4 bytes per object ref, on x86 at least) to 10 4-byte blocks, potentially scattered around the heap.</oversimplification>
Imagine how much longer it takes to compare two Integer[]'s than two int[]'s. The former involves a following a reference to get each value, the latter is just pointer addition. Furthermore, primitives allow the JIT compiler to create far more optimized native code. (Your hypothetical "bit of work" would have to fall back any time a public method takes an int argument, and ripple from there on inward whenever that reference is passed.)
Not to say there isn't a class of problems/programmers for which subclassable "primitives" may be appropriate and valuable. If you truly find yourself in that situation, it might be time to consider Python or Ruby.
C# generics are smart enough to treat value types differently than reference types (or what you're calling a "first class Object"), while Java generics are not.
You can get a very rough idea of the performance gain here (scroll down to "Trove Primitive Collections"). It's a significant difference.
Of course, for most apps that people are writing for Java (i.e. webapps for business), an optimization of this magnitude won't be noticable--all the time is spent in the DB or network. On the other hand, IIUC, MS intends to write large sections of Longhorn in C#.
...for about 10 minutes.
And at least give her credit for getting the merger done, in spite of Walter Hewlett throwing all of his force behind stopping it.
She's taken a huge risk with HP, and we'll all have to wait and see whether she was right. But either way I think so far she's done a commendable job. There's a reason she's the most powerful female in American business.
This sucks.
OTOH, the situation is exacerbated by the fact that I am a software programmer on a laptop. In other words, all day we need all the performance we can get, and then at night the laptops aren't on/connected. I imagine if you are backing up desktop machines, you can just set it to run at 3am every night and forget it, and never see the client software.
It's actually not very hard or expensive (I guess that's relative) to build a relatively quiet P4 or Athlon based system. Heatsink manufacturers are getting quite good at building thin-fin copper/aluminum heatsinks with big slow fans on them {1 2 3}. Or even without any fan at all.
VIA now offers an EPIA board that takes a P4 or Celeron (only up to 533MHz frontside bus though). At $185 (mobo only), it's a lot pricier than their C3 based solutions (which are IIRC $100-150 with proc included), but throw a P4 2.6GHz in there and you won't be "just a little short of processor horsepower" for anything. ;)
Yeah... I seem to remember Amazon.com started taking preorders for Ginger/IT long before they even knew what IT was going to be!
True, but it's worth pointing out that once you start talking about arrays of ints, the picture changes dramatically since Java does runtime checks for out-of-bounds conditions on every array access.
GC is required, and is slower than heap management.
Just a technicality, but, my understanding is that GC is actually faster than heap management (at least in theory). With GC, you don't pay for memory deallocation until you need it, and when that time comes, the cost is proportional not to the amount of garbage you've created, but to the amount of non-garbage that needs to be preserved. (That's true with copying garbage collectors, at least, which is the kind Sun's JVM uses most often.) And since most real-world apps' memory usage patterns tend to create 10X more short-lived objects than long-lived ones, you should be able to end up with a net savings most of the time by using GC.
Maybe what you meant was that GC is slower than stack management, or that GC causes unpredictable pauses during long "stop-the-world" collection operations (that plagued early versions of Java but are pretty rare now, due to some hard work by the folks at Sun).
-lack of documented/fixed object layout precludes direct memory manipulation of data - mostly a problem in I/O. This makes block-based I/O virtually impossible without serializing.
I'm not familiar with this problem. Could you elaborate?
-The 'Design Patterns' that have been adopted as Gospel by most in the Java community (at least the J2EE community) are very inefficient - too many layers, too much indirection, too many object copies etc.
I hate J2EE "Design Patterns" too, but in most real world enterprise apps, your performance is generally going to be totally dominated by either network I/O or database queries--stuff like in-memory object copies or indirection is like line noise.
- Swing. ugh.
Ugh indeed. :)
Um, that link says 96 Million.