Slashdot Mirror


User: tomstdenis

tomstdenis's activity in the archive.

Stories
0
Comments
6,870
First seen
Last seen
Profile
(view on slashdot.org)

Comments · 6,870

  1. Re:6502 on PC-BSD: The Most Beginner Friendly OS · · Score: 1

    The problem is there is no advantage to it. You'd spend a billion dollars beefing up an ARM processor only to learn that the backend is pretty much what you'd have in an x86 processor.

    The niche for ARM is the MIPS/watt tradeoff. It can get you a couple hundred MIPS for FAR LESS power usage than any x86 processor [specially for the later ARM processors with internal caches].

    Tom

  2. Re:6502 on PC-BSD: The Most Beginner Friendly OS · · Score: 3, Informative

    Yes, they are but they also benefit from the CISC opcodes. I-Cache polution is a serious threat to inlining/unrolling and branch prediction.

    With ARM style RISC opcodes operations heavy on memory [for example] are less dense than those of x86. e.g.

    x86:
    add eax,[ebx+ecx]

    ARM: [map them to r0,r1,r2]
    add r3,r1,r2 ; ebx + ecx
    ldr r3,[r3] ; [ebx+ecx]
    add r0,r0,r3

    So the x86 world takes 3 bytes to do what ARM takes 12 [or 6 in THUMB mode]. Multiply this by a few hundred if not thousand for any given algorithm and you get the point.

    Effectively the opcode decoders act like decompressors for x86 opcodes. Done on the fly for most opcodes. Of course in the case of AMD64 [and most likely the Core 2 stuff] most opcodes map to 1 or 2 RISC operations. The RISC engines are not as trivial as those in the ARM processor alone. So even if you scrapped the x86 side and exposed the internal engine it'd still be way cooler than ARM.

    Tom

  3. Re:So, an Exploit For a Patch? on Microsoft Bracing for Worm Attack · · Score: 4, Interesting

    Sadly "properly firewalled" also means from your peers inside your network. When I was in College it was routine for viruses to spread almost instantly in the labs where we had our own system drives (e.g. not locked down). Similarly at any sufficiently large office there is bound to be at least one complete f'ing idiot who clicks on all email attachments and thinks "browsing the net commando style" is top shit.

    Tom

  4. Re:Red Hat's fault on Novell Defends 'Unstable' Xen Claims · · Score: 1

    If you are using a Linux distro chances are you have NFS utils somewhere. Not to forget that the kernel comes with a NFS module, etc, etc, yada yada I hate you and Jon Callas.

    Tom

  5. Re:Red Hat's fault on Novell Defends 'Unstable' Xen Claims · · Score: 1

    Say what? I routinely copy things at 9.8 -> 10MiB/sec off my 100Mbit network. Why would SCP be any faster? It does more work than NFS to move the file. When I had a larger gigabit network I was routinely maxing out the RAID write speed (which was less than 128MiB/sec).

    Your post makes me want to hurt you. Badly.

    Tom

  6. Re:Red Hat's fault on Novell Defends 'Unstable' Xen Claims · · Score: 1

    Um, you need portmap for NFS. Without it the kernel just sits there trying to mount things.

    Tom

  7. Re:Defining my next purchases on Novell Defends 'Unstable' Xen Claims · · Score: 1

    I thought AM2 was sporting AMD-V? From what I can google that's the plan (oddly enough AMDs own website doesn't seem to have much AM2 details).

    My workstation is made up of a pair of 940-pin 285s so I won't be switching them out for anything else any time soon.

    Tom

  8. Re:Red Hat's fault on Novell Defends 'Unstable' Xen Claims · · Score: 1

    If you network UNIX[like] boxes you need NFS. No sane person uses SAMBA to network non-windows computers.

    A lot of people own more than one computer nowadays [heck I have 5 in my office] so networking means more than just "get on them internets".

    Tom

  9. Re:6502 on PC-BSD: The Most Beginner Friendly OS · · Score: 2, Interesting

    In terms of raw MIPS ARM is a loser to the "evil CISC" designs like the AMD64 and Conroe. Maybe in terms of MIPS/watt it wins though. I guess different problems. Of course it's hard to say if that's a result of CISC vs RISC or that most CISC processors are much larger.

    Maybe if ARM had 9 pipelines like AMD64 it'd be hella fast too :-)

    Tom

  10. Please on PC-BSD: The Most Beginner Friendly OS · · Score: 5, Interesting

    stop [next] posting [next] articles [next] which [next] are [next] nothing [next] but [next] ad [next] impression [next] generators [next].

    The dude put like 3 sentences per "page" and doesn't let you skip far into the article [hint, the dropdown says "...continue" so you can't just jump ahead to the conclusions and what not]. I stopped reading it after the 2nd page.

    If [next] this [next] is [next] the [next] future [next] of [next] journalism [next] then [next] I [next] fear [next] for [next] our [next] future.

    Tom

  11. Re:Red Hat's fault on Novell Defends 'Unstable' Xen Claims · · Score: 1

    inetd/portmap are what let you network your computer (inetd starts things like NIS for instance iirc). If you don't plan on networking your computer install freedos on it :-) Or DSL or something.

    Granted, I think you should have the ability to disable them if you want, but as a distro you have to target an audience who like it or not, like the whole "networking" fad.

    Tom

  12. Re:Defining my next purchases on Novell Defends 'Unstable' Xen Claims · · Score: 1

    If the only thing driving your performance is which Virtualization is supported in Xen first why not just flip a coin?

    There is more to it than just that. Afterall you still have a cpu to work with afterall...

    Tom

  13. Re:Three ways to justify "turbo" on Borland Announces the Return of the Turbo Products, with Video · · Score: 1

    That's all fine. I'm happy for you that this is one thing you do not care about in the least, since that obviously makes it easier to choose a compiler.

    I care about speed but I also am realistic. I require a highly optimizing flexible compiler more than I need a pascal compiler for x86. I routinely work on PPC, ARM, x86 [32 and 64-bit] boxes. Show me the copy of Delphi that works on all of those please.

    In the real world, speed is mitigated by properly factoring code. Having 100k lines per file is not "impressive" is poor project design and planning.

    If you have to refactor your code down to one function per source file (particularly nice for classes, or for different functions needing access to the same static variable) to keep compilation swift, there's something wrong with the compiler or build system you are using. This practice will also effectively kill any and all auto-inlining most compilers (including GCC) might otherwise do (except for static inline functions declared in header files).

    Welcome to the real world. If you are working in a team of 30 and you all need concurrent access to the tree putting all your eggs in one basket can make collisions a bitch to work around. Also, functions which are to be inlined are typically small macros which are best suited for a header file. If you are inlining 1000 line routines you need to rethink what you are doing.

    Code factoring has other benefits

    - Keeps the code organized, easier to find things
    - Easier to work in parallel on, fewer cvs/svn/etc collisions
    - Helps keep the build image smaller by avoiding linking objects not used (yes yes, smart linkers do exist but not universally)
    - Keeps build times down
    - Makes the project buildable on platforms with low amounts of memory

    At any rate, compile time matters but quality matters more. Delphi is a fast compiler because

    - It targets x86 only so the entire design is tailored for one cpu. It probably has less overhead because it doesn't have to have structures and routines in place to deal with non-x86 processors

    - It only compiles Delphi. GCC compiles C, C++, Java, Fortran and Ada.

    - It optimizes less than GCC, has fewer passes of optimization, etc.

    So really the comparison is meaningless. Delphi is fast because it DOES LESS than GCC. The speed has nothing to do with the fact it's Pascal derived as there are very fast C compilers out there.

    Tom

  14. Re:Why stop at a bridge? on Stephen Colbert vs The Hungarian Government · · Score: -1, Flamebait

    If you were born in America ... gasp ... you are american. Who cares what your parents are or where you live now.

    Tom

  15. Re:Three ways to justify "turbo" on Borland Announces the Return of the Turbo Products, with Video · · Score: 1

    Even if you turn off all optimizations GCC is still quite slow, in particular when compiling C++ code. Things got a lot better in 4.0 and 4.1, but it still not exactly fast.

    It's not meant for that problem. GCC is meant to be cross-platform highly optimizing standards adhering compiler platform [not just for C but C++, F77, Ada, Java, etc]. If your goal is "lines per second" and not quality of the output use something like LCC.

    As you know (since you mention it below), that isn't Delphi's only feature from the customers point of view. But it's nevertheless extremely convenient when you're used to it. People have been ranting since day one on Apple's Xcode list about the slowness of GCC compared to CodeWarrior (even when comparing a distcc'd build against a single threaded CodeWarrior build), also in debug mode (i.e. no optimizations). Compilation speed is far from a non-issue these days.

    It's far from a non-issue usually because people write SHIT CODE. Then they put zero effort into the build system. GCC, in a single process, compile thousands of lines a second with high optimizations. If you factor your code properly and write a sane build script [e.g. makefile] you can easily perform on the fly adjustments and not waste a lot of time compiling. It's when you get projects that are written by people who think loc counts mean quality and that brute force is the only way to solve problems that you get into issues.

    Look at the Linux Kernel. [2.6 at least]. I can hack a single file and make a new kernel image in a matter of seconds. There are millions of lines in the Kernel [granted, not all of them are quality] and yet with a sane make system you can avoid rebuilding the entire thing. Wow.

    I really truly honestly 100% believe that if you spend too much time building stuff you need to refactor your code. It's really that simple. Keeping single functions per .c file for instance is a quick way to make the code accessible, CVS [etc] ready and keep compile times low.

    If you're the type that puts all of your applications code in one file, you're a nutbag and your opinions don't matter.

    I took a course 2 weeks ago at a summerschool from David Padua who works a lot on compiler optimizations. His conclusion was all the time that basically all current compilers suck at optimizing, except in very specific cases and often only if you know how to write your code so the compiler recognises what you want to do.

    "suck" is subjective. Do you maintain the position that GCC 4.1.1 is no better than GCC v1? Or how about Turbo C++ 3.0?

    I'd say they're far from perfect but they're not sub-ideal. GCC routinely produces output of ideal quality. It often makes use of exotic opcodes [like movzbl] instead of emulating them with more basic opcodes. It knows how to move code blocks around, unroll, inline, CSE, etc.

    Try comparing the time of execution of GCC itself when compiled with -O2 versus say -O0. Tell me that it doesn't optimize.

    Tom

  16. Re:TIME TO DUMP GOOGLE on Google to Continue Storing Search Requests · · Score: 1

    Who owns the google servers?

    Tom

  17. Re:The differance on Google to Continue Storing Search Requests · · Score: 1

    And then it goes out as plaintext to the server. Joy.

    Tom

  18. Re:nv doesn't work well for 2D on Intel Open Sources Graphics Drivers · · Score: 1

    The intel driver has a similar problem with things like 1280x800 but you can reprogram the BIOS in memory (e.g. each time you boot) to change the video mode. Maybe you can do something similar with the nv bios?

    On my 1280x1024 panel the nv driver works fine at least :-)

    Tom

  19. Re:THEY AIN'T PRIVATE on Google to Continue Storing Search Requests · · Score: 1

    There aren't cuz there is no market for it. Nobody but the handful of trolls on slashdot care about search engine privacy.

    Tom

  20. Re:The differance on Google to Continue Storing Search Requests · · Score: 1, Interesting

    Tor is stupid because the author [who was at defcon] misleads people into thinking it's required and provides security. http over Tor != secure ... Stupid over Tor != secure If you really are worried about privacy stop doing things in PLAIN F!@#ING TEXT!!!

    Use a mail account that uses TLS, GnuPG encrypt/sign your emails, etc...

    Think about it. I log into my bank via TLS [or SSLv3, I disable SSLv2]. What do you learn?

    a) someone on Rogers has a Scotiabank account
    b) ???
    c) Profit!

    Big fucking deal. You could also learn that by WATCHING ME WALK INTO THE BANK.

    Tor is only for 13 yr old 3l33t hax0rz who think that the newfangled technology is the solution to all problems and that nothing from the past could possibly solve a privacy problem.

    Also, Jon Callas sucks ass.

    Tom

  21. Re:TIME TO DUMP GOOGLE on Google to Continue Storing Search Requests · · Score: 2, Insightful

    Yes, how dare they learn your IP!!! I mean it's only the single most important thing you need to function HTTP...Well that and a TCP stack...

    Tip: If you don't want to get in trouble for googling for bomb making kits, kiddie porn or whatever else you depraved fucks look for.... don't use google.

    For the rest of us looking for legal shit, I don't care. It's google server. If they want to log all my searches that's THEIR RIGHT.

    Tom

  22. THEY AIN'T PRIVATE on Google to Continue Storing Search Requests · · Score: 2, Insightful

    You sent it as PLAINTEXT over the INTERNET.

    This [or the thing against AOL] is not a story.

    I couldn't care less about Google releasing all the odd shit I look for. If I was I would find a private search engine that worked over HTTPS.

    Tom

  23. Re:Slow down cowboy on Intel Open Sources Graphics Drivers · · Score: 1

    I'm sure companies that build AMD boxes wouldn't mind the option. And for VIA it's win win. If you can use theirs or one they licensed it's still a VIA board you bought, etc, etc, etc.

    Tom

  24. Re:Slow down cowboy on Intel Open Sources Graphics Drivers · · Score: 1

    Yeah that sounds nice and smartassy except I doubt Intel will license the spec to [say] AMD or Via to include in their products. And failing to get a license you better learn how to remove the surface mounted ICs from your mobo so you can um I dunno, magically transplant them.

    OMG I can't get over how stupid your reply was... My head asploded!

    Tom

  25. Slow down cowboy on Intel Open Sources Graphics Drivers · · Score: 1, Informative

    Remember ... to use this GPU [totally unrelated to the CPU] you *MUST* use an Intel processor.

    So before y'all get too far ahead patting Intel on the back remember that you are not free to use the GPU with say an ARM, MIPS, PPC or other x86 processor [via/amd/etc]. Not only that, but IIRC Intel GPUs are tied to Intel chipset motherboards.

    So while it's all good and said that the drivers are open source, that helps users, it doesn't help the industry and society as a whole. Making their GPUs independently available outside of their x86 processor line would [e.g. as a discrete chip others could license or as an add-on PCI-E card].

    Tom