crimsonalucard1

6 ms·

1.
by crimsonalucard1 6y ago
Doesn't the net CO2 in the air increase? So you harvest CO2 to into fuel. That fuel is burned and the CO2 is released back into the air. So net difference is zero. But to harvest the CO2 you needed to generate a high amount of heat. Th
2.
by crimsonalucard1 6y ago
>If you say IO is the bottleneck, then you're claiming there is no significant difference between python and node. That's what a bottleneck means. This is my claim that this SHOULD be what's happening under the obvious log
3.
by crimsonalucard1 6y ago
I'm hoping that other then treating diseases this thing can aid with enhancement.
4.
by crimsonalucard1 6y ago
I think you need to pause before considering this route. Are you that exceptional? This level of intelligence is incredibly rare and unless you're 100% sure you're capable of this, I wouldn't do it.
5.
by crimsonalucard1 6y ago
>Unless you've actually profiled the thing and shown where the time is used, all your assertions are nonsense. It's data science that is causing this data driven attitude to invade peoples minds. Do you not realize that logic a
6.
by crimsonalucard1 6y ago
>Well, it's odd that you say that, when previously you were claiming that it was caused by Python. Is it caused by Python, or is Python negligible? It's not odd. Think harder. I'm saying under the benchmark and according t
7.
by crimsonalucard1 6y ago
> I just think that your comparison with _node.js_ when there are a bunch of confounding variables is nonsense And I'm saying all those confounding variables you're talking about are negligible and irrelevant. Why? Because the
8.
by crimsonalucard1 6y ago
>Your logic makes perfect sense, in a world where I/O bound processes, JIT versus interpretation differences, garbage collection versus reference counting differences, etc., don't exist. But those things do exist in the real wo
9.
by crimsonalucard1 6y ago
Except the problem here is that those tests were bottlenecked by IO. Whether you're testing C++, pypy, libuv, or whatever it doesn't matter. All that matters is the concurrency model because that application he's running is b
10.
by crimsonalucard1 6y ago
As a general rule it works. Work friends are not friends. There are exceptions but don't expect anything.
11.
by crimsonalucard1 6y ago
Except IO is the bottleneck here. The concurrency model for IO should determine overall speed. If python async is slower for IO tasks then sync then that IS an unexpected result and an indication of a python specific problem.
12.
by crimsonalucard1 6y ago
When I talk about async await I'm talking about everything that encompasses supporting that syntax. This includes the I/O event loop. So really we're in agreement. You're talking about reimplementing python specific thin
13.
by crimsonalucard1 6y ago
Bottleneck is IO. Concurrency model should be the limiting factor here. NodeJS is faster than flask because of the concurrency model and NOT because of the JIT. The python async implementation being slower than the python sync implementatio
14.
by crimsonalucard1 6y ago
NodeJS primitives are enough to produce the same functionality as flask without the need for an extra framework.
15.
by crimsonalucard1 6y ago
Right but this test focused on concurrent IO. The bottleneck is not the interpreter but the concurrency model. It doesn't matter if you coded it in C++, the JIT shouldn't even be a factor here because the bottleneck is IO and ther
16.
by crimsonalucard1 6y ago
The database is the bottleneck. JIT or even C++ shouldn't even be a factor here. Something is wrong with the python implimentation of async await.
17.
by crimsonalucard1 6y ago
Yep and this test being shown is actually saying that about 5 sync workers acting on thousands of requests is faster then python async workers. Theoretically it makes no sense. A Task manager executing tasks in parallel to IO instead of blo
18.
by crimsonalucard1 6y ago
>And no I'm not interested in whatever benchmark you're going to want to post, That's rude. Let's put it this way. NodeJS and nginx leveled the playing field. It destroyed the lamp stack and made async the standard wa
19.
by crimsonalucard1 6y ago
No man. Nodejs will beat the flask benchmark. For this specific test there is no downside to async. What’s going on here is python specific.
20.
by crimsonalucard1 6y ago
This is not what is happening with flask/uwsgi. There is a fixed number of threads and processes with flask. The threads are only parallel for io and the processes are parallel always.
21.
by crimsonalucard1 6y ago
Yeah except nodejs will beat flask in this same exact benchmark. Explain that.
22.
by crimsonalucard1 6y ago
I see this elitist attitude all over the internet. First it was people saying “Guys why are you over reacting to corona the flu is worse.” Then it was people saying “Guys, stop buying surgical masks, The science says they don’t work it’s li
23.
by crimsonalucard1 6y ago
Dynamic code upgrades? Can you explain what that is and why a type system will prevent that from happening?
24.
by crimsonalucard1 6y ago
Yeah but usually that's not the case. Usually you can get it back. I would say more often than not it's reversible.
25.
by crimsonalucard1 6y ago
It is reversible. If you make a mistake like this oftentimes you can rely on law enforcement/bank to force the money to be given back. Not sure if this is possible with crypto.
26.
by crimsonalucard1 6y ago
I'm waiting for the day where 3D printers become so powerful that I only need a minimal set of these "physical" DIY skills to build random physical objects. Anybody know of a printer that can get me very close to this goal?
27.
by crimsonalucard1 6y ago
>but up close the details of say, managing state with hooks in React, is very different from managing state with services and RxJS observables in Angular. I would say learning the detailed difference when needed for the project is in f
28.
by crimsonalucard1 6y ago
>But if a candidate is motivated to take a job because they get to use shiny new technology, i would suggest that they are not, in fact, a good candidate. I would argue that this attitude often exists at the corporate level as well. Most
29.
by crimsonalucard1 6y ago
>In my experience, magpieism is associated with weaker programmers; not the very worst, but second quartile, say - people who get very engaged with superficial details, but don't think about deeper things. I may be biased because I
30.
by crimsonalucard1 6y ago
This stuff all comes from China originally. I'm Chinese so I know. It's because Chinese characters use to be written with brushes and with brushes the stroke order of the lines is very important for legibility and beauty. See the

More ›