Using just one programming language for everything is not really possible.Īlso, programming languages are tools, so limiting yourself to just one is dumb.
Blitzmax 3d tuning how to#
If someone is skilled enough to write a compressor, even a simple one, I do no think a garbage collector is needed.Īt least I learn how to do without "bells and whistles" at about 15.5 years old, and now I am 48.8 In my "compression" I write directly by assembler into memory, no library no nothing. > In any case: C/C++ is (maybe) 3 order of magnitude more common of Rust (as today) Than integrated threading in some other languages, where you'd have to fight the language Yes, its currently better to not use language support (like std::thread) for this,īut low-level threading is actually very simple and much easier to maintain
Blitzmax 3d tuning software#
> The "big" problem is multithread: C/C++ relies on external libraries, some very good, some very badĪll software in any languages would rely on "external libraries" such as pthread for MT. That may be an industrial requirement (since C++ is not really portable, or something).īut C++ is very useful for high-performance algorithms,Īnd recently I see a trend where algorithm is developed in C++, then gradually ported to C. > Almost "everything" is written in C, it is like English. Yes, zpaq just uses a hashtable and a window buffer, but its still a custom hashtable,Īnd paq doesn't represent all compression algorithms. They're mostly not reliable enough to be used in compression. it would be 10x slowerĪnd at most would work as a good fuzzing experiment for standard libraries. You can try implementing something with STL maps and such. Its in fact so important, that custom memory pools and other components have to be implementedīasically individually for each compression algorithm. No, dynamic memory usage is very important. > this kind of software you do not need to learn how to alloc something. > Almost no garbage collectors, or others "facility" are needed: if you write Libsais is ~8 kLOC for just one branch, paq8px ~11 kLOC, JpegXL is ~56 kLOC without libs, etc.Īn archiver (like 7-zip) would include tens of such codecs. Sorry, but that's very out of date, zstd is 35-40 kLOC, oodle is something like 100 kLOC. Compression algos are typically very small, maybe 1.000 LOC or less
0 kommentar(er)
