Skip to main content

Home/ Coders/ Group items tagged low-level

Rss Feed Group items tagged

Oeil-de-nuit -_-

The Linux kernel: System Calls | Andries Brouwer, online book, 2003 - 3 views

Oeil-de-nuit -_-

2006: Sysenter Based System Call Mechanism in Linux 2.6 | manugarg.com - 1 views

Oeil-de-nuit -_-

Why LD_LIBRARY_PATH is bad, by David Barr (2001) - 2 views

  • This list is prepended to the existing list of compiled-in loader paths for a given executable, and any system default loader paths.
  • For security reasons, LD_LIBRARY_PATH is ignored at runtime for executables that have their setuid or setgid bit set. This severely limits the usefulness of LD_LIBRARY_PATH.
  • SunOS 4.x uses major and minor revision numbers. If you have a library “Xt”, then it's named something like “libXt.so.4.10” (Major version 4, minor 10). If you update the library (to correct a bug, for example), you would install libX11.so.4.11 and applications would automatically use the new version.
  • ...5 more annotations...
  • Linux, SunOS 5.x and most other SYSV variants use only major revision numbers. A library “Xt” is just named something like “libXt.so.4”.
  • Linux confuses things by generally using major/minor library file names, but always include a symlink that is the actual library path referenced. So, for example, a library “libXt.so.6” is actually a symlink to “libXt.so.6.0”.
  • The linker/loader actually looks for “libXt.so.6”.
  • run-time vs link-time paths
  • There's also LD_RUN_PATH which is an environment variable which acts to “ld” just like specifying -R.
Oeil-de-nuit -_-

Programming as if Performance Mattered, by James Hague [2004-04-04] - 3 views

  • I frequently see bare queries from programmers in discussion forums, especially from new programmers, who are worried about performance. These worries often stem from popular notions about what operations are "slow." Division. Square roots. Mispredicted branches. Cache unfriendly data structures.
  • Inevitably someone chimes in that making out-of-context assumptions, especially without profiling, is a bad idea. And they're right.
  • The golden rule of programming has always been that clarity and correctness matter much more than the utmost speed. Very few people will argue with that. And yet do we really believe it? If we did, then 99% of all programs would be written in something like Python. Or Erlang.
  • ...5 more annotations...
  • At the same time, such concerns and advice seem to remain constant despite rapid advances in hardware.
  • That tempting, enticing, puzzle-solving activity called "optimization," it hasn't gone away either.
  • Only now the process is on a different level. It isn't machine level twiddling and cycle counting, but it isn't simply mathematical analysis of algorithms either.
  • The big difference is that the code changes I made are substantially safer than running a program and having it silently hang the system. All array accesses are bounds-checked. There's no way to accidentally overwrite a data structure. There's no way to create a memory leak.
  • Really, this is what those cycle-counting programmers from 1985 dreamed of.
  •  
    « I frequently see bare queries from programmers in discussion forums, especially from new programmers, who are worried about performance. These worries often stem from popular notions about what operations are "slow." Division. Square roots. Mispredicted branches. Cache unfriendly data structures. »
Oeil-de-nuit -_-

prog21: Tales of a Former Disassembly Addict - 1 views

  • In fact, generated code can be so ridiculous and verbose that I finally came up with an across-the-board solution which works for all compilers on all systems:

    I don't look at the disassembled output.
  • I still see people obsessed with picking a programming language that's at the top of the benchmarks, and they obsess over the timing results the way I used to obsess over disassembled listings. It's a dodge, a distraction...and it's irrelevant.
1 - 10 of 10
Showing 20 items per page