Slashdot Mirror


User: fobef

fobef's activity in the archive.

Stories
0
Comments
11
First seen
Last seen
Profile
(view on slashdot.org)

Comments · 11

  1. Re:They have no chance. on Johansen Prosecutors Appeal · · Score: 5, Informative

    Here is how it works in Sweden, which I suppose has a similar system.

    All trials begin at the lowest instance.

    After that the second instance can choose to accept an appeal. It is always harder to get an appeal accepted when trying to sentence someone who was declared not guilt in a lower instance.

    Then there is the highest instance, which doesn't accept many cases every year, but this case most likely WILL end up there, because it is a new crime, and this is the instance which details how new, untested laws should be interpreted. If they make a clear enough innocent verdict in this case, no further "not guilty" verdicts would make it to second instance next time a person is tried for a similar crime under this law.

    And no slashdot post is complete without... IANAL...

  2. 640 kb on die cache on AMD Releases Barton: Athlon 3000+ · · Score: 5, Funny

    "This exclusive 512 KB L2-cache works together with the 128 KB L1-cache (64 KB data, 64 KB instruction) to form one impressive 640 KB on-die cache."

    Am I the only one who can see Bill Gates drooling over this?

  3. Re:So why are they not used? on U.S. Air Force Developing Microwave Weapon · · Score: 5, Interesting

    While studying wave physics at the university, a (swedish) defence researcher held a lecture about research in EMP weapons. The ones he had studied were supposed to be used in road blocks to stop vehicles, and when they tested it, it worked very well, and the vehicles were beyond repair.

    However, when they tried to use it in Bosnia, the vehicles there were so old, it had no effect because it targeted the electronics in the cars, and the ones they used were too old =)

  4. Re:Java is slow? on Linux Number Crunching: Languages and Tools · · Score: 1

    Instruction ordering: I'm not necessarily talking about read/write barriers but basic instruction scheduling, longer instruction sequences really help here. (Execution units in modern CPUs aren't very busy at all but I really don't wanna get in to a discussion about that too.) -client v. -server Ok, I thought only -client was called HotSpot, because java --help says that -hotspot is the same as -client. Lets end this discussion because neither one will convince the other. I still havn't seen a real world situation when java has come close to c++, and you say you have. While I don't doubt that, I doubt that the c version was very well optimized. Have a good day

  5. Re:Java is slow? on Linux Number Crunching: Languages and Tools · · Score: 1

    Cache friendly managment:
    It might be possible, but no VM does it yet. Why? Because they havn't seen any gain would be my guess.

    Instruction order issues are again very important, I don't know why you bother mixing in vector processing cpus, I assume we're talkning about x86. Most of the optimizations in IBMs JVM seem to be because of them gradually increasing the number of instructions that they can reorder .

    http://www-106.ibm.com/developerworks/ibm/librar y/ j-berry/sidebar.html
    (you might have to remove spaces from the URL if copying & pasting it)

    The difference between -client vs. -server is actually the opposite of what YOU are imagining. The client version (also called the hot spot version) starts by interpreting byte code, and then later compiles the hot spots. Not that it matters much here because the bechmark took a couple of minutes to run.

    Strange that the -server version couldn't determine what optimizations where bad for performance (according to you) from all that runtime information it must have gathered during those minutes.

  6. Re:Java is slow? on Linux Number Crunching: Languages and Tools · · Score: 2, Interesting

    This is interesting, but I'm still very sceptical.

    First of all, the possibility to align data to suit the cache is very very real and not silly. Of course it might not make a difference if you're memory bandwidth bound or whatever else is limiting performance, but for critical working sets close to the cache size it can, and most likely will, make tremendous difference.

    The advantage that Fortran has over C++, except for lots of well tested libraries, is the fact that pointers cannot interfere with each other. For example, writing to memory through pointer PA cannot affect a read from pointer PB, so the compiler can rearrange the read and write in any order. This thing alone made fortran faster than C++ on most math benchmarks.

    There now is a restrict keyword in C++ that does exactly the same thing, but what does java have? Nothing like that ofcourse, and IMHO it shouldn't. Because java is a language that makes for bug free software with good-enough performance.

    I have only written two performance critical programs both in java and c++, so my numbers are anecdotal evidence at best, but c++'s victory was devastating both times. And they where no line-by-line conversions, no unneccesary news etc. Of course they where a far cry from the "loop one million times and make a double precision fdiv" of the article linked in the original post in this thread where they found out that java and c++ was about equal. But then, so was the code you wrote, which makes it interesting.

    Is this thing you ported freely available somewhere?

    Also, how do you know that the -server switch hindered performance? It was better than -client, right? I assume it performs its optimizations when loading the class, and the only disadvantage compared to -client would be when inlined, runtime-bound methods have to be un-inlined because of a new class being new'ed in the place of an old object with different class (did that make sense?:-) So is this assumption wrong, or do you know that this is in fact happening in this benchmark?

  7. Re:Java is slow? on Linux Number Crunching: Languages and Tools · · Score: 2, Informative

    What do you mean by "using an interpreter"? He used Sun's run time, even with the -server switch, which does some for java quite serious optimizations. The real disadvantage java has (in terms of performance, it is an advantage otherwise) isn't the IEEE requirements, but rather the extensive use of runtime binding of classes. In C code, the compiler can inline pretty much anything for you, and get long runs of instructions to schedule as it likes. The other big performance disadvantage compared to C++ is that in C++ you can often have complete control over how arrays are laid out in memory, and test different ways to see which ones work best with your cache hierarchy. In Java you just 'new' it and then you have no control over it. I often hear that Java is about half the speed of C++, but my own tests put it more in the 10% to 20% range. Maybe half is true for poorly optimized C++ code vs poorly optimized Java code, but for well optimized C++ vs well optimized java the difference seems closer to five times. Which is fine to me most of the time, so I generally use Java.

  8. Re:what about compatibility? on Transmeta Astro Processor · · Score: 1

    heat is another problem, but that is something that proper internal design can usually cure
    Tell that to this guy.

  9. Re:Another good idea lost on Transmeta Astro Processor · · Score: 2, Informative

    Ok, I havn't read the linked articles. But I really think that you are wrong about Transmeta abandongin the code morphing. The things I've read in the past about their next generation cpus, which I assume is the astro, is that the maximum theoretical throughput would be doubled from 4 ops to 8 ops. That would ofcourse be impossible to do, without going the VLIW + codemorphing path of previous generations.

  10. Re:Fritz vs Deep Blue on Chess: Man vs. Machine Debate Continues · · Score: 1

    Nothing, nodes per second alone is a meaningless figure. Besides, I hear that Rebel generally is considered a stronger opponent against humen, although it might lose against Fritz head to head.

  11. Re:Quicktime has been linked with MPEG 4 since 199 on QuickTime To Move To MPEG-4 · · Score: 2, Interesting

    Ok, lets set this straight. The *file format* for MPEG-4 is based on that of quicktime. Defining the file format is like a millionth of the total work done on MPEG-4. ISO didn't define the file format for jpeg for example, which led to some problems, so this time they decided to define everything. Oh, and speaking of microsoft and divx, this is how I recall things happened (an mpeg guy told me): Microsoft offered the group to implement all ideas for the format, so that they could see the effect of various decisions. This naturally was a good thing (TM), however, when others wanted to see the actual code, ms denied that. So a european initiative started under some German company IIRC, to develop an open source implementation. Maybe it was called divx already here, maybe not. They caught up pretty much with MS, but then there was some problem with that code, it belonged to the company even though it was open source, so the project forked, one was rewriting it from the ground, and another continued on the work already done. So I believe that the rumour that divx is based on a hacked ms codec is bull. Also, MS added some extra bits to the file format, and doesn't call it MPEG-4 anymore, but rather MPGE-4 based or something to that effect. Sorry I'm so vague with the details.