141–150 of 150 posts
Earlier quoted context omitted.
Are you suggesting to ban human players from drinking water during the match?
No, I wasn't. I don't think that a drink of water is the same as a battery swap.
Earlier quoted context omitted.
The vast majority of web apps are CRUD apps, which can achieve sub 100ms responses on any language with caching, background workers and minor optimizations. There will always be problems where you need faster responses, and the solutions to those problems are already not using Ruby. You don't use a hammer when a screwdriver is appropriate, but nails work pretty well in most places and screws are unnecessary.
100ms with how many responses per second? Throughput matters too. And techempower does some pretty realistic-looking benchmarks. For example: > In this test, the framework's ORM is used to fetch all rows from a database table containing an unknown number of Unix fortune cookie messages (the table has 12 rows, but the code cannot have foreknowledge of the table's size). An additional fortune cookie message is inserted…
As always, it depends. Benchmarks are cool, and yes we know that Rust and Go will always be faster than Ruby out of the box. Once the number of responses goes up, you throw caching at the problem. But the benchmark says
> The requirements were clarified to specify caching or memoization of the output from JSON serialization is not permitted.
> the table has 12 rows
Which is low and should be quick regardless, but regardless of your tech stack if you are creating a "modern" UI, you handle this update asynchronously with JS anyway, and if you're not, do you really care about sub 100 ms responses?
If you want performance out of the box, yes you will use Go, but like I said earlier, you use a hammer for nails and a screwdriver for screws. If you want performance and type safety, you choose one, if you want faster prototyping and a more mature web dev ecosystem, you choose another.
Earlier quoted context omitted.
No, I wasn't. I don't think that a drink of water is the same as a battery swap.
Why not the same? If you impose the restriction on competitors to use only the fuel that he/she has stored, it would be very unfair to allow one player to break this rule and refill himself.
Earlier quoted context omitted.
Mathematician here, I don't think the singularity as popularised through people like Ray Kurzweil would happen. In particular, their metaphor of an "infinity" point seems to me like the incorrect application of mathematical ideas to social contexts. I think the question of artificial general intelligence is a different question than a singularity, much like how the Chinese room addresses a different question than the…
Why is it a different question? AFAIK the assumption is that if the computer can improve itself (which it can if it has IQ 100), there is nothing holding the singularity back.
We don't understand physics well enough to know whether time (and space [1]) can be arbitrarily halved over and over.
For an actual "infinity point" you would need such halving of time of computation up to a point where you actually have infinitely small time increments. The way you would define this would be via a limit and again the main premise is arbitrary halving, something that we have not seen in nature and which is a mathematical tool, rather than a hard physical fact.
Since you have physical computers, the composition of such a computer would have to lead to computations in these infinitesimal time brackets and in turn, for example, may necessitate infinitesimal matter. The way I understand the Planck length, at least as a concept, is that after some really small length of space then essentially you don't get anything smaller.
In any case, talking about a "singularity point" is an activity done by social personalities who like to sound clever. But they are not saying anything remotely clear.
As I mentioned, the other argument that one can make is to challenge the ability to indefinitely "improve yourself" as a machine, another dubious claim.
[1] https://en.wikipedia.org/wiki/Planck_length
Edit: I am not a physicist, so there could be better ways to think of Planck length and discuss its validity.
The article discusses one of the impacts of compute performance growth rates slowing while compute demand (training AI models) is growing exponentially. The 'end of Moore's law' (as a measure of performance, not density) is probably the most significant "Tech" story of the next decade. Why? Because it is going to demand engineers who can write fast code over engineers who write code fast. A lot of frameworks and abst…
There doesn't seem to be anything in the horizon that would make performance a more pressing concern in the work of the 99% of developers who do make business software and consumer web/mobile apps. They just sometimes call into libraries that have had performance work put into them and get by with rudimentary understanding of what seems to cause slowdowns.
In the other dimension, there does seem to be a continued focus and resulting improvements in velocity.
The recent ML popularity is all about leveraging packaged optimized code (Tensorflow etc) with vast majority of programmers freed from the engine level details and detailed understanding of GPU perf work or parallel/distributed programming.
Earlier quoted context omitted.
I'm not sure that's a given, who's to say we won't be happy with the current performance we have?
There are still problems, like protein folding, or training larger and larger deep learning models, which have nowhere near the performance you'd actually want in a perfect world. There's always going to be a bigger target in some of these domains, and it would be a shame to imagine we'll reach a ceiling in some areas of scientific inquiry because of hardware limitations.
Earlier quoted context omitted.
Why not the same? If you impose the restriction on competitors to use only the fuel that he/she has stored, it would be very unfair to allow one player to break this rule and refill himself.
Water isn't an energy source, though. Letting the robot top off on, say, hydraulic fluid or coolant or whatever, might be the same. Even battery water.
Earlier quoted context omitted.
Water isn't an energy source, though. Letting the robot top off on, say, hydraulic fluid or coolant or whatever, might be the same. Even battery water.
But tennis players' drinks are definitely an energy source: https://www.quora.com/What-kind-of-sports-drink-do-professio...
Earlier quoted context omitted.
But tennis players' drinks are definitely an energy source: https://www.quora.com/What-kind-of-sports-drink-do-professio...
True. On the other hand, five comments up-thread, you specifically said "water".
Earlier quoted context omitted.
I don't think this is very true. You can trace the deep learning revolution back to VGG and a fundamental driver in the success of the first multi-level networks was the ability to train in semi-reasonable amounts of time using GPUs. Even today distributed training is relatively uncommon while pretty much everyone uses NVIDIA GPUs.
VGG was a long time after the first deep learning revolution.