Changeset c0e7723


Ignore:
Timestamp:
Apr 15, 2017, 2:29:34 PM (4 years ago)
Author:
Peter A. Buhr <pabuhr@…>
Branches:
aaron-thesis, arm-eh, cleanup-dtors, deferred_resn, demangler, jacob/cs343-translation, jenkins-sandbox, master, new-ast, new-env, no_list, persistent-indexer, resolv-new, with_gc
Children:
67e8e19
Parents:
160af1e
Message:

finished changes to conclusion

File:
1 edited

Legend:

Unmodified
Added
Removed
  • doc/generic_types/generic_types.tex

    r160af1e rc0e7723  
    11051105However, every \CFA feature is different than its \CC counterpart, often with extended functionality, better integration with C and its programmers, and always supporting separate compilation.
    11061106All of these new features are being used by the \CFA development-team to build the \CFA runtime system.
    1107 Finally, we demonstrate that \CFA performance for some idiomtic cases is better than C and close to \CC, showing the design is competitive.
     1107Finally, we demonstrate that \CFA performance for some idiomatic cases is better than C and close to \CC, showing the design is competitive.
    11081108
    11091109There is ongoing work on a wide range of \CFA feature extensions, including reference types, exceptions, and concurrent programming primitives.
    1110 In addition to this work, there are some interesting future directions the polymorphism design could take.
     1110In addition, there are interesting future directions for the polymorphism design.
    11111111Notably, \CC template functions trade compile time and code bloat for optimal runtime of individual instantiations of polymorphic functions.
    1112 \CFA polymorphic functions, by contrast, use an approach that is essentially dynamic virtual dispatch.
    1113 The runtime overhead of this approach is low, but not as low as \CC template functions, and it may be beneficial to provide a mechanism for particularly performance-sensitive code to close this gap.
    1114 Further research is needed, but two promising approaches are to allow an annotation on polymorphic function call sites that tells the translator to create a template-specialization of the function (provided the code is visible in the current translation unit) or placing an annotation on polymorphic function definitions that instantiates a version of the polymorphic function specialized to some set of types.
    1115 These approaches are not mutually exclusive, and would allow these performance optimizations to be applied only where most useful to increase performance, without suffering the code bloat or loss of generality of a template expansion approach where it is unnecessary.
     1112\CFA polymorphic functions, by contrast, uses a dynamic virtual dispatch.
     1113The runtime overhead of this approach is low, but not as low as inlining, and it may be beneficial to provide a mechanism for performance-sensitive code.
     1114Two promising approaches are an @inline@ annotation at polymorphic function call sites to create a template-specialization of the function (provided the code is visible) or placing an @inline@ annotation on polymorphic function-definitions to instantiate a specialized version for to some set of types.
     1115These approaches are not mutually exclusive, and allow performance optimizations to be applied only when necessary, without suffering global code-bloat.
     1116In general, we believe separate compilation producing smaller code works well with loaded hardware-caches, which may offset the benefit of larger inlined code.
    11161117
    11171118
Note: See TracChangeset for help on using the changeset viewer.