Thanks! I persist with the Friendly Giant even though about 95% of the global audience, esp. the USA, has no idea what it's about! But i figure it's worth it for that tiny slice of GenX Canadians....
Please show the "current" leaderboard of all previously raced languages. I know that the videos are not really ordered but they DO have episode numbers after all :)
Fair enough! I'm going to bust out a whiteboard and camera and do it Top Gear style, since this is racing and all. I just need a mini stig... wish I had an Intel bunny doll!
It might be fun to put Cython in this group instead of Python since Cython is the backbone of several major Python data analysis packages (pandas, scipy, scikit-learn).
Good idea. Even though I've already done Python, I could include it but allow a numeric library, at least as an exhibition run to demonstrate what's possible!
This is fascinating. I only have a few years of basic programming classes from 20 years ago notched on my belt, but it's enough to pick up the interesting differences by immersion here. I suspect by the time this series finishes, I may just have some inspiration to go try a few of these languages out and get back on that train.
As a fellow Saskatchewan kid that started on a Magnavox Odyssey II and wrote my first stuff on a Coleco ADAM (with my mom), it's always sea-quall to me, haha. This is a fun series!
just because it requires a class doesn't mean it's bad, it needs to know where to start, you can also write a python program without functions and most languages won't compile that, so what?
Interesting video, but a few observations: 1) Machine language and assembler are the same thing. Assembler assigns a mnemonic to each machine instruction. It is a one-to-one relationship. It is simply a way to code in "letters" rather than "numbers" and was invented for that exact reason. All other languages use a one-to-many relationship. A C statement like "++a;" could translate into an "LOAD, INC, STORE" operation (far from the only possible implementation). 2) In a compiled language, the specific compiler, version, and optimization capabilities (and settings) can have a huge effect on performance. Further, the specific instruction set of the target machine can also have a huge effect. In the old days when compilers were only available from the hardware suppliers, it was very common for the compiler to take advantage of specific instruction unique to the hardware. A very old example was that on the IBM 360, there were native BCD instructions! I can remember when PC chips did not come with floating point operations (Intel 286 and 386). There are currently machines (and video cards) that can be programmed to use vector operations over arrays. The "look ahead" and caching capabilities of various processors differ dramatically. In an interpreted language, many comparisons are invalid because it is not the language that is being compared, but the implementation of the internal run-time library. A Perl implementation on one machine is not required to run identically to another machine, only to produce the same results. I remember using APL and the performance results of various operations were very different on different machines due to the differences in implementation. The short version of this is that tests can yield different results using different hardware/software/settings. Any comparison is limited to a very precise and unvarying specification! 3) IBM 360 JCL has no mechanism for looping, computation, or any other programming task. It only has the ability to test the "return" value of the previous operation (EXEC). It is possible that these capabilities were added in later machines and/or OS's, but I have no experience with them. Keep up the good work!
Thanks Dave. I made my living working with technology geeks, trying to understand and convert their knowledge into something mere mortals could understand. I had my share of fakers, trying to snow me with complex combinations of new words and concepts, poorly explained. I remember one session where I was told, "Our technology assumes some intelligence on the part of the user". On the other hand I thoroughly enjoyed working with true experts, those who where comfortable in their knowledge and were eager to share it with others. They explained using metaphors and simple stories, boiling their vast knowledge down to the essence that would reveal the beauty of their craft. They were always eager to share and they loved making new discoveries of their own. Your videos remind me of these session. Challenging but fun, I always up for the ride to the technology discovery store, knowing we're going to get something good. Growing up the 1970s watching drag racing in Fremont and working on cars at Bill's Arco, I appreciate your combined love of cars and computers. What a great time to grow up. Thanks for sharing!
I'm not TOTALLY sure but I'd wager Kia Sportage comes from the French "portage", which is to carry a canoe overland. I always found it odd that we had and kept our own pronunciations for things, but it happens elsewhere too. One thing I always found odd is Andrew Carnegie's name. It's pronounced CAR-NAY-GEE but they say "KARN-AGEE HALL" for the building!
@@DavesGarage to be honest, I always pronounced it exactly the same for exactly that reason. It's so much smoother! As for Carnegie, that feels like a whole kettle of fish...
I love this project, I massivly enjoyed working on the Zig version with ityonemo. I worked on the faithfull version, I hope to score high with that :-). I enjoy seeing other languages and people being passionate about them 😊
Please do! I was very impressed by the Zig work in the project, and I think people will stand to learn a lot from your contributions. And as you know, Zig has been very competitive for performance!
@@DavesGarage They way you described faithfull here is not completely in line with the zig implementation yet. It does know it's size at compiletime and is therefore able to optimize it quite extensively. (just putting the entire sieve on the stack lol). If I have time next week I'll see if I can make it completly faithfull. It's been interesting to see how much the target architecture prefers one solution over the other. eg: My desktop ryzen 3700x is fastest on the version that uses one byte per bit because it has such an absurd amount of cache and is able to keep the entire sieve in there. It actually loses a lot of performance in the faithfull bitpacked version because of the extra bit packing/unpacking it has to do. Meanwhile that version is by far the fastest implementation on my raspberry pi that has very little cache causing massive amounts of cache misses in anything but the bit packed version.
That depends very much on how you code :-) I've been coding in Perl for 20 years now and find I have no more problems reading my old code than in any other language. But I agree that Perl *can* be quite messy because almost everything can be done in several different ways - you need more discipline to keep it clean than in other, more restrictive languages. If you look ath the implementation here it pretty much looks exactly like the PHP implementation, apart from the postfix notation of if/unless and the explicit fetching of function arguments.
It also has to be noted that when modern CPUs there are some really weird branch optimisations that include things like knowing how long the branches are to decide which is the best optimisation... and that's HARD for a human coder to do.... So *technically*, yes, a really, really good asm coder could match the best compiler... but that's only technically correct, admittedly, the best kind of correct.
That's because it is one of the only keyboard combo'es you can't interfere with. If you could reassign it, you would be able to spin up a fake login screen and intercept the credentials... which i vaguely remember somebody doing for the local Novell Netware login, in my early educational days. Ediit: Also ctrl-alt-del has, as far as i know, always been the keyboard combo for soft-reset on PC, so it was uninterceptible and guaranteed to be available.
for languages like postscript and sql, a grouping of outliers could demonstrate interesting methods of getting them to work as a sieve (i for one am curious about sql) and show off how clever the solutions are
@@nebulium6641 "Dallas" was the "Game of Thrones" of its day - even if you didn't like it or had absolutely zero interest in it, you couldn't follow what anyone was saying if you didn't have a few of the key references front and centre (yes, "centre", for all you u-dropping, re-reversing rebels out there) in your brain.
For this test, where it's single threaded and basically entirely CPU, it really shouldn't. It can definitely be an issue with threaded code even on the same architecture though, which can be surprising!
@@SimonBuchanNz On a rich induction set, some of these code sections may be accelerated. In particular, the bit banging parts, there may even be a bit fill with offset instructions available.
Great video as always Dave! BTW the wackiest part of PHP IMHO is the comparison rules, where null, 0, false, and "0" are almost the same thing. Ohh, and the $$var thing...
The $ thing might seem whacky, but i find it a hell of an improvement in readability. You know in the blink of an eye wether or not you're dealing with a variable.
GPUs running any single thread is slower than most CPUs, the way GPUs accelerate things, is by having hundreds or even thousands of cores to run in parallel. A 3080 breaches the 10,000 mark.
@@EwanMarshall -cores- glorified floating point units i have a hard time really seeing them as cores, that kind of implies a fully functional cpu core for me, shader cores aren't that, it's merely a small subset of what would make a cpu a cpu. back when 386 did not have FPUs yet but you could add one in the board, noone really considered that FPU as adding a core, right? you merely added hardware accelerated extensions. sure a gpu is a very specialized ASIC with hardware accelerated functions for vector and matrix math, but not every floating point units deserves the name of a processor or a core, i regard them more like a single cpu with a shit ton of FPUs running in parallel inside that core. (in fact, one core per pixel in case of a fragment shader, but the same program will be running on each core, until you compile something else for the processor, there is no real thread control there). but yeah, it can do a lot of FP operations in parallel alright i know they call them shader/cuda cores themselves, but meh, marketing fluff to me :D
@@dutchdykefinger Cuda cores are a bit more than just FP co-processors... There is a a full ALU in them for 32bit integer operations for a start, though everything is SIMD that is split across the cores, I'm not sure on branching and looping constructs. The actual instruction set architecture of CUDA is pretty opaque, that said even hlsl shaders can handle some kinds of looping and branching. I have a feeling that every 32 cores that make up a SIMD instruction would be turing complete in itself. Problem 1 though, you dispatch to add 2 numbers together, well you are also chewing up 31 cores adding 0s together for that clock cycle.
It is crazy that PHP got better results than Pascal (from the previous episode) since the former is interpreted and the latter is compiled into machine code. Isn’t that weird? Are Pascal compilers really that bad?
It isn't so much that Pascal is bad so much as PHP has been heavily optimized for performance - that has been their main focus for the last decade and each new major version from 3 to 4 to 5 to 7 has come with a gigantic performance boost. Most Pascal compilers probably were excellent once, but they've been largely left stagnant and optimizations that could be done to better reflect the capabilities of modern systems and hardware simply aren't done. Perl 5 has the same problem, it's been stagnant for so long it's fallen behind in performance too (Perl was historically much faster than PHP).
@@robertmarder126 Doesn't PHP also have included a JIT compiler for a long time? At least that's been my understanding... I don't know enough about JIT compilers and Perl's internals to even begin to contemplate whether it would be easy or hard and unpractical (relative to other interpreted/JIT compiled languages in general) to implement - Perl has a lot of weird magic, and that might make such work harder, less practical and decrease the benefits from JIT compilation, but I'm not the right person to make any guesstimations about that... *But* the last time, before Perl 6 was a thing (and Perl 6 is alien to me - it's not the Perl I know and love), the last time I tried to find any information of any plans to implement JIT compilation in Perl 5, the discussions from some Perl development mailing list bummed me out big time. Basically it seemed that while there were people who would have wanted it, the ones making the decisions seemed to be rather reluctant about it and offered a non-explanation of how they didn't feel that this was that relevant or important for Perl. I mean, what? Yeah, perl programmers like myself know it's not high performance language, but it's being used to create all kinds of applications. For example, many screensavers of XScreenSaver (and it's less good forks, like gnome-screensaver) are written in Perl - including some of the OpenGL screensavers. People have written realtime games, like side- and top-scrolling platformers in Perl. Of course the OpenGL, SDL and other libraries used by them are written in C/C++, but considering that it's being used for pretty much all kinds of applications, shouldn't improving it's performance have been considered "relevant to Perl"? I mean, reading that was a total bummer for a Perl-loving whacko like myself. I'd like to fork one of the existing idtech1 engine (DooM - or in fact DooM, Heretic, Hexen & Strife, they are all supported by some ports) and make Perl as new scripting language for it - but I think it wouldn't be a good choice because of performance. I'd like to extend the scriptability of DooM to something like Quake's QuakeC, making it possible to create complex bots and totally new game mechanics. But it would have to be in some other language than Perl :/
I would like to see the concatenative/stack-oriented programming languages (PostScript, Forth, Joy, Factor) featured together. Looking at the Github, there aren't implementations yet for Joy or Factor, which are two languages that I've been curious about. Perhaps I can learn enough about one or both to contribute a faithful implementation. Either way, Forth and PostScript would be an interesting pairing, even though they look very different and are typically used in very different contexts. One thing they share in common is that they were originally designed to run on memory-constrained systems.
This is a great series and I love seeing the algorithm in different languages. I recommend that the oddball languages be clumped into "miscellaneous" episodes as necessary. Instead of comparing similarities, you can give a quick assessment of what each language is used for. The results won't be very relevant to one another, but it will still be interesting to see what speeds are typical for that language's particular job. We should still try to associate languages with "similar" jobs or which run in similar environments, of course, but that may not always be possible and I would want to include 3 languages per episode when practical. Group up the obvious contenders and then start trying to clump the rest into "close-enough" associations. I also suggest that groupings larger than 2-3 can be allowed by carrying results over from one episode into the next. A follow-up episode can refer back to the prior languages and simply continue on from where the prior one left off. This would create larger groups of 4-6 than span 2 episodes, but no more than that.
Thank you again, so much! Great video. I'm a release engineer and can do some Bash, and Perl, and the like, but I'm not a pro coder. Even though, this series is fascinating to watch.
7:00 Fun bit o' trivia: While everyone was wondering who shot J.R., scientists discovered that two of Saturn's' rings are woven together through forces unknown. I learned that from Harlan Ellison, some time ago.
btw. the most expensive operation in the Perl implementation is actually initializing the 'bits' array. It takes about 30% of the overall runtime! So using a more suitable bitarray class (of which there seem to be plenty on CPAN) should speed things up significantly.
Really hope someone has implemented it in Haskell, I'm trying to learn the language but it's fairly different and it hasn't been my top priority. Maybe this is the perfect scale or project to get me started!
Just an idea for the future: Language "performance" in terms of productivity, readability, safety, and expressiveness. I think it would be be interesting to explore the maintainability of a project in some languages, its readability for newcomers to a project, their ability to help mitigate or even eliminate some classes of bugs, and the ability of just how quickly or easy it is to go from idea to code, even if it's just a proof of concept.
This ideia is good. But even with diferent compileres you will get diferent run time. For example Fortran code gives diferent run time with the choosen optimization in Intel Compile, Portland Compiler, GFortran, AMDcompiler, G95...etc
I can't even imagine what a JCL Prime Sieve would look like. I've only ever used it to move/sort datasets and call Programs. If it's possible I'd love to see it!
Not to be too controversial here - I seriously doubt that it can be done in JCL (whether MVS or VSE version). They were really just a way to control the flow of programs as in "run the SORT program with these two files as input, using these parameters to control the sort (ascending, descending, type of data, etc) and putting the output in that file". If anyone actually works out a way to do it, I will be seriously impressed, nay, flabbergasted.
Perl's "unless" keyword is an interesting option, and in the right place (maybe 10% of conditionals in my experience) is actually very helpful for clarity. The problem is that (like most of the language) it suffers from over-application by enthusiastic programmers who just discovered it (nested cases, "unless" combined with not operators, etc...), and insufficient sober analysis about whether it actually improves code clarity in each case. Perl as a language gives you a huge footgun to write things incomprehensibly, but also allows for very clear and expressive solutions with some forethought. I mostly work in Python these days, but one thing I really miss from Perl is its variable scoping rules. It's easy and straightforward to scope variables to the specific pieces of code you want, ensuring they're available exactly where needed without trampling on anything else. The other big thing I miss is Perl's use of regular expressions as a first-class citizen, baked right into the language. There's a way to use regular expressions in just about any language, but they're a powerful (and like perl itself, often abused) tool that takes a lot more boilerplate to leverage in just about anything other than Perl.
Indeed, Perl's RegEx support is out of this world - not only is it baked into Perl's syntax, it also goes way beyond regular "Extended Regular Expressions" (as GNU Grep likes to call what's usually meant by regexps). Even without rest of the Perl it's so powerful that GNU Grep has separate command line switches -E (for "Extended Regular Expressions") and -P (for "Perl Regular Expressions"), LOL - but the things you can do with it inside perl code... Yet way too often I see regular expressions used in Perl code when they aren't needed, like where plain globs would be enough (and easier to write, faster to perform, etc.). One other language I was originally gladly surprised to see getting regex support, also baked into it's syntax, was bash - but being baked into syntax doesn't mean it's necessarily that awesome... However the alternative is to call another tool that has regexp support, and depending what you need from it you'll have to use different commands - of course when I first tried it (and almost every time since), I was hit with the most common flaw of bash: unclear documentation. What I mean by that? Well, technically the documentation isn't ridden with errors, it's just that it's not telling you everything you need - like the part where when you have a conditional using = or !=, the right part can be used for glob pattern matching - what it leaves out is that if you have the glob pattern in variable and put the variable in quotes, it doesn't work. Actually it's not about using variable, I found this out when I was trying to do "if [[ ("$1" = "-*") && ("$1") != "--")]]; then..." and couldn't get it to work. You can say that glob matching does not work with quoted strings, but the man page didn't. It might mention it in another place, and obviously when you write "*" on command line it's not expanded to list of files, but pattern matching inside conditional expression isn't same as pattern expansion. Same kind of issues, but less obvious than that, is what I ran into with bash regexps - and while I've gotten it to work couple times, I usually don't even try, unless I have a good reason. And bash has a lot of unexplained quirks like that. The biggest issue I have, and I admit I haven't checked the info documentation of bash that does have some things explained better or with examples that work, but the man page doesn't really tell you what regexp functionalities you can use, and I don't really like having to guess whether I need to escape something in some special way, etc. - it's a lot of trial and error, and bash has a number of things you just have to experience and find a way to make it work. I've been in a situation where I first implemented something on command line - a complex one-liner using fortune piped to cowsay with randomly selected .cow file to use - and when I got it to work I tried to use it inside a function. I never figured out that one, but it just didn't work. I wanted it in my .bashrc, but I wanted it as shell function I could also call manually anytime I wanted to, but somehow the same line inside a function spewed out some error I've since forgotten. But most of the time I still love bash - but I'm really reluctant to try and use it's regexp functionality. I've never liked awk or sed, and if I were to call perl I feel I could just as well do the whole thing as perl script instead. I don't know why I felt like making this rant - at first I just wanted to say that bash also has regexp support as part of it's syntax, but that it's not that good (or perhaps it would be if not for the lack of good decumentation), but it grew into large rant about bash documentation in general and in relation to regexp support. Funny thing - I once found a fork of OG bourne shell and now always install it on every linux installation I do for myself; because I like to. But while it's much more limited and simpler to document, it's documentation is stellar in clarity when compared to bash. In fact it's so good, that even when making bash scripts if I need to refer the manual and if it's about something that works with bourne shell, I'll rather check it from bourne shell man page ;)
"At least I didn't do the videos in my original [Canadian] accent." That's too bad! It would have been epic. I bet you really know what you're talking aboot.
I suggest a headless category, maybe something like 'GUI' or 'graphical' or simply 'not headless'. Some languages for all practical purposes either can't or don't ordinarily operate in a text based mode . For instance, LiveCode. It's possible to write the Sieve program in a LiveCode "headless" mode, but I doubt that more than 1 or 2 LiveCode programmers out of a 1,000 ever experience writing a headless program in LiveCode. In the majority of commonly used languages, programmers have lots of experience writing programs in a text editor and running them in a 'console' or 'terminal', i.e. in headless mode. However, you can't do that in Scratch - which is higher on the TIOBE list than Rust, Ada, Julia, COBOL, Kotlin, Haskel, Lua, et. al. Going headless in the robotic programming language NXT-G is possible in a variety of headless languages, but I doubt that more than 1% of the Lego Mindstorms programs are headless. Likewise for LabVIEW. Your comparison of dozens of programming languages is woefully biased towards headless language programming. How would you compare the sheer number of computer programs in use today by people throughout the world, which are headless vs. GUI? My guess is that the vast majority of people don't care to be presented with a console/terminal screen when they want to use a computer program. For that reason, I also doubt that most programmers are writing headless programs.
Dave, great episode again - I wrote a comment specifically for you in the end considering your statement of the Perl program being a shell script; I'd love to hear whether you agree and if not, why. No offense meant, never to you - love your content
Scala and Swift are quite similar, so you could group them. However, Scala is a JVM language and Swift is LLVM. So that's quite different. I'm surprised nobody added a Kotlin version.
God I hate "to be continued" ...but this takes me all the way back to the big John and sparkie radio days, buck Rogers, and sky king...but please...don't wait till next Saturday to post the next one. Thanks...this is an example of how the world might be saved ...
Great stuff! Dave, your videos have always been AWESOME and they keep getting even funnier and better. You are the man! Absolutely loving the computer language wars series :-)
I'm not really quite following here. We are comparing specific compilers / interpreters, no? Languages are just grammar, having nothing to do with speed or performance.
Thoughts on how the "official" scores will be calculated? Currently, all results are calculated within a docker container. Which while wonderful for compatibility, surely higher can be achieved by native running code.
Thanks! It does seem like the language is always evolving quite aggressively, which can be hard to keep up with but is good! How far away is PHP8 from full release I wonder?
You can run with jit enabled changing php.ini or with some args: /usr/bin/php8.0 -dopcache.enable_cli=1 -dopcache.jit_buffer_size=100M -dopcache.jit=1255 -q PrimePHP.php
Me: I wonder if anyone's used the fact that all primes are of the form 6n±1 or any of the other equations you can get by using similar logic. Dave: To be faithful, the only prime you're allowed to use is 2. Me: Ah, so probably not. Makes sense, because without that restriction you could just hard bake the list in to the program and this would all be pointless.
I can easliy prove all primes have a multiple of 6N on one side or the other, but the converse isn't true, so it's not that helpful in finding primes. Rest assured when eliminating multiples of 3, my algorithm starts at 9 and walks by 6, which should eliminate all the 3N prime candidates as it goes. The evens are not present anyway so I think right after that pass you've got that info, but it's not enough to predict where primes WILL occur, just where they COULD occur.
It would be interesting to hear David's opinion on the usefulness of spending time on optimizing code and when not to. I am a tinkerer, the bad kind of perfectionism, so it is not for me. It took ages for others to make me stop wasting time and I see it around me in others, often the best and brightest.
Dave this is great. I think your pithy rebuttal to the "assembler is fastest" argument was first-rate. I'm with you --- if someone is able to code the prime sieve (including I/O) directly in machine code, they deserve special recognition --- perhaps an all-expenses paid houseboat tour of Lake Wascana ??
PHP 7 is NOT the latest version, PHP 8 is. And it has JIT, which should translate to quite a big performance gain in comparison to 7. By the way, while the -r command line switch works, it might be easier to use -f and feed it a file with your code. Also, you can use PHP as a shell script too by adding #!/usr/bin/php on top and making it executable, just like perl.
It would be fun to see (and listen to an explanation of) array oriented languages like APL, K and J. Given that there are sometimes claims that K programs can be faster than hand optimized C, seeing how well it does here would be really interesting.
I recently ran into an issue where I could not efficiently express a simple function in 'C'. I needed to swap the top 16 bits with the lower 16 bits in a 32 bit variable. (audio codec/dma artifact) In arm assembly its simply 'ror r0,r0,#16', 1 cycle, a rotate that puts (bit31->bit0). In normal 'C' you only can use shifts, or load/store halfwords. Arm assembly also has bit manipulation functions, that would speed up you algo, but are probably not exploited by the compiler.
@@DavesGarage Ok, I tested it using gcc thumb2 instruction set, and you are right. I guess I am a bit biased by my day job that involves using custom instructions/mcu. Although ((unsigned)(x) >> (y) | (unsigned)(x)
20:13 - oooh, is PCL Turing Complete? If so, it’s the obvious pairing for PostScript. 😁 If not, maybe PostScript and Logo?!? I mean, pretty different, but…
How about something as obscure as Standard ML? The computer languages course I took at college involved that language. It’s not very useful for writing applications, but was originally intended for mathematical proofs. This would be an interesting language to try.
Thanks, Dave for this series. It is very interesting! :) But there is one thing I would like to point out as loud as possible, but... well, this is as loud as it will ever get! :D LANGUAGE SPEED DOES MATTER MORE THAN ONE THINKS! Dave stated that: "[..] language is good as long as You get from it what You want without waiting on it to do its job [..]". It is subjectively a valid, yet globally broken logic that will (and actually invisibly is already) kicking our rear ends. Reality is displayed with PHP as an sad example. Most web pages in the world is running PHP back end that is written by many people that took their time to learn this specific language. Many poor in their time, energy and effort to make it better. Good job, but ... it is like reinventing the bike all over again. I am definitely NOT stating that PHP is bad. What I am saying that people all around the world is investing into worse performance-wise language than they should. It matters when You take this exact comparison into account - speed - and combine it with scale! If task given is equal & HW is fixed, why language matters? Energy consumption. Electricity. We are talking hundreds of megawats per hour of electricity consumption difference in single country! If PHP is 4 to 8 times slower than (for example) C, C++ or any other language that can do the same job, it is economically unjustified to use slower language for big projects that are run countless times all over the world even if programmer salaries are taken into account. And big projects are the ones driving language development itself! So, reason that "one language is easier to use than other in given task" also becomes meaningless at the point where You still have to learn & develop a language itself. It, unfortunately, looks like that most popular languages are the ones that lets You be sloppy the most. Not most efficient or fastest to write, but the ones that requires less attention, less care and makes someone or something else to cover up programmers laziness in some other means, like... lets just buy bigger server and burn twice as much energy to run this homepage... I am not advocating for C or Assembly as "be all & end all" for everything! I am just saying that there has to be a point where programmers have to be able to put down their opinions about how good or bad language is, and realize, how big of an impact given system will have on global scale. Big impact & big scale? Reconsider the choice of language not for ease but for function.
Interesting metrics to look at for the final runtrhoguh Code size relative to performance. Perceived complexity relative to performance And a huge performance comparison matrix comparing languages compiled for and run on Windows, Linux and macOS with different compilers where available, to let C not just be represented by GCC but also Clang, MSVC and other optimising compilers potentially
I pronounce SQL as “squall” because that's just how it looked to me when I first saw it. I can even see “squil” or “skwool”. I also saw the word _array_ for the first time when I was really young in the Color BASIC book for the TRS-80 and pronounced it “AIR-ay”. Took me 20 years or so to not have to double-check what I was about to say before saying it out loud after hearing how it was really pronounced. Never did understand where someone originally got “sequel” though
What version of PHP are you running this test in Dave? 8 would be more fair considering it’s the most up to date version, has JIT and the code could be simple with the new match syntax.
Some remarks/corrections: 15:46: On Unix-like systems, the shebang is NOT interpreted by the shell but by the execve (3) system call. 17:33: $self is NOT a language feature of perl but an ordinary variable. Choosing $self as variable name is a well known convention however. In line 30 of the code, the declaration and assignment of the variable can be seen. Apart from that, awesome project!! Cheers -Fritz
Dave, please ignore the useless, critical for the sake of being critical comments. I understand responding to reasonable criticism or comments but as the kids say, haters are gonna hate. Love your channel!
First off, I always tell people that the best language is the language THEY ENJOY programming with. C is my personal favourite (not C++, but the latest GNU C). I have recently played with Python as it is used with various game engines (Ren'Py and Godot) and I have really been impressed with them, and I have never been one for such languages. But I love C mainly. I would like to see the latest C (not Visual Studio's C++ that compiles C, but the latest version of C which is supported by a GNU C compiler like MinGW for Windows).
Honestly not surprised about the perl result. It's absolutely my go to language if I want to do something quickly under linux that I'll either use once, or isn't too intensive. It can do a lot of things way easier than other languages I think. SQL access (including prepared statements), excellent regex capability, good file read/write options and overall filesystem control, rest/json client easily implemented. If you just want to bring things together quickly it's excellent for that. But, it's not fast. If I know I need speed I'll generally go for C# (via mono for linux). There's also the danger something you thought would be simple is started in perl and then becomes some monstrosity you wish you'd moved to something else long ago.
One suggestion is to group dynamic scripting languages together and do a video on that. For example, Python, Lua, Ruby, Javascript. Now most probably already know Python and JS so you can skip most of the explanations for them. Other thing to note is whether you're running the script in a jit vs non-jit implementation. For example, if you're benchmarking javascript with node.js then it'll make sense to also bench python and lua with something like pypy and luajit respectively just to keep things fair.
The amazing color changing shirt.
Someone noticed in the livestream premiere first, but you're the first to comment on it. Good catch! I bet a lot of folks didn't even notice!
Was going to comment on that but apparently it's pinned.
@@Fidelity_Investments Same 😂
Thanks for commenting on that, I though I was going to have to go to the Doctor and get my eyes/brain checked. So relieved.
Hypercolor or post processing?
I won’t be impressed until the Perl code is on a single line with no comments.
*unless
And without alphanumeric characters
@lohphat as it was always intended
You always hit me right in the feels with the Friendly Giant outro.
Love this series, and find the comparisons of all the languages fascinating.
Thanks! I persist with the Friendly Giant even though about 95% of the global audience, esp. the USA, has no idea what it's about! But i figure it's worth it for that tiny slice of GenX Canadians....
@@DavesGarage I am old enough to remember "The Friendly Giant" on TV in the USA. Thank you.
Look up. Waaaaaaay up
Please show the "current" leaderboard of all previously raced languages.
I know that the videos are not really ordered but they DO have episode numbers after all :)
Fair enough! I'm going to bust out a whiteboard and camera and do it Top Gear style, since this is racing and all. I just need a mini stig... wish I had an Intel bunny doll!
@@DavesGarage Awesome, Thanks a lot!
@@DavesGarage Stack XD
Maybe group data analysis/science languages together, like Python, R, Julia, and Matlab
Python is general purpose, it just happens to be good for data analysis/science
It might be fun to put Cython in this group instead of Python since Cython is the backbone of several major Python data analysis packages (pandas, scipy, scikit-learn).
Good idea. Even though I've already done Python, I could include it but allow a numeric library, at least as an exhibition run to demonstrate what's possible!
@@DavesGarage That would be cool. Thanks for the content!
Add in SAS, Octave, SPSS, and FORTRAN and you're on the right path.
I think that C and Zig should be in the same episode since Zig is often called 'better C' by its community and creators
Everybody knows French is the fastest language with Italian a close second. Ever hear a Frenchman speak slowly? Exactly!
fair enough
I have heard that Chinese and German are also very fast. But I am not an expert in them 🙈
Well I speak french and a little bit Italian and also a little bit Spanish, and I think Spanish is way faster than anything else I have heard
Brazilian Portuguese is a hard one too
French MUST be fast in speaking! You know how they say '90'? We Italians at least do not mix grammar and math! :-O
Love these videos. It's really cool to see someone with this much experience talking about programming
This is fascinating. I only have a few years of basic programming classes from 20 years ago notched on my belt, but it's enough to pick up the interesting differences by immersion here. I suspect by the time this series finishes, I may just have some inspiration to go try a few of these languages out and get back on that train.
As a fellow Saskatchewan kid that started on a Magnavox Odyssey II and wrote my first stuff on a Coleco ADAM (with my mom), it's always sea-quall to me, haha. This is a fun series!
Ah, the good old days of three TV channels! I grew up in Alberta but spent a lot of time visiting relatives in Prince Albert and Saskatoon.
9:33 "...raison d'être..." pronounced well. Canadian cred checks out.
Python: print("Hello World")
Java: hey, would you mind to make some classes first? :)
just because it requires a class doesn't mean it's bad, it needs to know where to start, you can also write a python program without functions and most languages won't compile that, so what?
But who prints faster? I bet on java.
@@ChristopherGray00 don’t take it too seriously ;)
@@Anllazsn who cares? They are really slow.
Python: "Calls 500 lines of C code as a wrapper" WoWL0oKHoWE45yPy7h0nIz
Seems like you're having more and more fun editing your videos with all those tricks and effects ;)
I try... it keeps things entertaining for me as well. But wow, there's a lot of time into edits!
Interesting video, but a few observations:
1) Machine language and assembler are the same thing. Assembler assigns a mnemonic to each machine instruction. It is a one-to-one relationship. It is simply a way to code in "letters" rather than "numbers" and was invented for that exact reason. All other languages use a one-to-many relationship. A C statement like "++a;" could translate into an "LOAD, INC, STORE" operation (far from the only possible implementation).
2) In a compiled language, the specific compiler, version, and optimization capabilities (and settings) can have a huge effect on performance. Further, the specific instruction set of the target machine can also have a huge effect. In the old days when compilers were only available from the hardware suppliers, it was very common for the compiler to take advantage of specific instruction unique to the hardware. A very old example was that on the IBM 360, there were native BCD instructions! I can remember when PC chips did not come with floating point operations (Intel 286 and 386). There are currently machines (and video cards) that can be programmed to use vector operations over arrays. The "look ahead" and caching capabilities of various processors differ dramatically.
In an interpreted language, many comparisons are invalid because it is not the language that is being compared, but the implementation of the internal run-time library. A Perl implementation on one machine is not required to run identically to another machine, only to produce the same results. I remember using APL and the performance results of various operations were very different on different machines due to the differences in implementation.
The short version of this is that tests can yield different results using different hardware/software/settings. Any comparison is limited to a very precise and unvarying specification!
3) IBM 360 JCL has no mechanism for looping, computation, or any other programming task. It only has the ability to test the "return" value of the previous operation (EXEC). It is possible that these capabilities were added in later machines and/or OS's, but I have no experience with them.
Keep up the good work!
Thanks Dave. I made my living working with technology geeks, trying to understand and convert their knowledge into something mere mortals could understand. I had my share of fakers, trying to snow me with complex combinations of new words and concepts, poorly explained. I remember one session where I was told, "Our technology assumes some intelligence on the part of the user".
On the other hand I thoroughly enjoyed working with true experts, those who where comfortable in their knowledge and were eager to share it with others. They explained using metaphors and simple stories, boiling their vast knowledge down to the essence that would reveal the beauty of their craft. They were always eager to share and they loved making new discoveries of their own. Your videos remind me of these session. Challenging but fun, I always up for the ride to the technology discovery store, knowing we're going to get something good.
Growing up the 1970s watching drag racing in Fremont and working on cars at Bill's Arco, I appreciate your combined love of cars and computers. What a great time to grow up. Thanks for sharing!
There's a saying: If you can't explain something simply, you probably don't understand it.
Thanks kindly! Glad you're finding them enjoyable!
That was Einstein's quote, I believe: "If you can't explain it simply, you don't understand it well enough."
As a Canuck of a similar generation to yourself, Dave, the ending was perfect.
"I apologize in advance" Canadian confirmed xD
“Sport-ah-zh”, “sequel” and “N-aye-k” are wonderful and never ever change them
I'm not TOTALLY sure but I'd wager Kia Sportage comes from the French "portage", which is to carry a canoe overland. I always found it odd that we had and kept our own pronunciations for things, but it happens elsewhere too.
One thing I always found odd is Andrew Carnegie's name. It's pronounced CAR-NAY-GEE but they say "KARN-AGEE HALL" for the building!
Wait... How are you supposed to pronounce Nike then?
@@DavesGarage to be honest, I always pronounced it exactly the same for exactly that reason. It's so much smoother! As for Carnegie, that feels like a whole kettle of fish...
@@Sibula nigh key
@@asdasdv7540 huh, that sounds really weird...
I love this project, I massivly enjoyed working on the Zig version with ityonemo. I worked on the faithfull version, I hope to score high with that :-). I enjoy seeing other languages and people being passionate about them 😊
Please do! I was very impressed by the Zig work in the project, and I think people will stand to learn a lot from your contributions. And as you know, Zig has been very competitive for performance!
@@DavesGarage They way you described faithfull here is not completely in line with the zig implementation yet. It does know it's size at compiletime and is therefore able to optimize it quite extensively. (just putting the entire sieve on the stack lol). If I have time next week I'll see if I can make it completly faithfull. It's been interesting to see how much the target architecture prefers one solution over the other. eg: My desktop ryzen 3700x is fastest on the version that uses one byte per bit because it has such an absurd amount of cache and is able to keep the entire sieve in there. It actually loses a lot of performance in the faithfull bitpacked version because of the extra bit packing/unpacking it has to do. Meanwhile that version is by far the fastest implementation on my raspberry pi that has very little cache causing massive amounts of cache misses in anything but the bit packed version.
Having spent quite a few hours trying a failing to beat you in Fortran I have to say I believe in you :-)
I also really like your Zig solution. It's a pretty cool language!
perl is, in my opinion, a write-only-language. I have written perl that six months later I had no idea how it worked.
Myth
That depends very much on how you code :-)
I've been coding in Perl for 20 years now and find I have no more problems reading my old code than in any other language.
But I agree that Perl *can* be quite messy because almost everything can be done in several different ways - you need more discipline to keep it clean than in other, more restrictive languages.
If you look ath the implementation here it pretty much looks exactly like the PHP implementation, apart from the postfix notation of if/unless and the explicit fetching of function arguments.
Perl is the only language that looks the same before and after being encrypted.
Once my C++ changes are merged, you bet it's going to be on the top!
Challenge! I plan to tinker soon with C++ and x64 ASM versions!
@@DavesGarage great! If you find improvements in my suggestions I'll just take my hat off. Have a great day Dave :D
It also has to be noted that when modern CPUs there are some really weird branch optimisations that include things like knowing how long the branches are to decide which is the best optimisation... and that's HARD for a human coder to do.... So *technically*, yes, a really, really good asm coder could match the best compiler... but that's only technically correct, admittedly, the best kind of correct.
Dave I have always been curious about this... can you do a video on why ctrl-alt-del was used for logging in?
That's because it is one of the only keyboard combo'es you can't interfere with. If you could reassign it, you would be able to spin up a fake login screen and intercept the credentials... which i vaguely remember somebody doing for the local Novell Netware login, in my early educational days.
Ediit: Also ctrl-alt-del has, as far as i know, always been the keyboard combo for soft-reset on PC, so it was uninterceptible and guaranteed to be available.
Thanks for showing the PHP I wrote, awesome challenge !
Thanks again for contributing it!
Group languages by decade when first released.
I think I missed the episode where they reveal who shot JR. Certainly, I won't miss the winner of this drag race! :D
for languages like postscript and sql, a grouping of outliers could demonstrate interesting methods of getting them to work as a sieve (i for one am curious about sql) and show off how clever the solutions are
I'm curious about whether SQL would be testing the language or the DB engine on which you run it.
"Who shot JR" now there's a reference that probably lost most of the audience under 40, well played
I always wonder about that stuff! I mean GenX and older will get it, but it probably does right past everyone else!
@@DavesGarage Gen z here, No clue what it means haha
@@DavesGarage Well it made me laugh and I'm in depression over the footy result last night !
@@DavesGarage We'll always have Paris.
@@nebulium6641 "Dallas" was the "Game of Thrones" of its day - even if you didn't like it or had absolutely zero interest in it, you couldn't follow what anyone was saying if you didn't have a few of the key references front and centre (yes, "centre", for all you u-dropping, re-reversing rebels out there) in your brain.
This may be over kill, but the target/host may actually influence the results
For this test, where it's single threaded and basically entirely CPU, it really shouldn't. It can definitely be an issue with threaded code even on the same architecture though, which can be surprising!
@@SimonBuchanNz On a rich induction set, some of these code sections may be accelerated. In particular, the bit banging parts, there may even be a bit fill with offset instructions available.
@@piratk yeah, should have been clearer that I just meant the OS, absolutely you could get different results on different architectures.
And the quality of one compiler/interpreter implementation vs. another within each language.
That thumbnail brightned my day ❤️
Thanks! And while it looks fairly clickbaity, its an actual scene from this episode!
Great video as always Dave! BTW the wackiest part of PHP IMHO is the comparison rules, where null, 0, false, and "0" are almost the same thing. Ohh, and the $$var thing...
The $ thing might seem whacky, but i find it a hell of an improvement in readability. You know in the blink of an eye wether or not you're dealing with a variable.
It would be interesting to see a GPGPU implementation, but it definitely wouldn't be an apples-to-apples comparison.
gpus rely on parallel processing, which violates the "single-thread/core" rule. might be a fun exhibition though
GPUs running any single thread is slower than most CPUs, the way GPUs accelerate things, is by having hundreds or even thousands of cores to run in parallel. A 3080 breaches the 10,000 mark.
@@EwanMarshall -cores- glorified floating point units
i have a hard time really seeing them as cores, that kind of implies a fully functional cpu core for me, shader cores aren't that,
it's merely a small subset of what would make a cpu a cpu.
back when 386 did not have FPUs yet but you could add one in the board, noone really considered that FPU as adding a core, right?
you merely added hardware accelerated extensions.
sure a gpu is a very specialized ASIC with hardware accelerated functions for vector and matrix math, but not every floating point units deserves the name of a processor or a core, i regard them more like a single cpu with a shit ton of FPUs running in parallel inside that core. (in fact, one core per pixel in case of a fragment shader, but the same program will be running on each core, until you compile something else for the processor, there is no real thread control there).
but yeah, it can do a lot of FP operations in parallel alright
i know they call them shader/cuda cores themselves, but meh, marketing fluff to me :D
@@dutchdykefinger Cuda cores are a bit more than just FP co-processors...
There is a a full ALU in them for 32bit integer operations for a start, though everything is SIMD that is split across the cores, I'm not sure on branching and looping constructs. The actual instruction set architecture of CUDA is pretty opaque, that said even hlsl shaders can handle some kinds of looping and branching. I have a feeling that every 32 cores that make up a SIMD instruction would be turing complete in itself. Problem 1 though, you dispatch to add 2 numbers together, well you are also chewing up 31 cores adding 0s together for that clock cycle.
It is crazy that PHP got better results than Pascal (from the previous episode) since the former is interpreted and the latter is compiled into machine code. Isn’t that weird? Are Pascal compilers really that bad?
It isn't so much that Pascal is bad so much as PHP has been heavily optimized for performance - that has been their main focus for the last decade and each new major version from 3 to 4 to 5 to 7 has come with a gigantic performance boost.
Most Pascal compilers probably were excellent once, but they've been largely left stagnant and optimizations that could be done to better reflect the capabilities of modern systems and hardware simply aren't done. Perl 5 has the same problem, it's been stagnant for so long it's fallen behind in performance too (Perl was historically much faster than PHP).
@@robertmarder126 Doesn't PHP also have included a JIT compiler for a long time? At least that's been my understanding... I don't know enough about JIT compilers and Perl's internals to even begin to contemplate whether it would be easy or hard and unpractical (relative to other interpreted/JIT compiled languages in general) to implement - Perl has a lot of weird magic, and that might make such work harder, less practical and decrease the benefits from JIT compilation, but I'm not the right person to make any guesstimations about that...
*But* the last time, before Perl 6 was a thing (and Perl 6 is alien to me - it's not the Perl I know and love), the last time I tried to find any information of any plans to implement JIT compilation in Perl 5, the discussions from some Perl development mailing list bummed me out big time. Basically it seemed that while there were people who would have wanted it, the ones making the decisions seemed to be rather reluctant about it and offered a non-explanation of how they didn't feel that this was that relevant or important for Perl.
I mean, what? Yeah, perl programmers like myself know it's not high performance language, but it's being used to create all kinds of applications. For example, many screensavers of XScreenSaver (and it's less good forks, like gnome-screensaver) are written in Perl - including some of the OpenGL screensavers. People have written realtime games, like side- and top-scrolling platformers in Perl. Of course the OpenGL, SDL and other libraries used by them are written in C/C++, but considering that it's being used for pretty much all kinds of applications, shouldn't improving it's performance have been considered "relevant to Perl"?
I mean, reading that was a total bummer for a Perl-loving whacko like myself. I'd like to fork one of the existing idtech1 engine (DooM - or in fact DooM, Heretic, Hexen & Strife, they are all supported by some ports) and make Perl as new scripting language for it - but I think it wouldn't be a good choice because of performance. I'd like to extend the scriptability of DooM to something like Quake's QuakeC, making it possible to create complex bots and totally new game mechanics. But it would have to be in some other language than Perl :/
I think the "no country for old programmers" is the more obscure reference for the people who are following this competition.
Great video as always, Dave! Thanks, a fellow Canadian!
Thanks for doing this series. I'm leaning and it's entertaining. Thank you.
I first saw an `unless` statement when learning Elisp - still can't wrap my head around it. Perl looks absolutely nuts lol.
I would like to see the concatenative/stack-oriented programming languages (PostScript, Forth, Joy, Factor) featured together. Looking at the Github, there aren't implementations yet for Joy or Factor, which are two languages that I've been curious about. Perhaps I can learn enough about one or both to contribute a faithful implementation. Either way, Forth and PostScript would be an interesting pairing, even though they look very different and are typically used in very different contexts. One thing they share in common is that they were originally designed to run on memory-constrained systems.
This is a great series and I love seeing the algorithm in different languages. I recommend that the oddball languages be clumped into "miscellaneous" episodes as necessary. Instead of comparing similarities, you can give a quick assessment of what each language is used for. The results won't be very relevant to one another, but it will still be interesting to see what speeds are typical for that language's particular job.
We should still try to associate languages with "similar" jobs or which run in similar environments, of course, but that may not always be possible and I would want to include 3 languages per episode when practical. Group up the obvious contenders and then start trying to clump the rest into "close-enough" associations.
I also suggest that groupings larger than 2-3 can be allowed by carrying results over from one episode into the next. A follow-up episode can refer back to the prior languages and simply continue on from where the prior one left off. This would create larger groups of 4-6 than span 2 episodes, but no more than that.
The intros get better every time!!! Thanks!
Thank you again, so much! Great video. I'm a release engineer and can do some Bash, and Perl, and the like, but I'm not a pro coder. Even though, this series is fascinating to watch.
Great to hear!
That ending. Of course you went there. Well done. Waiting Gerome in the next episode. Or possibly Hammy the Hamster cameo in the diving bell.
7:00 Fun bit o' trivia:
While everyone was wondering who shot J.R., scientists discovered that two of Saturn's' rings are woven together through forces unknown.
I learned that from Harlan Ellison, some time ago.
btw. the most expensive operation in the Perl implementation is actually initializing the 'bits' array. It takes about 30% of the overall runtime!
So using a more suitable bitarray class (of which there seem to be plenty on CPAN) should speed things up significantly.
Really hope someone has implemented it in Haskell, I'm trying to learn the language but it's fairly different and it hasn't been my top priority. Maybe this is the perfect scale or project to get me started!
That bless thing in Perl has be cracking up
Awesome series,Dave! I look forward to seeing you do some 6502 stuff even more. Throwing in some 65c816 would be the icing on the cake!
Just an idea for the future: Language "performance" in terms of productivity, readability, safety, and expressiveness. I think it would be be interesting to explore the maintainability of a project in some languages, its readability for newcomers to a project, their ability to help mitigate or even eliminate some classes of bugs, and the ability of just how quickly or easy it is to go from idea to code, even if it's just a proof of concept.
Just by that outro we know you're Canadian of a certain generation. Awesome!
Look up. Waaaaay up.
This ideia is good. But even with diferent compileres you will get diferent run time. For example Fortran code gives diferent run time with the choosen optimization in Intel Compile, Portland Compiler, GFortran, AMDcompiler, G95...etc
I just had to break out of jail for the last one. Now i need to find an assistant to hold my calls?
The fastest language is the one you know the best. Long ago I used to annoy my C professor by writing faster Fortran code.
I can't even imagine what a JCL Prime Sieve would look like. I've only ever used it to move/sort datasets and call Programs. If it's possible I'd love to see it!
Not to be too controversial here - I seriously doubt that it can be done in JCL (whether MVS or VSE version). They were really just a way to control the flow of programs as in "run the SORT program with these two files as input, using these parameters to control the sort (ascending, descending, type of data, etc) and putting the output in that file".
If anyone actually works out a way to do it, I will be seriously impressed, nay, flabbergasted.
We demand the Canadian Accent version of all your videos! Release the Canuck cut!
Perl's "unless" keyword is an interesting option, and in the right place (maybe 10% of conditionals in my experience) is actually very helpful for clarity. The problem is that (like most of the language) it suffers from over-application by enthusiastic programmers who just discovered it (nested cases, "unless" combined with not operators, etc...), and insufficient sober analysis about whether it actually improves code clarity in each case. Perl as a language gives you a huge footgun to write things incomprehensibly, but also allows for very clear and expressive solutions with some forethought.
I mostly work in Python these days, but one thing I really miss from Perl is its variable scoping rules. It's easy and straightforward to scope variables to the specific pieces of code you want, ensuring they're available exactly where needed without trampling on anything else. The other big thing I miss is Perl's use of regular expressions as a first-class citizen, baked right into the language. There's a way to use regular expressions in just about any language, but they're a powerful (and like perl itself, often abused) tool that takes a lot more boilerplate to leverage in just about anything other than Perl.
Indeed, Perl's RegEx support is out of this world - not only is it baked into Perl's syntax, it also goes way beyond regular "Extended Regular Expressions" (as GNU Grep likes to call what's usually meant by regexps). Even without rest of the Perl it's so powerful that GNU Grep has separate command line switches -E (for "Extended Regular Expressions") and -P (for "Perl Regular Expressions"), LOL - but the things you can do with it inside perl code...
Yet way too often I see regular expressions used in Perl code when they aren't needed, like where plain globs would be enough (and easier to write, faster to perform, etc.).
One other language I was originally gladly surprised to see getting regex support, also baked into it's syntax, was bash - but being baked into syntax doesn't mean it's necessarily that awesome... However the alternative is to call another tool that has regexp support, and depending what you need from it you'll have to use different commands - of course when I first tried it (and almost every time since), I was hit with the most common flaw of bash: unclear documentation. What I mean by that? Well, technically the documentation isn't ridden with errors, it's just that it's not telling you everything you need - like the part where when you have a conditional using = or !=, the right part can be used for glob pattern matching - what it leaves out is that if you have the glob pattern in variable and put the variable in quotes, it doesn't work. Actually it's not about using variable, I found this out when I was trying to do "if [[ ("$1" = "-*") && ("$1") != "--")]]; then..." and couldn't get it to work. You can say that glob matching does not work with quoted strings, but the man page didn't. It might mention it in another place, and obviously when you write "*" on command line it's not expanded to list of files, but pattern matching inside conditional expression isn't same as pattern expansion. Same kind of issues, but less obvious than that, is what I ran into with bash regexps - and while I've gotten it to work couple times, I usually don't even try, unless I have a good reason.
And bash has a lot of unexplained quirks like that. The biggest issue I have, and I admit I haven't checked the info documentation of bash that does have some things explained better or with examples that work, but the man page doesn't really tell you what regexp functionalities you can use, and I don't really like having to guess whether I need to escape something in some special way, etc. - it's a lot of trial and error, and bash has a number of things you just have to experience and find a way to make it work. I've been in a situation where I first implemented something on command line - a complex one-liner using fortune piped to cowsay with randomly selected .cow file to use - and when I got it to work I tried to use it inside a function. I never figured out that one, but it just didn't work. I wanted it in my .bashrc, but I wanted it as shell function I could also call manually anytime I wanted to, but somehow the same line inside a function spewed out some error I've since forgotten.
But most of the time I still love bash - but I'm really reluctant to try and use it's regexp functionality. I've never liked awk or sed, and if I were to call perl I feel I could just as well do the whole thing as perl script instead.
I don't know why I felt like making this rant - at first I just wanted to say that bash also has regexp support as part of it's syntax, but that it's not that good (or perhaps it would be if not for the lack of good decumentation), but it grew into large rant about bash documentation in general and in relation to regexp support.
Funny thing - I once found a fork of OG bourne shell and now always install it on every linux installation I do for myself; because I like to. But while it's much more limited and simpler to document, it's documentation is stellar in clarity when compared to bash. In fact it's so good, that even when making bash scripts if I need to refer the manual and if it's about something that works with bourne shell, I'll rather check it from bourne shell man page ;)
"At least I didn't do the videos in my original [Canadian] accent."
That's too bad! It would have been epic. I bet you really know what you're talking aboot.
I like your shirt! The drag racing is cool too!
I suggest a headless category, maybe something like 'GUI' or 'graphical' or simply 'not headless'. Some languages for all practical purposes either can't or don't ordinarily operate in a text based mode . For instance, LiveCode. It's possible to write the Sieve program in a LiveCode "headless" mode, but I doubt that more than 1 or 2 LiveCode programmers out of a 1,000 ever experience writing a headless program in LiveCode.
In the majority of commonly used languages, programmers have lots of experience writing programs in a text editor and running them in a 'console' or 'terminal', i.e. in headless mode. However, you can't do that in Scratch - which is higher on the TIOBE list than Rust, Ada, Julia, COBOL, Kotlin, Haskel, Lua, et. al. Going headless in the robotic programming language NXT-G is possible in a variety of headless languages, but I doubt that more than 1% of the Lego Mindstorms programs are headless. Likewise for LabVIEW. Your comparison of dozens of programming languages is woefully biased towards headless language programming.
How would you compare the sheer number of computer programs in use today by people throughout the world, which are headless vs. GUI? My guess is that the vast majority of people don't care to be presented with a console/terminal screen when they want to use a computer program. For that reason, I also doubt that most programmers are writing headless programs.
Not sure what is scariest, the welcoming chairs or the master wielding the chairs wearing rubber gloves.
Dave, great episode again - I wrote a comment specifically for you in the end considering your statement of the Perl program being a shell script; I'd love to hear whether you agree and if not, why. No offense meant, never to you - love your content
Scala and Swift are quite similar, so you could group them. However, Scala is a JVM language and Swift is LLVM. So that's quite different. I'm surprised nobody added a Kotlin version.
God I hate "to be continued" ...but this takes me all the way back to the big John and sparkie radio days, buck Rogers, and sky king...but please...don't wait till next Saturday to post the next one. Thanks...this is an example of how the world might be saved ...
Great stuff! Dave, your videos have always been AWESOME and they keep getting even funnier and better. You are the man! Absolutely loving the computer language wars series :-)
I appreciate that! Thanks for reaching out to let me know!
Did anyone stay to the end to see the Friendly Giant montage. You sir are truly a Canadian. I'm Sorry, Eh!
I did! :-)
For any compiled languages it would be interesting to compare different compilers with all possible and imaginary optimizations turned on.
I'm not really quite following here. We are comparing specific compilers / interpreters, no? Languages are just grammar, having nothing to do with speed or performance.
Thoughts on how the "official" scores will be calculated? Currently, all results are calculated within a docker container. Which while wonderful for compatibility, surely higher can be achieved by native running code.
The relative scores are what's important, not the absolute. The highest absolute scores, when I do need those, I get natively.
PHP8 has significant changes on the __construct behavior.
Thanks! It does seem like the language is always evolving quite aggressively, which can be hard to keep up with but is good! How far away is PHP8 from full release I wonder?
@@DavesGarageif by "full release" you mean ready to use ( not in alpha or beta version ) then it is in a full release.
Also in my tests if you enable php8 jit you can almost double the results
On xeon 2620v3 without jit: 114
With jit 201
Great improvement
And 114 was the same result that running with php7.4
You can run with jit enabled changing php.ini or with some args:
/usr/bin/php8.0 -dopcache.enable_cli=1 -dopcache.jit_buffer_size=100M -dopcache.jit=1255 -q PrimePHP.php
4:39 off to watch some Amanda McCants reruns. Ahahahaha that my friend made my day.
Me: I wonder if anyone's used the fact that all primes are of the form 6n±1 or any of the other equations you can get by using similar logic.
Dave: To be faithful, the only prime you're allowed to use is 2.
Me: Ah, so probably not. Makes sense, because without that restriction you could just hard bake the list in to the program and this would all be pointless.
I can easliy prove all primes have a multiple of 6N on one side or the other, but the converse isn't true, so it's not that helpful in finding primes. Rest assured when eliminating multiples of 3, my algorithm starts at 9 and walks by 6, which should eliminate all the 3N prime candidates as it goes. The evens are not present anyway so I think right after that pass you've got that info, but it's not enough to predict where primes WILL occur, just where they COULD occur.
19:31
It would be interesting to hear David's opinion on the usefulness of spending time on optimizing code and when not to. I am a tinkerer, the bad kind of perfectionism, so it is not for me. It took ages for others to make me stop wasting time and I see it around me in others, often the best and brightest.
If you instrument and measure, then you'll know what/where to optimize. You can guess, but always better to measure!
Dave this is great. I think your pithy rebuttal to the "assembler is fastest" argument was first-rate. I'm with you --- if someone is able to code the prime sieve (including I/O) directly in machine code, they deserve special recognition --- perhaps an all-expenses paid houseboat tour of Lake Wascana ??
Yes! You could take them and show them the old bandstand!
@7:14 "They don't tell you who shot JR in episode one" I'm soooooo stealing that. Just to see the confused looks on the millenials and the GenZ's. :)
As a millennial, I at least know what show it’s referencing-Little House on the Prairie-but not much besides that.
This media should reach more people. Be well Dave
I sure hope so! If folks share with other PROGRAMMERS that'd really help because it's such a narrow, nerdy interest!
PHP 7 is NOT the latest version, PHP 8 is. And it has JIT, which should translate to quite a big performance gain in comparison to 7. By the way, while the -r command line switch works, it might be easier to use -f and feed it a file with your code. Also, you can use PHP as a shell script too by adding #!/usr/bin/php on top and making it executable, just like perl.
It would be fun to see (and listen to an explanation of) array oriented languages like APL, K and J. Given that there are sometimes claims that K programs can be faster than hand optimized C, seeing how well it does here would be really interesting.
I recently ran into an issue where I could not efficiently express a simple function in 'C'. I needed to swap the top 16 bits with the lower 16 bits in a 32 bit variable. (audio codec/dma artifact) In arm assembly its simply 'ror r0,r0,#16', 1 cycle, a rotate that puts (bit31->bit0). In normal 'C' you only can use shifts, or load/store halfwords. Arm assembly also has bit manipulation functions, that would speed up you algo, but are probably not exploited by the compiler.
Try this: #define ROR(x,y) ((unsigned)(x) >> (y) | (unsigned)(x)
@@DavesGarage Ok, I tested it using gcc thumb2 instruction set, and you are right. I guess I am a bit biased by my day job that involves using custom instructions/mcu. Although ((unsigned)(x) >> (y) | (unsigned)(x)
I'd honestly love to see how TypeScript compiled and used with WebAssembly...
20:13 - oooh, is PCL Turing Complete? If so, it’s the obvious pairing for PostScript. 😁
If not, maybe PostScript and Logo?!? I mean, pretty different, but…
Thanks for your humour and humility, Dave. You're managing the sweaty geeks with class.
Still very cool video. Among the other languages I also learned JAVA, JAVA Script, HTML, and SQL.
How about something as obscure as Standard ML? The computer languages course I took at college involved that language.
It’s not very useful for writing applications, but was originally intended for mathematical proofs. This would be an interesting language to try.
Dave, pass me the cards that run the loom to make that shirt pattern. Love it
Thanks, Dave for this series. It is very interesting! :)
But there is one thing I would like to point out as loud as possible, but... well, this is as loud as it will ever get! :D
LANGUAGE SPEED DOES MATTER MORE THAN ONE THINKS!
Dave stated that: "[..] language is good as long as You get from it what You want without waiting on it to do its job [..]". It is subjectively a valid, yet globally broken logic that will (and actually invisibly is already) kicking our rear ends. Reality is displayed with PHP as an sad example. Most web pages in the world is running PHP back end that is written by many people that took their time to learn this specific language. Many poor in their time, energy and effort to make it better. Good job, but ... it is like reinventing the bike all over again. I am definitely NOT stating that PHP is bad. What I am saying that people all around the world is investing into worse performance-wise language than they should.
It matters when You take this exact comparison into account - speed - and combine it with scale! If task given is equal & HW is fixed, why language matters? Energy consumption. Electricity. We are talking hundreds of megawats per hour of electricity consumption difference in single country! If PHP is 4 to 8 times slower than (for example) C, C++ or any other language that can do the same job, it is economically unjustified to use slower language for big projects that are run countless times all over the world even if programmer salaries are taken into account. And big projects are the ones driving language development itself! So, reason that "one language is easier to use than other in given task" also becomes meaningless at the point where You still have to learn & develop a language itself.
It, unfortunately, looks like that most popular languages are the ones that lets You be sloppy the most. Not most efficient or fastest to write, but the ones that requires less attention, less care and makes someone or something else to cover up programmers laziness in some other means, like... lets just buy bigger server and burn twice as much energy to run this homepage...
I am not advocating for C or Assembly as "be all & end all" for everything! I am just saying that there has to be a point where programmers have to be able to put down their opinions about how good or bad language is, and realize, how big of an impact given system will have on global scale. Big impact & big scale? Reconsider the choice of language not for ease but for function.
Interesting metrics to look at for the final runtrhoguh
Code size relative to performance.
Perceived complexity relative to performance
And a huge performance comparison matrix comparing languages compiled for and run on Windows, Linux and macOS with different compilers where available, to let C not just be represented by GCC but also Clang, MSVC and other optimising compilers potentially
I pronounce SQL as “squall” because that's just how it looked to me when I first saw it. I can even see “squil” or “skwool”.
I also saw the word _array_ for the first time when I was really young in the Color BASIC book for the TRS-80 and pronounced it “AIR-ay”. Took me 20 years or so to not have to double-check what I was about to say before saying it out loud after hearing how it was really pronounced.
Never did understand where someone originally got “sequel” though
Keep it up, Dave! You can do it! You can overtake "Discount Bus Passes for War Widows" for that #1 spot on Github.
What version of PHP are you running this test in Dave? 8 would be more fair considering it’s the most up to date version, has JIT and the code could be simple with the new match syntax.
Some remarks/corrections:
15:46: On Unix-like systems, the shebang is NOT interpreted by the shell but by the execve (3) system call.
17:33: $self is NOT a language feature of perl but an ordinary variable. Choosing $self as variable name is a well known convention however. In line 30 of the code, the declaration and assignment of the variable can be seen.
Apart from that, awesome project!!
Cheers
-Fritz
Thanks! Fritz's comments look correct to me - that's the risk of talking about things I (admittedly) don't always understand!
Dave, your narrative could be published in a book, without editing, and still be captivating.
Dave, please ignore the useless, critical for the sake of being critical comments. I understand responding to reasonable criticism or comments but as the kids say, haters are gonna hate. Love your channel!
First off, I always tell people that the best language is the language THEY ENJOY programming with.
C is my personal favourite (not C++, but the latest GNU C). I have recently played with Python as it is used with various game engines (Ren'Py and Godot) and I have really been impressed with them, and I have never been one for such languages. But I love C mainly. I would like to see the latest C (not Visual Studio's C++ that compiles C, but the latest version of C which is supported by a GNU C compiler like MinGW for Windows).
Looking forward to part two of the Atomic Fire Lamp.
Not many people watched it by comparison! But I will try to do the coding episode on it soon!
@@DavesGarage Sweet, I’m just waiting on the actual lamp part to arrive so I can assemble mine. Can’t wait to see it working.
Me too! Lamp is built and running already but just with 4 arms parallel!
Speak of the devil, look what the postman just brought. Time to assemble!
Always a good day when there is a new Dave's Garage video is posted. :D
Enjoy! Thanks for the kind words!
Honestly not surprised about the perl result.
It's absolutely my go to language if I want to do something quickly under linux that I'll either use once, or isn't too intensive. It can do a lot of things way easier than other languages I think. SQL access (including prepared statements), excellent regex capability, good file read/write options and overall filesystem control, rest/json client easily implemented. If you just want to bring things together quickly it's excellent for that.
But, it's not fast. If I know I need speed I'll generally go for C# (via mono for linux). There's also the danger something you thought would be simple is started in perl and then becomes some monstrosity you wish you'd moved to something else long ago.
Newspapers published about this last year already? Such foresight.
That's because I read Canadian newspapers, which get the news a year in advance. Sorry to hear about Covid-22!
One suggestion is to group dynamic scripting languages together and do a video on that. For example, Python, Lua, Ruby, Javascript. Now most probably already know Python and JS so you can skip most of the explanations for them.
Other thing to note is whether you're running the script in a jit vs non-jit implementation. For example, if you're benchmarking javascript with node.js then it'll make sense to also bench python and lua with something like pypy and luajit respectively just to keep things fair.
This series is great!!