335 karma · joined February 1, 2015
But if you had been wrong and we would now have had superintelligence, the upside for its owners would presumably be great.
... Or at least that's the hypothesis. As a matter of fact intelligence is only somewhat useful in the real world :-)
The city heating network operator is a monopoly, that is why the price is capped.
Even though city heating networks utilize 'waste heat', the capital cost of the network is significant. The price cap and the capital costs (especially now with higher interest rates) led to many proposed projects being cancelled in recent years.
> The imported junk we get from Netherlands is abysmal compared to anything grown locally, and the reality is that we want the good stuff for ourselves, not the tourists.
This hurts, and it's absolutely true.
Makes me wonder why we spend so much in subsidies for the dutch tomato growers, if nobody actually likes eating them.
For what it's worth, I get them in the supermarket, grown in spain, if at all possible.
In environmental discussions that measure is usually something of grams-of-CO2-equivalent emitted per km. One oddity is that the usually communicated figure is only that emittted 'at the tailpipe', which is obviously zero for full electrics. Often people try to compensate by taking the kWh-per-km figure and multiplying by the CO2-per-kWh figure for their environment. This is however still misleading if compared with the tailpipe CO2 for an ICE, because the production of gasoline or diesel are also fairly CO2-intensive.
The official term of use is well-to-wheel efficiency or emissions; there is no doubt at all that electric vehicles beat ICE vehicles easily, basically on account of the ICE being relatively inefficient because of size/performance constraints.
Obviously the actually interesting figure of merit is the lifetime emissions (and the 'useful work' gained from those emissions) and while methods and tools to compute this exist computing this in a reasonable way means making a lot of assumptions (such as the miles-per-lifetime), assumptions that will be easily attacked on internet fora, and assumptions that can easily be tweaked to show what you want to show.
The reality is that (full) electric vehicles are practical and efficient for most of the population today, if not in the very near future, and that it's hard to imagine that the current dependency on oil will last very long. Ten years is a long time.
- The Rust compiler uses the LLVM backend, which is generally more aggressive about optimizations and code generation. The Go compiler is a custom compiler (I think plan 9 inherited) and as of fairly recently didn't do some optimizations that are fairly common otherwise (non-leaf inlining).
- Rust as a language heavily favors automatic (stack) allocation, and does not favor complex object graphs, so that will often help make algorithms more cache-friendly. In go, stack allocation is strictly an optimization. This is somewhat defeated by the common use of 'smart' pointer types.
- Due to using segmented stacks, the function prologue/epilogue is a bit more involved in go, than it is in a language like rust.
So with rust, it is - with some work - possible to have code that executes as the equivalent C code would. I guess in go you could too, but it'd be quite a bit harder, and go against the grain of the language.
Compared to the performance of a typical interpreted dynamic language, this is a fairly marginal difference however.
- Given that in this IR, every value has a single definition, and every use must reference that value, I'd argue that this is already SSA form.
- In fact, the concept of 'variable' is mostly missing, there's only a repeated reference to the same value. I think that simplifies things a lot, but maybe too much.
- Optimizing across expression boundaries is in fact very much the point, if we can keep the semantics the same.
Thanks for your interest!
Note that those numbers when I last looked into it typically include industrial and agricultural water use - residential water consumption is usually approximately 15% of total water use, so that fits reasonably.
One problem is that in many countries, water consumers (e.g. farmers) are able to withdraw water from their own soil, and so nobody really knows how much water that is, although it's possible to make educated guesses.
[1] https://www.statista.com/statistics/263156/water-consumption...
At an average, rather immodest level of water consumption per capita (~1580 m3/annum), then this is about ~4740kWh per year, or 13 kWh per day. I'd say this is significant, but then:
For comparison, current energy use per capita in the USA is 7000kg-oil-equivalent [2] (or 81000 kWh [3]), so an additional 4740 kWh is about 5%.
The real problem is that people use absolutely indecent amounts of energy and water and other resources, usually for no good reason at all...
[1] https://s3.amazonaws.com/academia.edu.documents/45145253/The... [2] https://data.worldbank.org/indicator/EG.USE.PCAP.KG.OE?locat... [3] https://en.wikipedia.org/wiki/Tonne_of_oil_equivalent
I've always been thinking - someone should give these guys money, and lots of it.
a): 'Studying' is definitely very important to get an idea of the context of the thing you are trying to solve. (I did a lot of reading both before and during the project). But, it doesn't always relate easily to the problem you have right now. (E.g. I'm using linear scan allocation, and the papers on that method all glossed over the nature of a 'live range', which took me 3 iterations to figure out). And without a practical problem to guide you, it is easy to get lost in literature.
b): What I find is that before I try to do something, I typically put together a high-level overview of how I think I can achieve it (what stuff to change where, and what I will need for that, roughly). But I'd classify that more under planning than under studying per se.
What I also do is take lots of notes. I have several large org-mode files (big fan) and before that paper notebooks in which I write down thoughts as they come up. I think org-mode is superior because it lets me organize things after the fact. Notes are a crucial bit of making progress for me, because I don't need to revisit the same things over and over.
The other thing that I find helps very much (and which I wasn't very good in at first) is to do incremental, small-step improvements. Move a function here, change an struct there, change an interface, move some process earlier or later, split it up. Simple things that you can do and that you know will not go wrong. Many problems can be broken down in that way, and the few that can't can at least be 'isolated' so that you can fix them 'atomically'. I wrote a blog post about this some time ago, if you'll excuse the link: http://brrt-to-the-future.blogspot.com/2016/06/in-praise-of-...
c): I was lucky to be able to join the perl community as part of a GSoC project, and fortunate that the perl community is altogether friendly and welcoming. And I really can't speak for the node.js people at all. But what I will say that anyone with a genuine interest in contributing (as you seem to have) and a willingness to do the work to learn (and to listen) will find a warm welcome from nearly all open source projects, because all of them are relatively understaffed compared to their ambitions :-)
So in your situation, I'd start with checking out the node.js source, start with trying to figure out how a debugger could work (there is lots of prior art here, of course, so you can check out the chromium source as well), and ask your questions basically as the jvns comic demonstrates.
I hope that answers some of your questions.
I should add I have had support of more people than I can name :-)
In 2014, for the Google Summer of Code program, I applied to build a JIT compiler for the MoarVM virtual machine. (It is actually more correct to speak of my work as a JIT backend than a full-fledged compiler - the 'frontend' of the compiler was already under development when I started). At the time, I knew just short of nothing about compilers, let alone JIT compilation. So what I did instead was learn, and make lots and lots of mistakes.
And it worked. The JIT backend I created has been in production since 2014, with a new backend since 2017, and a small (but thriving) community of contributors. It is far from the worlds most advanced JIT compiler, but it does provide a nice speedup on real-world perl 6 programs. All the while I've continued learning.
So... definitely try ambitious things :-)
Disadvantages?
And the actual numbers are considerably less optimistic than you report, and that paper was rather optimistic to begin with.
But I agree with the gist of it: storage worries are quite a bit overrated,and oversupply and transmission capacities are underrated. We can fix those easily enough, though
So in other words, I don't really understand why you are arguing for replacing a standard - one that works well for its purposes, mind you - with another when this has in fact already happened. And even less I understand why you are trying to frame a good and sound engineering decision as somehow a mistake?