Here I compared the effect of different compiler optimizations in both Fortran and C for a program that multiplies a matrix with a vector. The results are below.
| Options | C (loop) | Fortran (intrinsic) | Fortran (loop) |
|---|---|---|---|
| 828 ms | 104 ms | 835 ms | |
| -Ofast | 110 ms | 112 ms | 110 ms |
| -O3 | 362 ms | 361 ms | 363 ms |
| -O3 -march=native | 362 ms | 363 ms | 361 ms |
| -O3 -march=native -ffast-math -funroll-loops | 90.3 ms | 92.8 ms | 89.5 ms |
| -O3 -march=native -ffast-math -funroll-loops -fopenmp | 85.2 ms | 91.2 ms | 86.4 ms |
##tempering expectations for generative AI
Originally posted here: https://www.linkedin.com/pulse/tempering-expectations-generative-ai-andrew-marble/
There's a software development concept called low code programming - idea is that you could automate away lots of the boilerplate for common coding tasks, so as to minimize the code written, often by drawing a picture or writing some other kind of specification instead. Turns out it works great for about 95% of the programming tasks you'd want to do, but makes the other 5% more complex or impossible because it doesn't fit nicely in the low-code template so you need to hack around it. And unfortunately, this 5% is present in pretty much every real software project, and is what takes all the work. That's why despite the time that's passed since the first low code tool was developed (it was called COBOL) most software is still written in fully featured programming languages, and low code is only used in niche areas. Enter the new "low code" revolution. There's be
The following assembly code counter.asm counts to 10^9, using a linux system call to print:
section .data
count dd 0 ; Define a 32-bit integer for the count
section .text
global _start
_start:| program pretokenize | |
| character(:), allocatable :: result, orig | |
| character(:), dimension(:), allocatable :: c_encoding | |
| integer :: j | |
| c_encoding = make_encoding() | |
| result = pre_tokenize('Andy99아마') |