DrPizza

Members
  • Content count

    1713
  • Joined

  • Last visited

Community Reputation

160 Neutral

About DrPizza

  • Rank
    Contributor
  1. C is faster?

    [QUOTE]Also, what are some good algorithms to know?[/quote] My favourite has always been radix sort. It makes me feel all warm and fuzzy.
  2. IIRC one incurs a big performance hit by treating sockets like handles in Win32. IIRC it has to make a transition that goes something like user (your code) -> kernel (ReadFile) -> user (winsock) -> kernel (TDI) -> user (your code), versus Winsock calls which go user (your code) -> user (winsock) -> kernel (TDI) -> user (your code).
  3. Quote:Original post by benryves GREP? Windows Headers? It's VB... so no header files that I can see. Even as a VBer you've surely downloaded the Platform SDK to get up-to-date documentation and such?
  4. [java] Java 1.5 released

    Erasure is the devil.
  5. Java 5 (1.5) has been released

    Java 1.5 is like an exercise in seeing how many typing holes they could introduce into the language.
  6. I'd grep the Windows headers for them.
  7. Assuming the keyboard is normal, they just have regular VK_ values. You can use these values with RegisterHotKey() et al..
  8. One is limited to about 2^16 - 2 handles per process (of any kind); each thread defaults to a 1 MiB stack, so one has a further limit of about 2048 (or 3072) threads per process (less the memory overheads of the process itself and any OS libraries). Creating hundreds of threads in a single process is certainly doable.
  9. Whether it just rewrites the pointers (which it could do, as it knows where they are, after all) or uses pointer-to-pointers/indexes into an array of pointers/etc. I don't know.
  10. Question about multithreading

    A thread can take arbitrarily long to start. Create the parameter block on the heap. If the thread creation returns a failure value, free the block from the creating function. Otherwise, free the block within the thread itself.
  11. 64 bit optimizations

    Quote:and L1 is way slower than registers Rather an overstatement. Some L1 is accessible in a single cycle, which is not "way" slower, particularly when performing a multicycle operation. Merely going 64-bit is, ceteris paribus, slower than 32-bit (assuming that in both cases you have ample virtual memory). Reason being, the larger pointers and integers create more cache/memory pressure. But the abominable x86-64 also adds more architectural (i.e. directly usable) registers. Sure, rename registers can mitigate lack of architectural registers to a fair degree. But they're not as good as the real thing.
  12. A class to do it seems like a complete waste of time.
  13. Quote:That's exactly what a stack does. Probably because stack has no reserve capability so can make you pay for the O(n) resizes, which deque doesn't (well, it actually does, but with much better constant factors).
  14. Quote:No. I'm pretty sure that's wrong. It's wrong because today's processors are superscalar and so can retire more than one instruction per clock cycle. If you were getting only one instruction per cycle that'd be pretty much worst-case.