Let's design a suckless bignum library. (I'm not part of suckless though, just curious about replacing GMP).
I researched a bit into algorithms and the rundown is this: * long multiplication: O(n^2) * karatsuba O(n^1.5) * Toom-Cook, fourier transform based methods - even faster but only used for numbers 10k digits+ long. Much more complex.
So we should probably use karatsuba for all multiplications. Squaring can be done a bit faster than multiplying two different numbers sometimes.
Now I suggest programming it in assembly, that gives you access to the carry bit (C doesn't get you that). Of course we will use libc and the normal C calling conventions so that it's a regular C library.
What to do about memory management? e.g. if you want to add two numbers do we need to allocate a new 'number' as long as the largest to write the result into or do it destructively "x <- x + y"? Maybe the library should support both - then a calculator program would figure out the best primitives to use for a given computation.
It might be nice to also support things like (big modulus) modular arithmetic and polynomials. stuff like exponentiation and modular inverses have interesting algorithms.
What other integer operations would we want? I don't really want to do anything with arb. prec. real numbers - arithmetic with rationals could be done though.
k = m + n; hebi_zerop(w, k+1); hebi_mulp_karatsuba(w, w+k+1, a, b, m, n); hebi_addp(r, r, w, l, k); hebi_subp(r+m, r+m, w, l-m, k); }
Assumes an >= bn >= ceil(a/2). All temporary/work memory is allocated up-front using a discrete upper-bound function to compute the space required and is passed in through the 'w' pointer. Should be a lot faster than libtommath, which performs multiple allocations/deallocations at each recursive level.
Name:
Anonymous2015-12-16 11:05
dubs
Name:
Anonymous2015-12-17 2:12
Optimized row-order long-multiplication for x86-64.
Some micro-benchmarks on my AMD A10-7850K, multiplying 2000 iterations of 16384 byte x 8192 byte -> 24576 byte length integers: Standard C long-multiplication kernel: 22.61794163 seconds x86-64 assembly long-multiplication kernel: 6.17667357 seconds Karatsuba w/ Standard C long-multiplication kernel: 8.23420589 seconds Karatsuba w/ x86-64 assembly long-multiplication kernel: 2.34662074 seconds
Name:
suigin2015-12-17 2:25
Also, my software is no longer s̶u̶c̶k̶l̶e̶s̶s̶communist software. I hereby christen my software as your choice of traditionalist software, heroic software, spartan software, Spenglarian software, or reactionary software. Take your pick.
Don't get me wrong, the suckless people write nice software. And I'll continue to use it. It's a shame their software sentiments do not extend to real-life.
On one hand, they favor small, decentralized software programs. On the other, they advocate for collectivization, centralization, and increasing power of the state, in order to ``apparently'' eliminate it.
>>125 I said nice software, not perfect. I too was aghast when they started ``refactoring'' one line fragments into their own functions for sake of ``readability.'' I also don't like how their ls(1) defaults to column output with -l. Whoever the fuck did that should have just used a shell alias to scratch their own itch.
So what to do, revive anon coreutils? Fork sbase? Easy. At that point, the problem isn't so much the software, but creating and nurturing a viable community. Therein lies the real undertaking.
>>116 Alright, compile-time function multi-versioning is now fully working for x86-64. It strips out everyone you don't want, according to your `config.inc' file, and calls the kernel functions directly by address.
See config.mk on how to configure it for static mode, and run $ make config.inc to generate your `config.inc' file for editing.
Dynamic run-time multi-versioning still works as before.
Name:
Anonymous2015-12-17 11:26
A big num library that outperforms GMP would be a historic /prog/ event.
>>124 I think software should speak on its own, no matter what the developer's political ideas are, or their favorite food or where they live, etc. If the software is good, it's good. The end. Also, the suckless and 2f30 community are composed of several people with very different ideals. The thing they have in common is: simple software. The rest? Doesn't matter. Forking won't improve the software just because you have different political views compared to some of the members. I think you're taking the wrong turn, but that's just my opinion.
>>126 If you send a simple patch + rationale for the patch, it'll almost surely be accepted. And sbase will be improved. But saying the current implementation has such and such flaws won't help. Discussion (with patches provided) will help in the other hand. Join #2f30 suigin. Fragmentation isn't the answer, I believe.
Hey Suigin. Will you update your bc(1) with big-integer support by using either hebimath or libzahl? Are you working on any other suckless project or still busy with the soul-sucking corporate job? I hope you have fun soon.
Name:
Anonymous2016-05-30 2:10
>>138 bc(1) isn't a priority for me. Still working on hebimath in my personal time, libzahl has definitely been a strong influence in terms of design. I've got some major changes and additions in the pipe.
In my opinion, neither libzahl nor hebimath are suitable for a suckless bc(1). What you want to use there is a very minimalistic suite of functions.
Name:
Anonymous2016-05-30 5:14
>>139 That's fine. suckless isn't suitable for anything anyway.
Name:
Anonymous2016-05-30 10:15
the critical flaw in suckless is that they're trying to prevent bloat by optimizing for SLOC. this does prevent bloat but in a suboptimal way that sacrifices functionality and usability for user and maintainability (because muh SLOC limit) and readability (because a dirty deep magic hack can have less SLOC than a proper solution) for programmers.
for example, does anyone actually browse the web with surf? no, because it lacks features for actually browsing the web (that goes double for powerusers who like seeing source, inspecting or just having over 9000 tabs at the same time). rendering HTML is not enough.
the proper way of making a bloat-free project (especially hobby projects where you don't have corporate assholes with their deadline, changing requirements and le enterprise agile UML XML smart IOT buzzwords) would be a clearly defined scope (THE most important thing), a simple (preferably modular for easier maintenance) design and an adherence to good coding standards.
basically, aiming for low SLOC count makes sense only if you're doing code golf. if you want to make actually useful software, it should just be a rule of thumb
Name:
Anonymous2016-05-30 12:21
>>141 How about forgetting about the whiny kiddie notion of "bloat" altogether, and just make sure the program runs fast enough in real-world usage, can be maintained, and has a well designed feature set? Do whatever it takes to make that happen, fuck the haters.
that's nebulous as fuck though, things that work fast enough on my gaming PC will be slow on my 7-year old laptop which wassn't even that good when I bought it. and that's a real concern because both browsers and webapps got so bloated, said laptop will be slow at basic web browsing unless I disable all the JS bullshit.
also
runs fast enough in real-world usage, can be maintained, and has a well designed feature set
isn't the whole thing synonymous with not being bloated, avoiding feature creep etc. while maintaining functionality? aka the thing I've been talking about all along.
basically, bloat isn't about SLOC. it's about feature creep, overengineering and plain old adding useless bullshit to impress the general audience.
isn't the whole thing synonymous with not being bloated, avoiding feature creep etc. while maintaining functionality? aka the thing I've been talking about all along.
No, the term "not being bloated" means a billion different things, usually harping on faggot concerns like nitpicking the size of the source code base or the memory footprint.
Overture - To walk a less harmful path ===============================================================================
It is a well known phenomenon that all great fields of science and higher thought at a particular point in history reflect the unique nuances and aspects of culture of their host civilizations. When it comes to the perilous state of the field of ``Computer Science'' and the software development community at large, it is no different. One simply has to look at the culture and direction of the present civilizations that currently hold grip over computing to understand the source of our predicament.
When a cycle of civilization is reaching its end, it is difficult to achieve anything by resisting it and by directly opposing the forces in motion. The ``current'' is too strong; one would be overwhelmed. The essential thing is to not let oneself be impressed by the omnipotence and apparent triumph of the forces of the epoch. These forces, devoid of connection to any higher princ- iple, are in fact on a short chain. One should not become fixated on the present and on things at hand, but keep in view the conditions that may come about in the future. Thus the principle to follow could be that of letting the forces and processes of this epoch take their own course, while keeping oneself firm and ready to intervene when the great behemoths of the software and computing world--and their supporting base of ignorant users--finally succumb to irrelevance.
The old Christian saying ``resist not evil'' may have a similar meaning, if taken in a very particular way. One abandons direct action and retreats to a more internal position. The perspective offered by the doctrine of cyclical laws is implicit here. When one cycle closes, another begins, and the point at which a given process reaches its extreme is also the point at which it turns in the opposite direction.
But there is still the problem of continuity between the two cycles. To use an image from the poet Hofmannsthal, the positive solution would be that of a meeting between those who have been able to stay awake through the long night, and those who may appear the next morning. But one cannot be sure of this happening. It is impossible to foresee with certainty how, and on what plane, there can be any continuity between the cycle that is nearing its end and the next one.
My assertion that today there is no political system, no software development community, and no computing methodology whatsoever worth devoting oneself to, and that everything existing must be denied, likely disconcerts many. However, this denial and non-commitment do not derive from a lack of principles, but from the possession of principles, which are precise, solid and not subject to compromise. In the life of today it can be appropriate, for many, to withdraw in order to settle in a more interior line of trenches, so that which we cannot do anything about cannot do anything against us.
However, it should not be encouraged that people let themselves go, but precisely the contrary: a strict discipline of life and of computing brought to the highest point should be the foremost aspiration. On this inner, spiritual plane of the individual, what is required is the opposite of non- involvement. To draw your attention to the possibility that, before thinking of outer actions, often dictated by momentary enthusiasms, one should think of the formation of oneself, the action on oneself, against everything that is formless, temporary, mediocre and borgeois.
We must thus pay attention to the particular plane of problems that are oriented inward from the anterior, and moreover, realise that not every individual we come across can expect to identify himself with modernity. Perhaps he too is alienated from the present and desires only lucidity and realism in how he conducts his life and carries out computing. Therein a common ground can be found. And if there are men willing to fight in spite of all, even on lost positions, one should be most grateful to them.
Name:
Anonymous2016-05-30 15:09
Manifest =======
Many (open source) hackers are proud if they achieve large amounts of code, because they believe the more lines of code they’ve written, the more progress they have made. The more progress they have made, the more skilled they are. This is simply a delusion.
Most hackers actually don’t care much about code quality. Thus, if they get something working which seems to solve a problem, they stick with it. If this kind of software development is applied to the same source code throughout its entire life-cycle, we’re left with large amounts of code, a totally screwed code structure, and a flawed system design. This is because of a lack of conceptual clarity and integrity in the development process.
Code complexity is the mother of bloated, hard to use, and totally inconsistent software. With complex code, problems are solved in suboptimal ways, valuable resources are endlessly tied up, performance slows to a halt, and vulnerabilities become a commonplace. The only solution is to scrap the entire project and rewrite it from scratch.
The bad news: quality rewrites rarely happen, because hackers are proud of large amounts of code. They think they understand the complexity in the code, thus there’s no need to rewrite it. They think of themselves as masterminds, understanding what others can never hope to grasp. To these types, complex software is the ideal.
Ingenious ideas are simple. Ingenious software is simple. Simplicity is the heart of the Unix philosophy. The more code lines you have removed, the more progress you have made. As the number of lines of code in your software shrinks, the more skilled you have become and the less your software sucks.
Name:
Anonymous2016-05-30 20:43
>>148 What a pile of horseshit, projecting his pet peeve onto everyone else.
Name:
suigin2016-05-31 6:07
>>147 Someone finally noticed! It was actually meant as a half-serious joke to create board drama, but no one picked it up until now... Now it's too late. I may end up removing it and the bonus/ content from Hebimath when I get close to tagging a release.
>>145 I already said those concerns are mostly bullshit so I'm not sure what are we arguing about
Name:
Anonymous2016-05-31 8:14
>>151 I'm arguing that you should stop using the word "bloat", because it's meaningless and associated with faggots.
Name:
Anonymous2016-05-31 8:55
>>152 what would be the better term? 'feature creep, reinventing the wheel, Greenspun's law, pointless fucking bullshit that keeps running in the background, labyrinthine object oriented design and the very existence of XML' is a bit too long.
>>150 I notioced a long time ago. Almost went as far as submitting a patch to edit the suckless philosophy page with your joke text, but decided not to bother them. The bonus/ is cool too.
Name:
Anonymous2016-05-31 16:55
The idea that a vast majority of 'hackers' measure their e-peen by LoC is one of the more stupid delusions I've seen in a long time. Fuck suckless.
Name:
Anonymous2016-06-01 5:18
>>157 You're confusing what Suckless desires with low LoC, because low LoC ends up being a side-effect of it.
To understand what Suckless is really after, here's the essence of it: