My experience is that I'm more productive in C# than on Java. The reason in not so much the language, but the fact that the.NET class library is lightyears ahead of the JDK. They stole what was good and ditch the stupid parts (like the overused decorator pattern which dramatically slows down productivity and gains little or nothing in flexibility)
"Google has been at 4.285 billion pages for more than three months straight. The count hasn't increased in a long time... The index is maxed."
Hmm... are they using a 32-bit integer to keep the page count?
2^32 = 4.294 billion, pretty close to 4.285 billion pages.
Newbies...
"You can simulate this probabalistic balance behavior right now by getting married and getting a joint checking account."
I tried that and observed what is called the "Heisenberger shopping principle". Whenever I checked the account, my wife appeared to be shopping at two or three stores at the same time.
According to Heisenberger, my money is going to be both here and there. And if I'm to check my balance, the result will be inaccurate because I'm checking it up.
"I was really just saying that the privacy threat exposed by Gmail storing your mail is no worse than how email works today."
The point of my posting was actually about cross referencing. That's usually when privacy issues arise. Google can do that efficiently using an incredible amount of data as input.
It doesn't matter if the article is six years old. The problem with Java is still present: it is stack based, which makes any optimizations hard. It still fetches bytes code from the class pool which is on the heap, and operands from the Java stack which is on the heap. This means L1 and L2 cache misses all the time. In C, most operands are on the stack if the compiler has a sane register coloring implementation. Also, the stack ops are faster than heap mem-fetch.
In any non-trivial app, C is MUCH faster in this respect.
Not trying to debunk Java here - just pointing out that Java is a silly choice for number crunching apps.
Here's the deal: when you perform fp ops in Java, operands go where? The _Java_ stack which actually resides on the heap. In C? Usually registers. The JIT register allocation algorithm cannot possibly optimize like a good C compiler can because of the purely stack-based architecture. What's worse - after each fp op, the CPU must fetch byte codes from the class pool which also resides on the heap. So farewell L1 cache line optimization (and sometimes L2 caching)
Note that most benchmarks are too limited, the Lx cache line problems appear in non-trivial applications with a bit more more than a loop doing fp addition.
Slashdot Mirror
My experience is that I'm more productive in C# than on Java. The reason in not so much the language, but the fact that the .NET class library is lightyears ahead of the JDK. They stole what was good and ditch the stupid parts (like the overused decorator pattern which dramatically slows down productivity and gains little or nothing in flexibility)
Oh my god, I HAVE A PARALLELL PORT FETISH.
Well, there's http://www.zero.com and http://www.null.com
"Google has been at 4.285 billion pages for more than three months straight. The count hasn't increased in a long time... The index is maxed."
Hmm... are they using a 32-bit integer to keep the page count?
2^32 = 4.294 billion, pretty close to 4.285 billion pages.
Newbies...
>| ) |_| =| Y 2 4 _| |_| 0 Y
Let's not hope this means the reintroduction of "MemoryDoubler" products. Or SpeedHalfers, as they are sometimes called...
Hhmmm - like a beta version? Perhaps the mother ship will blow up like my motherbord did the other day...
Simula is still used and there is a research facility named after it.
This guy obviously banged his head in the toilet.
Anyone know what that amount to in termns of kbps?
Yeah, I know, but if I said that, I wouldn't be modded up to +5 Funny, now would I? That's for certain.
I tried that and observed what is called the "Heisenberger shopping principle". Whenever I checked the account, my wife appeared to be shopping at two or three stores at the same time.
A true Heisen-bitch.
Nah, back to those good ol' electrons.
I see. At least Opticom and Intel has some substance in what they are doing.
A norwegian company (I think) has joined forces with Intel to provide polymer storage within the decade. Exiting stuff: Opticom
The people surveyed don't have important information on their computers. The few who have are either plain stupid or extremely obese.
Darn. I find it hard to hack using gloves.
This scam started in 2003. How is this news?
I'll be more impressed when I get my hands on a 4D search engine. My first movie sequence search would be like: "guy fucks women in the * "
Booble?
Uhm, I believe I have a 4 port USB hub for sale. Anyone?
The point of my posting was actually about cross referencing. That's usually when privacy issues arise. Google can do that efficiently using an incredible amount of data as input.
That's pure theory and doesn't work out in real life. Why? Because the registered are occupied with VM internals (to speed up VM loops, in particular)
In any non-trivial app, C is MUCH faster in this respect.
Not trying to debunk Java here - just pointing out that Java is a silly choice for number crunching apps.
And pigs _can_ fly.
Here's the deal: when you perform fp ops in Java, operands go where? The _Java_ stack which actually resides on the heap. In C? Usually registers. The JIT register allocation algorithm cannot possibly optimize like a good C compiler can because of the purely stack-based architecture. What's worse - after each fp op, the CPU must fetch byte codes from the class pool which also resides on the heap. So farewell L1 cache line optimization (and sometimes L2 caching)
Note that most benchmarks are too limited, the Lx cache line problems appear in non-trivial applications with a bit more more than a loop doing fp addition.
And now it runs Java number crunching in the background.