The Freedom Road Socialist Organization (FRSO) is a communist political party in the United States. FRSO formed in 1985 as a merger of several Maoist-oriented New Communist movement organizations.

In 1985, the Proletarian Unity League and the Revolutionary Workers Headquarters merged to create FRSO. In 1986, FRSO fused with the Organization for Revolutionary Unity. In 1988, FRSO absorbed the Amílcar Cabral-Paul Robeson Collective.

FRSO’s component groups believed that ultraleftism was the US New Communist movement’s main error. Merging under the FRSO banner, these groups hoped to consolidate the movement’s remnants in a single organization and move beyond the sectarianism that marked the previous decades.

1999 split

In response to the 1989 Tiananmen Square protests and the dissolution of the Soviet Union, FRSO began to develop two distinct positions on socialist countries. The “Left Refoundation” group, aligned with democratic socialism, argued that these events resulted from a deep crisis of Marxism. The “Fight Back!” group, aligned with Marxism-Leninism, argued that these events resulted from revisionism rather than failures within Marxism. These divisions grew during the 1990s. In 1998, the Left Refoundation group wrote an internal document, “Theses on Left Refoundation”, and requested an organization-wide discussion.

Both factions claimed the name “Freedom Road Socialist Organization”. In 2006, the Left Refoundation group renamed itself to “FRSO/OSCL”, combining the English and Spanish acronym. In 2019, the Left Refoundation group renamed itself to Liberation Road.

Publications

FRSO’s main publication is the website and monthly paper Fight Back! News (FB!N) and its Spanish section Lucha y Resiste.

Congress

The 9th Congress of FRSO, held in spring 2022, came at a critical juncture in the development of the people’s struggle and the accelerating decline of monopoly capitalism in the U.S. As the call to the congress states, in the recent period “we have seen a level of struggle that is unprecedented since the 1960s. The great rebellion following the murder of George Floyd, which was both broad and militant, signals the shape of things to come. It can be said the burning police stations helped illuminate the road to freedom. The fight against police crimes led to a resurgence of the African American national movement.”

Megathreads and spaces to hang out:

reminders:

  • 💚 You nerds can join specific comms to see posts about all sorts of topics
  • 💙 Hexbear’s algorithm prioritizes comments over upbears
  • 💜 Sorting by new you nerd
  • 🐶 Join the unofficial Hexbear-adjacent Mastodon instance toots.matapacos.dog

Links To Resources (Aid and Theory):

Aid:

Theory:

Financial Support to the Bearsite

  • FunkyStuff [he/him]@hexbear.netEnglish
    6·
    1日前

    Do you have a nested loop through all collision objects in your collision system?

    You know, something like:

    
for object1 in objects:
   for object2 in objects:
      if object1.collides(object2):
         #do collision logic

    Because this would explain why you’re only doing 20x better in terms of capacity. The Rust code is probably running roughly 400x faster, but each additional object in your system costs more than the last (because it means every single other object now has to check collision with one more thing). In total that comes out to meaning that speeding up the calculation by a factor of k only multiplies your capacity by a factor of sqrt(k). This is because it’s an O(n^2) algorithm.

    If you wanna learn how you can take that 1000 and make it 20,000 without multithreading, you could check out Sebastian Lague’s videos where he makes a fluid simulation. There’s one where he makes a particle based simulation and he starts it off by simulating forces between all particles, but he optimizes it later by splitting up his simulation into square tiles. A particle then only needs to apply force to particles in its own tile and adjacent tiles, but no farther than that.

    • Carl [he/him]@hexbear.netEnglish
      4·
      24時間前

      I haven’t actually stress tested the new Rust code yet to see what it can really do, 1000 is just the size I initially set the “asteroids” and “projectiles” object pools to, which are the primary collision-checking entities in the game.

      My original Python implementation did it the “check every other object” way, but the way I’m doing it now is by breaking up the play area into zones and having each object only check for collisions inside its current + adjacent zones. I implemented that in Python and it got me a pretty big speedup, although I didn’t properly quantify the speed increase at the time.

      The next thing I did was implement that same algorithm in Rust, and use PyO3 so that I could do the collision math in Rust while keeping everything else the same. I did properly quantify this speed increase with a series of benchmarks - the code got about a 3x speedup for <100 objects, 1.5x for 200-500 objects, and resulted in slowdown at 1000+ objects. I figure the issue was the transfer overhead getting unwieldy when copying that many tuple objects back and forth.

      What I’m doing right now is rewriting the whole engine in Rust while keeping Python as the “controller + monitor”. This lets me keep overhead to an absolute minimum - Python only sends control inputs down, and Rust only sends current entity locations up. I haven’t finished writing it yet so I haven’t gotten to stress testing what it can do, but I’ve already glimpsed how much faster it is because I’m able to fly at ridiculous speeds through the game area while spawning in ridiculous numbers of objects without any slowdown on the same machine that would start to chug at about 50 objects before.

      I’ll definitely check out those videos!

      • PorkrollPosadist [he/him, they/them]@hexbear.netEnglish
        3·
        20時間前

        A common optimization in collision systems is to attempt to partition the scene. By using a structure like a quad/oct-tree (this is not the only way), you can first throw the objects into buckets based on which partitions their bounding boxes overlap, and then check collisions in all these partitions separately.

        Doing a first pass with rough checks (radius to radius is very cheap, essentially calculating whether the distance between two vectors is less than r1+r2) before doing more precise checks can also help a lot. A lot of these checks can also be optimized by e.g. squaring the radius for the sake of comparison instead of doing a significantly more costly square root to find the actual distance.

      • FunkyStuff [he/him]@hexbear.netEnglish
        2·
        23時間前

        My original Python implementation did it the “check every other object” way, but the way I’m doing it now is by breaking up the play area into zones and having each object only check for collisions inside its current + adjacent zones. I implemented that in Python and it got me a pretty big speedup, although I didn’t properly quantify the speed increase at the time.

        Yo, cool! Then you did pretty much what I was suggesting. There might be some further optimizations to this based on changing what data structures you use, but you have the core idea down.