On Jul 27, 2013, at 12:29 , "Jonathan S. Shapiro" <[email protected]> wrote:
> I'm sure that I'm leaving some things out, and I don't mean to be unfair by
> doing so. Heres how I would state the requirements for a systems language:
> Is a great general-purpose language that
> Supports prescriptive stack allocation
> In which run-time expense of computing statements and expressions is
> understandable to the experienced programmer
> In which that run-time cost understanding is reasonably balanced against
> compilation techniques like inlining and template expansion - C++ fails this
> test, not because it has these features, but because of the way in which
> these idioms are commonly used.
> In which certain types of safe, prescriptive storage management are possible
> when algorithms are written by expert programmers.
I agree with these statements although I would also say something about how
things map down to the underlying hardware/architecture. You have more
concerns as a systems programmer than other kinds of programmers:
* you want appropriately sized data types that directly map to hardware
registers
* you may care what registers are used and what the contents are
* you care about how data structures are laid out in memory: you need to access
specific addresses (memory-mapped devices), you need to know if its packed or
not, aligned or not. (e.g. you wouldn't find defrepr anywhere but in a systems
programming language).
* you care about the memory hierarchy and how long your cache lines are. you
have explicit ways of avoiding false sharing.
* you care about swapping, usually to the point that if your application is
swapped out, horrible things happen
* you care about how language-level threads are mapped to cores and how they
are scheduled (priorities, context-switches, etc)
I think that it's your number 3 that causes people to avoid garbage collection
(at least it does to me). Even if you understand the cost of the kinds of
collection you usually don't know when it's going to happen. Usually there are
critical sections where you must not be preempted by either the garbage
collection runtime or the kernel. If there's a way to disable the GC for the
duration of those sections (possible the lifetime of the application) then
great. Or, I suppose, if you have the hardware resources you can dedicate one
or more cores for GC and say, 'run over there and never take actions that will
interrupt my application threads running on these other cores' , that would be
acceptable.
Is that what you meant by number 5? Assuming the presence of an expert
programmer can they write a complex application that allocates all the memory
it needs on start up and then run with a guarantee that the GC will not cost a
single cycle? I think it falls under that 'pay for what you use' philosophy.
If I don't need a collector then any time spent running one, even if it doesn't
interrupt my program, is time wasted that could be used by other processes.
-ipc
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
