ascar

After the big update I had to spend an hour restoring it to a functional state including changing an about:config parameter to get the scaling right. Out of the box I got changes that broke my UI and no "beautiful" new UI to begin with (you need to actively change settings to convert). Also there is still a giant clonky Win98 scrollbar on my folders, so getting that clean look in the marketing screenshots is impossible unless I severely reduce folders so I don't need the scrollbar. Why the scrollbar wasn't replaced with something more modern? No clue.

When I read the title I thought this is going to be an ethernet competitor similar to Infiniband.

I'm curious where you are living while trying this and what language you speak with your spouse.

I'm German and have a foreign spouse living in Germany. I speak English with my spouse, work mostly in English and spend most of my free time using English. For neither of us English is the native language though.

I guess it's a dramatically different experience if you try to teach your child a language that's not used in the household and not used in the country. E.g. me speaking German with my child in Germany, while we use English as the common language, should be a lot easier than my spouse trying to teach a language to our child that's not spoken in the country.

This is all theoretical for me as kids are still a few years away, but a question I have been wondering about in a long time.

If I recall correctly in TCP a packet loss will cause a signifcant slowdown in the whole data stream since that packet needs to be retransmitted and you generally end up with a broken data stream until that happens (even tho TCP can continue to send more data in the meantime meaning it's more of a temporary hang than a block). Thus if you are sending multiple different data streams over the same TCP connection a packet loss will temporarily hang the processing of all data streams. A constrain that QUIC doesn't have.

Intetestingly (or rather not surprising at all?) http3 is eating away the http2 traffic, while http1 just stays on a very slow decline.

Since http1 webservers are usually stuck there for a (more or less) good reason, they won't be converting to http3 anytime soon, while already more modern webservers are easier to upgrade from http2 to 3.

Are they? Would you elaborate on it or link some reading material? I've never heard of religion being heritary and your claim is pretty strong to just throw out there without any additional information.

if you read the comments posted here and know the spirit of this community, it's pretty obvious this isn't in the spirit of it. People need information, but this isn't the place for "me too".

Discord desktop client is having an outage due to cloudflare. You are not blocked from discord, this is an error and will resolve itself with time.

In the meantime you can go to discord.com and use the web application or the mobile version. They both are not affected.

@dang can we block comments on this or delete or something?

yea blocked Discord users googling for help and it's the first result. it being flagged doesn't take it off Google though. It's the first hit for me when Googling "discord block"

looks like Discord users searching for the block found this thread and signed up to comment.

the block is real tho. I can't login through my desktop client. Using the browser app works though. Maybe they disabled the Cloudflare CDN on their website as an emergency fix but couldn't easily do it for the desktop (i assume electron?) app?

this was posted here and flagged https://news.ycombinator.com/item?id=37701476

I don't know why it's flagged tho, because it's true. I can confirm my desktop client is blocked (same screen as in the article), but funnily enough I can go to discord.com and login through the webinterface. Maybe they disabled the cloudflare CDN as an emergency measure in their webapp?

GPT translates incredibly well.

Doesn't that really depend on the metal? E.g. copper is a great thermal conductor while stainless steel a really poor one.

> No practical quantum computer exists, and nobody has a realistic concept for building one.

Can you expand on that? I'm not involved in the field, but there certainly exist many low qbit machines with varying technologies around the world that can already be used for calculations. Yes, they're nowhere near big enough to be useful yet, but qbit counts in the biggest machines are multiplying every year similar to Moore's law, so that seems to be just a matter of time.

It's hard to call it a bug given that any concurrent float sum or product will be different in regards to changing the amount of concurrency. Even if you order the final value per thread before reducing the result will differ if you use a different amount of threads to split the problem.

Because in floating point arithmetic 1 + 2 + 3 + 4 is different than (1+2) + (3+4).

To nitpick in addition to the already existing comments: this has nothing to do with GPUs per se. You would see the same issue in multithreaded code on a CPU. Even on a single core CPU this can happen with a multithreaded program depending on how the OS schedules and interrupts the threads. It just happens to be an implementation choice in a GPU library/API.

> Most Ivy League students weren't born smart. They're exceptional because they were given access to what they needed to succeed.

The most ironic part here it isn't the school and education there that makes them exceptional. The schools filter so harshly that just getting admitted already means you are exceptional. And they can do that because of their good reputation, which is mostly based on tradition and perception.

Ha, imagine MI5 agents frantically trying to figure out how the D-day codenames and other content resulted in actual espionage.

> Location information cannot be effectively anonymized without basically nullifying its utility.

I was under the impression that properly anonymizing location data includes aggregating a sufficient amount of individuals and the radius of this aggregation of course changes based on the population density in a given area. In with anonymized location data we can only draw conclusions on a populace and not an individual, which is still very useful.

Of course, I generally agree with you. In most cases it won't be done properly and just replacing PI with the same "anonymous" id on a set of location data points of an individual achieves next to nothing.

So before 2001 your OS didn't have a scheduler and was incapable of handling more than one process at the same time? The user interface was simply hanging when you told your CPU to do something?

If there is no dependency between your results, you do not need synchronization. Parallelizing it just means putting them into a seperate stream of execution. That can be a thread or an entirely different computer and the two different execution streams need to synchronization or communication between each other.

That is an entirely different set of problems than having to deal with a computation that has close dependencies and now you need synchronization and communication to progress the compuation. You don't only have to think about how to synchronize your computation, you also have to think about how to distribute your data to begin with to minimize the need for synchronization. An entire set of problems that just don't exist in the former case.

To pick up a word you used: In one case you have many independent tasks and you want to run them as quickly as possible. In the other case you have a single task and you think about how to split that up to make it faster.

> The distinction I learned was: any time you have multiple logical threads of execution you have concurrency, any time you have multiple computations happening simultaneously, you have parallelism.

I like this distinction as it also splits the different problem domains quite well. And I don't think it contradicts my definition as much as you might think.

When you have an embarrassingly parallel program you do not have to deal with the problems that come from data dependencies and synchronization of your simultaenously running compuations on different threads/machines. You do not really have to think about your computation running in parallel, but just about how to put them into different execution environments to run them concurrently. So you end up doing "concurrent programming".

When you do not have an embarrassingly parallel program, you still use the base concepts of running something concurrently (e.g. threads), but now your main focus shifts on how the multiple compuations can happen simultaneously. Now you end up doing "parallel programming" or parallel computation.

In the end, the terminolgy here is less than ideal. My main point was that some kind of distinction matters as TFA clearly discusses different topics from what many people think about from a web dev perspective (e.g. async, futures, etc.)

Memory bandwidth can be increased by parallelization though. E.g. MPI (Message Passing Interface) is one of the major libraries in parallel programming and supercomputing and deals with parallelization across multiple machines.

but it's just not a tiny minor difference. The problems you end up dealing with are entirely different.

The terminology used might be terrible since they're originally synonyms. Differentiating between the two is very useful though.

Well, funnily enough this does read in contrast to the definitions used in Wikipedia, which are the ones I am also familiar with (I also do teach a class called "Parallel Programming" to graduates).

I do think the differentation make sense from a perspective of problem classes, as also evident from the comments here. Running independent problems in parallel to better utilize hardware ressources is very different from running problems in parallel in timesteps that have strong dependencies in regards to progress of the overall computation. And that's not a problem of the scheduler, but a much more general concept.

It doesn't sound to me like the author has the whole web service parallelism/concurrency in mind that is very apparent in the comments here.

I don't think IO bound and CPU bound problems are the correct way of differentiating between the two. Parallel programming deals with real-time problems with data dependencies and synchronization requirements. While concurrent programming deals with independent computations, where progress or completion of one does not depend on the progress of another.

I agree however they do ultimateively solve two very different domains of problems and there is a lot of confusion going on here.

On a side note: matrix multiplcation is generally not a CPU bound problem, but a memory bound one.

I see a lot of confusion between parallel programming [1] and concurrent programming [2] in the comments here.

The former and what this book is about deals with the problem of parallelizaing a single sequential program. There usually is strong interaction or dependencies between elements and progress needs synchronization. E.g. timestep iterations in real-time simulations that need synchronization with data communication after each timestep. These simulation also tend to get way to big to be run on a single machine, lest a single thread, and get scaled up to millions of cores/threads in supercomputers.

Concurrent programming is what most developers working with the internet are more familiar with. You have mostly independent tasks that you want to run concurrently. "A concurrent system is one where a computation can advance without waiting for all other computations to complete." [2] E.g. nginx serving thousands of user requests at the same time.

The problem domains have a lot of overlap on the basics (e.g. threading), however the focus is very different. Things like synchronization (mutex, barriers), cache locality and memory bandwith & latency play a central role in parallel programming, while concurrent programming focuses more on the engineering challenge of distributing independent tasks across multiple threads or machines.

[1] https://en.wikipedia.org/wiki/Parallel_computing

[2] https://en.wikipedia.org/wiki/Concurrent_computing

What you're looking at is pretty much concurrent programming.

https://en.wikipedia.org/wiki/Concurrent_computing

Google search isn't a good example. AAA games are a great example when you think about graphics. However, most of that is trivially parallelizable, thus "all you need to do" is assign vertices/pixels to different threads (in quotation marks as that's of course not trivial by itself, but a different kind of engineering problem).

However, once you get into simulations you have billions (or multiple orders of magnitude more) elements interacting with each other. When you simulate a wave every element depends on it's neighbors and the finer the granularity the more accurate your simulation (in theory at least).

Cache locality is certainly an important aspect and especially when it comes to matrix multiplication even just changing the loop order (and thus access pattern) has a huge performance impact. However, an O(n^3) algorithm will always loose out to an O(n^2*log(n)) algorithm, when the input gets big enough. And the difference between these two might be as simple as sorting your input data first.

I teach parallel programming to graduates and the first exercise we give them is a sequential optimization for exactly that reason. Think about if your algorithm is efficient before thinking about all the challenges that come with parallelization.