I can't speak to the staging process, but I became all too aware of how
to cause cache misses on a SPARC (:--)
In a mature, sane and well-debugged program, write #define debug()
macros so they always caused a cache miss even when not turned on, then
sprinkle enthusiastically throughout all the hot parts of the program.
--dave
On 27/03/17 01:22 PM, Jesper Louis Andersen wrote:
In addition, there are also the notion of "staging meta-compilation" as
witnessed in e.g., BER-MetaOCaml.
The idea is that if you want the best program efficiency, no compiler is
able to carry out the needed optimizations. So you start meta-compiling
by staging the compiler and generating code at each stage for the next
one. Preferably in a type-safe manner. You can get some tremendously
fast computational kernels out of this method. Usually, such speed only
matter to a small part of a code base, so the effort is well spent doing
these kinds of optimizations. Or it matters a lot in which case you need
a GPU, FPGA or ASIC to make it run fast enough.
Generics are trying very hard to be a lot of things at the same time:
Convenient notation, Efficency, and Type safety. This means it has to
make trade-offs along those areas, one way or the other.
As for Code Size and icache misses: back in the day, the MLton project
found that code expansion usually happens on a few types. Less than a
handlful is the common case. And because (polyvariant) inlining follows,
there are a lot of situations where the code size expansion doesn't
matter at all to a modern largeish icache. Of course, this was 15 years
ago, so many things may have happened in the meantime.
On Mon, Mar 27, 2017 at 3:11 PM David Collier-Brown <davecb...@gmail.com
<mailto:davecb...@gmail.com>> wrote:
Folks, is this something that we should do with a template processor?
More topically, is this a set of somethings that we should prototype
each of, using templates?
I'd love to see actual experiments in computer "science" (;-)) and a
debate about the tradeoffs based on code.
--dave
On Monday, March 27, 2017 at 2:40:12 AM UTC-4, Egon wrote:
On Monday, 27 March 2017 04:06:17 UTC+3, Mandolyte wrote:
I agree that it makes the suitable trade-offs. And Linq is
doing pretty well without generics
(https://github.com/ahmetb/go-linq); not familiar with Rx.
When I consider the dilemma, the two things I don't want are
slow programmers and slow execution, leaving "slow compilers
and bloated binaries". But here is how I think about this
option:
- There are alternatives that only impact compiler speed if
they are actually used. I think that's fair.
The unfortunate reality is that when you add generics to a
language it will be almost impossible to avoid it.
And the dilemma is not a binary-yes-no... e.g. would you give
100x performance to have fast programmers, fast execution and no
code-bloat... or would you give 10% performance for medium speed
programmers, fast execution and some code-bloat?
It's better to view the dilemma as a rating system. As a
facilitated example:
/copy-paste:/
1. convenience: 0/10
2. code size: 10/10
3. performance: 10/10
4. flexibility: 10/10
5. readability: 5/10
/interfaces:/
1. convenience: 4/10
2. code size: 0/10
3. performance: 2/10
4. flexibility: 6/10
5. readability: 8/10
/type-level generics with boxing:/
1. convenience: 7/10
2. code size: 0/10
3. performance: 5/10
4. flexibility: 8/10
5. readability: 1/10
/package-level generics with out-of-bounds boxing:/
1. convenience: 6/10
2. code size: 3/10
3. performance: 8/10
4. flexibility: 5/10
5. readability: 7/10
*Obviously, do not take these numbers seriously.*
- There are alternatives that result in binaries hardly any
larger than if you copy-pasted. Again, I think that's
reasonable.
Here you are making a trade-off... it's not just about size, but
also about performance. More code means more icache misses.
The main point is that /"there are approaches that produce less
code than copy-pasting"/. So ideally we want smaller binaries
than you would get from copy-pasting.
As I understand it, the package template approaches fall
into this camp. So with the above restrictions, count me in
favor of slow and bloated :-)
Not necessarily. I suspect it will be faster to compile than
most generics packages and similarly dealing with bloat will be
easier.
On Sunday, March 26, 2017 at 9:08:20 AM UTC-4, Egon wrote:
On Sunday, 26 March 2017 15:30:30 UTC+3, Mandolyte wrote:
@Bakul - is your approach documented in Egon's
collection? I think it is essentially the same as
Egon's at
https://groups.google.com/d/msg/golang-nuts/JThDpFJftCY/1MqzfeBjvT4J
Perhaps your syntax is cleaner, simpler. I also like
this general approach. In Egon's document, this
approach has nearly no downsides.
Depending what do you want to use generics for, there
are significant downsides. Mainly, you cannot create
chained general purpose functions... e.g. LINQ, Rx...
/in the summary document see problems "functional code"
and "language extensions"./
You could argue that using such approaches is not good
for Go... but this wouldn't invalidate that this
generics approach doesn't solve these problems nicely.
You are always making trade-offs.
/Personally, I think it makes trade-offs that are
suitable to Go... but I understand why people would
disagree with it./
--
You received this message because you are subscribed to the Google
Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to golang-nuts+unsubscr...@googlegroups.com
<mailto:golang-nuts+unsubscr...@googlegroups.com>.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
