-
Notifications
You must be signed in to change notification settings - Fork 25
/
chap1-notes.tex
161 lines (113 loc) · 5.87 KB
/
chap1-notes.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
people had pretty good ideas of certain things they wanted
and they had piles of existing software
the recognized something they could use, e.g. python on C, and just ran
with it. it was never designed
1. technical computing
- the power of abstraction
- why they never asked
. the current VHLLs must have gotten something right, but it doesn't have
to be done the exact way they do it
. SC vs. CS
. ¶ about T.C. not being about just arrays, but flexibility
- the remedy (``contributions of this thesis''), the breakthrough
2. analysis of abstraction
- current abstractions that work well
. matrices
. blockbuster library calls (fft, lapack, blas)
. composability of calls via key built-in types
. dynamic typing
- pushing it further -- what doesn't work well
. bad abstractions => productivity problems
. compile-time overloading, weak overloading, single dispatch,
everything-is-a-dictionary, etc.
- performance through abstraction
there are 2 ways to design a language: (1) provide simple efficient abstractions
and build out of that, or (2) provide bigger abstractions more directly useful
to a domain expert. (2) often appears to work well, but in fact only approach
(1) is truly viable.
3. julia (technical, innovations)
- language design space
- the many multiple dispatches
- case studies, examples
4. julia (social/vision)
- what does or should a language consist of?
- what can be done for this problem at the language level of abstraction?
- a design like NumPy argues the answer is ``nothing''
Today, object-oriented languages are used for scientific computing
(particularly C++, Java, and Python). However in our opinion this
application area has not fully explored the possibilities of OOP. In
particular, generic functions have been one of the least popular
OO concepts and yet, we will argue, are the most relevant to scientific
computing.
Unlike in other specialized domains (e.g. CAD software), these users
are primarily interested in writing programs.
People start out needing a few specialized routines, then eventually
need ``glue'' of some kind, and eventually need a full language.
The glue is an afterthought.
Computational scientists often observe that they spend an amazingly
small percentage of their time on the core computations that
interest them, and lots of time on glue, verifying results,
parsing and printing data, etc. This speaks to the need for
general purpose languages.
People are afraid to reinvent --- SVD etc. are considered black
boxes not to be touched.
We don't just need a faster matlab; for example a matlab with better
loop optimizations or the like. Such a thing is fine to have,
but we would argue it is not what people really need.
Instead we propose powerful general-purpose abstractions that
provide what is needed for technical computing as a special case.
It is a technical computing language because it does *not*
special case technical computing.
At a very low level, the kinds of behaviors technical users expect
from their languages do not match computer scientists' preconceptions
of how languages should work.
You should be able to define the meanings you want, not have them
imposed on you.
\section{Why a new language?}
You cannot implement MATLAB arrays in C++ with the same level of
convenience.
%%
Our goal is to declaratively specify the behaviors of abstractions
important to scientific computing, in a way that can be executed
efficiently and is arguably easy to write.
By ``declaratively'', we mean in a manner that a compiler can
realistically understand. All the behaviors we are interested in
could of course be implemented with, say, imperative code, and indeed
this is what has been done before, either inside a compiler, or inside
an interpreter, or in a library for a sufficiently flexible language.
These approaches have serious drawbacks. Implementing behaviors
inside a compiler is effective for generating efficient code, but
does not provide a way for users to easily implement their *own*
behaviors. Imperative code inside an interpreter or library, on the other hand,
does not provide a clear path to efficient execution. In theory, a
partial evaluator could solve this problem, and this approach has been
tried (REF). After adding minor annotations to a program, partial evaluation
can work well. However, the biggest downside might be opacity: it is
difficult to tell users how to write their code for the partial
evaluator to be effective. We wish to try a different approach, that
(1) permits a simpler performance model, and (2) stands a decent chance
of being exploited *by accident* (i.e. users will tend to follow the performance
model without much effort).
Our method for doing this is generic functions with rich signatures
(method specializers). Generic functions are rather well studied in the
OOP literature (REF), but we feel that the kinds of method specializers
that have been designed before are simply not powerful enough.
Furthermore, if they are made powerful enough, surprising consequences
ensue.
We don't want to focus on compiler implementation tricks. We want a
design such that fancy compiler and implementation tricks are not necessary.
\section{How have times changed?}
Use more memory, different point now in the resource/cost space
In line with the new big data world of today?
Julia is the language where people can and hopefully will collaborate
to make better programs (different from 1980).
Language has to not just know matrices, but also must be a web server
and everything in between. (MATLAB knew it was also FFT and graphical,
but the line was drawn)
Want to get past only the experts knowing how to use arpack, lapack,
etc.
Prediction: the next ARPACK like thing will have one tenth the number
of lines and have many more innovations and contributors (BLAS and
lapack already have 4x redundancy thanks to single, double, complex,
double complex repetition of routines)
\section{Contributions of this thesis}