Your SlideShare is downloading. ×
Bridging the Application-to-Hardware Gap
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Bridging the Application-to-Hardware Gap

1,073

Published on

Keynote presentation by Bjarne Stroustrup, Professor at Texas A&M University. This keynote was part of our 4th annual Fujitsu Labs of America Technology Symposium held in Sunnyvale on June 9th, …

Keynote presentation by Bjarne Stroustrup, Professor at Texas A&M University. This keynote was part of our 4th annual Fujitsu Labs of America Technology Symposium held in Sunnyvale on June 9th, 2010. The theme of the event was:

Smart Grid: When Energy Meets the "Internet of Things"

Published in: Technology, Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,073
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Bridging the Application-to-Hardware Gap Bjarne Stroustrup Texas A&M University http://www.research.att.com/~bs
  • 2. Overview • “The gap” • C++ • Mapping to the machine • Low-overhead abstraction • Resource management Fujitsu - May'10 - Stroustrup 3
  • 3. Infrastructure – crossing the gap • A source of strength and/or a money pit? Application Application Application Application “The gap” Foundation/Infrastructure hardware hardware hardware Fujitsu - May'10 - Stroustrup 4
  • 4. Infrastructure – Examples • .Net • JVM • Model driven development environments • Browser • Scripting engine • Game engine • Some aspects of enterprise architectures • Some aspects of operating systems • Embedded systems architectures Fujitsu - May'10 - Stroustrup 5
  • 5. Infrastructure • As opposed to – Web apps – Conventional commercial applications – Numerical/scientific computation • The application/infrastructure distinction is often blurred – Because of confusion – For commercial reasons – For performance reasons • Cheap/efficient crossing of layers of abstraction can be critical Fujitsu - May'10 - Stroustrup 6
  • 6. Infrastructure • Is a platform – Differentiates corporations, communities, organizations • Expensive to – Build , port , and maintain • Designed, built, and maintained by expert developers – Differ from application developers in attitude and skills • Critical for applications – Ease of development – Stability over time (sometimes decades) – Maintenance – Portability across hardware – Performance Fujitsu - May'10 - Stroustrup 7
  • 7. Programming in “the gap” • Classical systems programming – Demanding on designers and programmers • High complexity – Layering, Modularity • Hardware differs and matters – Some code must differ even on different processors of the same architecture • Concurrency – Memory architecture, Multi-cores, Physical distribution • High reliability requirements – Typically 24/7 • Large programs/libraries/systems – N*100K lines Fujitsu - May'10 - Stroustrup 8
  • 8. Programming languages • A programming language exists to help people express ideas – Programming language features exist to serve design and programming techniques – The real measure of value is the number, novelty, and quality of applications Fujitsu - May'10 - Stroustrup 9
  • 9. Programming Languages Domain-specific abstraction General-purpose abstraction Fortran Simula Java Cobol C++ C++0x Direct mapping to hardware C# Assembler BCPL C 10 Fujitsu - May'10 - Stroustrup
  • 10. Template What is C++? A multi-paradigm meta-programming! programming A hybrid language language Buffer It’s C! overflows Embedded systems programming language Too big! Supports generic programming An object-oriented A random programming Low level! collection of language features Fujitsu - May'10 - Stroustrup 11
  • 11. C++ Key strength: building software infrastructures and resource-constrained applications A light-weight-abstraction programming language Fujitsu - May'10 - Stroustrup 12
  • 12. ISO Standard C++ • C++98: ISO standard since 1998 – Millions of programmers – Billions of lines of code deployed – Massive support • C++0x: next ISO standard – Probably 2011 • Currently being voted on – Many language features already available • GCC, Microsoft, IBM, Apple, etc. – Standard libraries widely available Fujitsu - May'10 - Stroustrup 13
  • 13. C++ applications 14 Fujitsu - May'10 - Stroustrup
  • 14. C++ Applications • www.research.att.com/~bs/applications.html 15 Fujitsu - May'10 - Stroustrup
  • 15. C++ Applications www.lextrait.com/vincent/implementations.html 16 Fujitsu - May'10 - Stroustrup
  • 16. Technical topic overview • Ideals • Mapping to the machine – Built-in, user-defined, hierarchy – Compactness, minimal run-time indirection • Low-overhead abstraction – Type safety – Flexibility • Resource management – File, lock – Concurrency support: type-safe task, lock, etc. Fujitsu - May'10 - Stroustrup 17
  • 17. Ideals • Work at the highest feasible level of abstraction – More correct, comprehensible, and maintainable code • Represent – concepts directly in code – independent concepts independently in code • Represent relationships among concepts directly – For example • Hierarchical relationships (object-oriented programming) • Parametric relationships (generic programming) • Combine concepts – freely – but only when needed and it makes sense Fujitsu - May'10 - Stroustrup 18
  • 18. C++ maps directly onto hardware • Mapping to the machine – Simple and direct – Built-in types • fit into registers • Matches machine instructions • Abstraction – User-defined types are created by simple composition – Zero-overhead principle: • what you don’t use you don’t pay for • What you do use, you couldn’t hand code any better Fujitsu - May'10 - Stroustrup 19
  • 19. Memory model Memory is sequences of objects addressed by pointers Fujitsu - May'10 - Stroustrup 20
  • 20. Memory model (“ordinary” class) class Point { int x, y; p12: 1 // … }; 2 // sizeof(Point)==2*sizeof(int) p: Point p12(1,2); Heap info Point* p = new Point(1,2); 1 // memory used for “p”:sizeof(Point*)+sizeof(Point)+Heap_info 2 Fujitsu - May'10 - Stroustrup 22
  • 21. Not all memory models are that direct • Consider a pair of coordinates – class Coord { double x,y,z; /* operations */ }; – pair<Coord> xy= { {1,2,3}, {4,5,6} }; C++ layout: xy: 1 2 3 4 5 6 Likely size: 6 words (2*3 words) “pure object-oriented” layout: reference: references: 4 5 5 Likely minimal size: 15 words (1+(2+2)+2*(2+3) words) 1 2 3 Fujitsu - May'10 - Stroustrup 25
  • 22. Abstraction • Simple user-defined types (“concrete types”) – classes • Amazingly flexible • Zero overhead (time and space) • Hierarchical organization (“abstract types”) – Class hierarchies, virtual functions • Object-oriented programming • Fixed minimal overhead • Parameterized abstractions (“generic types and functions”) – Templates • Generic programming • Amazingly flexible • Zero overhead (time and space) Fujitsu - May'10 - Stroustrup 26
  • 23. A class – defined class vector { // simple vector of double public: // interface: // a constructor establishes the class invariant (acquiring resources as needed): vector(); // constructor: empty vector vector(initializer_list<double>); // constructor: initialize from a list ~vector(); // destructor for cleanup double& operator[](int i); // range checked access const double& operator[](int i) const; // access to immutable vector int size() const; // copy operations private: // representation: Think of vector as a resource handle int sz; double* p; }; Fujitsu - May'10 - Stroustrup 27
  • 24. A generic class – used • “Our” vector is just an ordinary type used like any other type vector v1; // global variables vector s2 = { 1, 2, 3, 4 }; void f(const vector& v) // arguments and local variables { for (int i = 0; i<v.size(); ++i) cout << v[i] << ‘n’; vector s3 = { 1, 2, 3, 5, 8, 13 }; // … } No explicit resource management struct S { vector s1; // class members vector s2; Fujitsu - May'10 - Stroustrup 28 };
  • 25. A class - implemented class vector { // simple vector of double public: vector() :sz(0), elem(0) { } vector(initializer_list<double> il) :sz(il.size()), elem(new double[sz]) { uninitialized_copy(il.begin(), il.end(), elem); } ~vector() { delete[] elem; } double& operator[](int i) { if (i<0||sz<=i) throw out_of_range(); return elem[i]; } const double& operator[](int i) const; // access to immutable vector int size() const { return sz; } // copy operations private: int sz; No run-time support system “magic” double* elem; }; Fujitsu - May'10 - Stroustrup 29
  • 26. A class – made generic template<class T> class vector { // simple vector of T public: vector() :sz(0), elem(0) { } vector(initializer_list<double> il) :sz(il.size()), elem(new T[sz]) { uninitialized_copy(il.begin(), il.end(), elem); } ~vector() { delete[] elem; } T& operator[](int i) { if (i<0||sz<=i) throw out_of_range(); return elem[i]; } const T& operator[](int i) const; // access to immutable vector int size() const { return sz; } // copy operations private: int sz; No overheads compared to the non-generic version T* elem; }; Fujitsu - May'10 - Stroustrup 30
  • 27. A generic class – used • “Our” vector is used just like any other type, taking its element type as an argument – No fancy runtime system – No overheads (time or space) compare to hand coding vector<int> vi; vector<double> vd = { 1.0, 2, 3.14 }; // exactly like the non-parameterized version vector<string> vs = {"Hello", "New", "World" }; vector<vector<Coord>> vvc = { { {1,2,3}, {4,5,6} }, {}, { {2,3,4}, {3,4,5}, {4,5,6}, {5,6,7} } }; Fujitsu - May'10 - Stroustrup 31
  • 28. In real-world code • We use the standard-library vector – Fundamentally similar to “our” vector • same mapping to hardware – More refined that “our” vector – As efficient (same map to hardware) • or better • Or we use an industry, corporation, project “standard” container – Designed to cater for special needs • Build our own – Using the same facilities and techniques used for the standard library • There are tens of thousands of libraries “out there” – But no really good way of finding them Fujitsu - May'10 - Stroustrup 32
  • 29. Engine example • MAN – B&W marine diesel engine – Up to 132,340Hp – Has been deployed in very large ships for a couple of years Fujitsu - May'10 - Stroustrup 33
  • 30. What is a “resource”? • A resource is something – You acquire – You use – You release/free – Any or all of those steps can be implicit • Examples – Free store (heap) memory – Sockets – Locks – Files – Threads Fujitsu - May'10 - Stroustrup 34
  • 31. Managing Resources // unsafe, naïve use (common in all languages): void f(const char* p) { FILE* f = fopen(p,"r"); // acquire // use f fclose(f); // release } Fujitsu - May'10 - Stroustrup 35
  • 32. Managing Resources // naïve fix: void f(const char* p) { FILE* f = 0; try { f = fopen(p, "r"); // use f } catch (…) { // handle every exception if (f) fclose(f); throw; } if (f) fclose(f); } Fujitsu - May'10 - Stroustrup 36
  • 33. Managing Resources // use an object to represent a resource (RAII ==“resource acquisition is initialization”) class File_handle { // belongs in some support library FILE* p; public: File_handle(const string& s, const char* r) // constructor: acquire { p = fopen(s.c_str(),r); if (p==0) throw File_error(s,r); } ~File_handle() { fclose(p); } // destructor: release // copy operations // access functions }; void f(string s) { File_handle f(s, "r"); // simpler than “naïve use” // use f Fujitsu - May'10 - Stroustrup 37 }
  • 34. Type-safe conventional threading void f(vector<double>&); void g(vector<string>&, vector<int>&); void some_fct(vector<double>& vd, vector<string>& vs, vector<int>& vi) { std::thread t1{f, v1}; // run f(v1) asynchronously std::thread t2{g, vs, vi}; // run g(vs,vi) asynchronously t1.join(); t2.join(); } C++0x Stroustrup -København 2010 38
  • 35. Simplified conventional locking • A lock represents local ownership of a resource (the mutex) std::mutex m; int sh; // shared data void f() { // ... std::unique_lock<mutex> lck(m); // grab (acquire) the mutex // manipulate shared data: sh+=1; } // implicitly release the mutex Stroustrup -København 2010 39
  • 36. Type-safe simple concurrency double accum(double* b, double* e, double init); double comp(vector<double>& v) // spawn many tasks if v is large enough { if (v.size()<10000) return accum(&v[0], &v[0]+v.size(), 0.0); auto f0 = async(accum, &v[0], &v[v.size()/4], 0.0); auto f1 = async(accum, &v[v.size()/4], &v[v.size()/2], 0.0); auto f2 = async(accum, &v[v.size()/2], &v[v.size()*3/4], 0.0); auto f3 = async(accum, &v[v.size()*3/4], &v[0]+v.size(), 0.0); return f0.get()+f1.get()+f2.get()+f3.get(); } C++0x Stroustrup -København 2010 40
  • 37. C++ for safety-critical uses General strategy: Use a subset of superset C++ JSF++ MISRA C (a subset of C) C • JSF++ (a subset of a superset of C++) – stricter than any C subset (and far more flexible) Fujitsu - May'10 - Stroustrup 41
  • 38. Summary • Focus on mapping from “high-level” applications to hardware – One critical focus among many – The complexity of this mapping is easily underestimated • Work at the highest feasible level of abstraction – For correctness, maintainability, portability, and performance • A programming language can help – A suitable programming language – In the hands of competent programmers – Good language use is essential (IMO) • Rely on libraries – Define and rely on explicit abstractions – Represent resources directly • Stay type safe Fujitsu - May'10 - Stroustrup 42
  • 39. Thanks! • C and Simula – Brian Kernighan – Doug McIlroy – Kristen Nygaard – Dennis Ritchie – … • ISO C++ standards committee – Steve Clamage – Francis Glassborow – Andrew Koenig – Tom Plum – Herb Sutter – … • C++ compiler, tools, and library builders – Beman Dawes – David Vandevoorde – … • Application builders Fujitsu - May'10 - Stroustrup 43
  • 40. More information • My HOPL-II and HOPL-III papers • The Design and Evolution of C++ (Addison Wesley 1994) • My home pages – Papers, FAQs, libraries, applications, compilers, … • Search for “Bjarne” or “Stroustrup” • The ISO C++ standard committee’s site: – All documents from 1994 onwards • Search for “WG21” • The Computer History Museum – Software preservation project’s C++ pages • Early compilers and documentation, etc. – http://www.softwarepreservation.org/projects/c_plus_plus/ – Search for “C++ Historical Sources Archive” Fujitsu - May'10 - Stroustrup 44
  • 41. Object-oriented programming • Class hierarchies, dynamic lookup, and static interfaces class Shape { Point c; // common implementation detail: often a dumb idea Color col; public: // common user interface virtual void draw(); virtual void move(Point p) { c=p; } virtual void rotate(int deg); // … }; class Circle : public Shape { Circle(Point cc, Color co); void rotate(int) {} // nice optimal algorithm // … Fujitsu - May'10 - Stroustrup 45 };
  • 42. Performance and convenience template<class C, class V> vector<typename C::iterator> find_v(C& s, V v) // note: return by value! // find all occurrences of v in s { vector<typename C::iterator> res; for (auto p = s.begin(); p!=s.end(); ++p) if (*p==v) res.push_back(p); return res; } vector<string> m = { "Dennis", "Joe", "Brian", "Al", "Joe", "Bill" }; for (auto x : find_v(m,"Bill")) if (x!= "Bill") cerr << "bug!n"; Fujitsu - May'10 - Stroustrup 46
  • 43. Concurrency support • Memory model – To guarantee our usual assumptions • Support for concurrent systems programming – Atomic types for implementing concurrency support features • Lock-free programming – “Here be dragons” – Thread, mutex, and lock • RAII for locking • A single higher-level model – async() and futures Fujitsu - May'10 - Stroustrup 47

×