dottrap

8 miesięcy temudiscuss

Microsoft's timing was the worst. I think they announced this a year after Swift was already announced, but before Swift was open sourced. So Microsoft wouldn't be able to deal with things like Obj-C/Swift interop which iOS developers were already jumping onto. And Microsoft's Windows 8 mobile initiative was pretty clearly a flop by this point.

Frankly, this Obj-C effort needed to be done way earlier, starting with AppKit, like back when Microsoft was panicking that OS X 10.4 Tiger was going to kick Longhorn's butt. If these tools had already been proven useful before the dawn of the iPhone, Microsoft might have had a chance of riding the iOS wave.

dottrap

w zeszłym rokudiscuss

Main changes (since 5.4)

  declarations for global variables
  for-loop variables are read only
  floats are printed in decimal with enough digits to be read back correctly.
  more levels for constructors
  table.create
  utf8.offset returns also final position of character
  external strings (that use memory not managed by Lua)
  new functions luaL_openselectedlibs and luaL_makeseed
  major collections done incrementally
  more compact arrays (large arrays use about 60% less memory)
  lua.c loads 'readline' dynamically
  static (fixed) binaries (when loading a binary chunk in memory, Lua can reuse its original memory in some of the internal structures)
  dump and undump reuse all strings
  auxiliary buffer reuses buffer when it creates final string

dottrap

w zeszłym rokudiscuss

One of Lua's goals has been extreme portability, and the main implementation works on anything that has a C compiler, going to the extreme of compiling cleanly on C89, C99, and even compiling as C++ (no extern "C"). Remember that Lua is popular in the embedded space too, so this is a big feature.

Pallene isn't designed to be a new native language on its own. Pallene is designed to be a companion language for Lua, specializing in a subset of performance.

But as importantly, Pallene isn't just compiling to C. Pallene is generating C code that directly manipulates the underlying Lua internals, which are in C.

The research thesis is that many bottlenecks are due to boxing and unboxing going through an FFI. Memory safety also incurs overhead. Python is an extreme example of how excruciatingly slow this can be, but even Lua incurs costs for this. A core tenant of the Pallene compiler is that it can generate C code that gets to cheat like crazy. Pallene gets to directly access Lua internals and things like arrays directly manipulate underlying C arrays deep inside, which sidesteps boxing/unboxing. The compiler can do the analysis to make sure it doesn't cheat in a way that is unsafe. Finally, the C optimizer now also has a chance to perform optimizations. And now operations such as crunching math on arrays of numbers may get much faster because now you get generated code that is more CPU friendly and may benefit more from prefetching and cache locality.

Pallene is built from the the extreme compatibility goals as Lua since it is designed to work with it. It it only depends on any C compiler and Lua itself. If you get Lua compiled, then you can get Pallene working. That means any existing project that uses Lua (5.4) could start adding Pallene modules to their project for new features or to try to improve performance in key areas. Since Pallene just outputs a Lua modules, it looks like any other Lua module implemented in C, so it won't create new portability constraints that you didn't have before. This is different than say LuaJIT, where not all platforms may allow JIT or you may be targeting a new CPU architecture that LuaJIT does not support.

Both Teal and Pallene were started by grad students of Roberto's. Since Roberto has started giving talks himself on Pallene, I'm assuming they are joining in.

dottrap

w zeszłym rokudiscuss

>> I really wish the Lua authors would add official types to Lua.

> Never going to happen IMO. Adding static types would change the nature of the language completely, even more than it has in Python.

You both are kind of right.

The Lua authors have been working on the new companion language to Lua named Pallene. Pallene is a subset of Lua that adds types, not for the sake of types themselves, but for the purpose of performance. The Pallene compiler can generate optimized native code that potentially removes the need to manually write a module for Lua in C.

The other cool trick is that Pallene and Lua are completely interoperable with each other, so Pallene can be added to existing Lua projects, and you can opt to use regular Lua for the dynamic parts of your code where compilers won't be able to optimize much and strong types might be more trouble than help.

Here is a talk Roberto Ierusalimschy gave about Pallene. https://www.youtube.com/watch?v=pGF2UFG7n6Y

dottrap

2 lata temudiscuss

This should be plenty fast. SDL_RenderCopy generally should be doing things the 'right' way for on any video card made roughly in the last 15ish years (basically binding a texture in GPU RAM to a quad).

You probably need to due some debugging/profiling to find where your problem is. Make sure you aren't creating SDL_Textures (or loading SDL_Surfaces) inside your main game play loop. You also may want to check what backend the SDL_Renderer is utilizing (e.g. OpenGL, Direct3D, Vulkan, Metal, software). If you are on software, that is likely your problem. Try forcing it to something hardware accelerated.

Also, I vaguely recall there was a legacy flag on SDL_Surfaces called "hardware" or "SDL_HWSURFACE" or "SDL_HWACCEL" or something. Don't set that. It was a a very legacy hardware from like 25 years ago that is slow on everything now.

dottrap

2 lata temudiscuss

I was referencing the historical motivations that led to where we are today. Yes, I was referring in part to the SDL_Render family APIs. These were insufficient to support things like Nuklear and Dear ImGui, which are reasonable use cases for a simple 2D game, which SDL hoped to help with by introducing the SDL_Render APIs in SDL 2.0 in the first place.

https://www.patreon.com/posts/58563886

Short excerpt:

    One day, a valid argument was made that basic 2D triangles are pretty powerful in themselves for not much more code, and it notably makes wiring the excellent Dear Imgui library to an SDL app nice and clean. Even here I was ready to push back but the always-amazing Sylvain Becker showed up not just with a full implementation but also with the software rendering additions and I could fight no longer. In it went.

The next logical thing people were already clamoring for back then was shader support. Basically, if you can provide both batching (i.e. triangles) and shaders, you can cover a surprising amount of use cases, including many beyond 2D.

So fast forwarding to today, you're right. Glancing at the commit, the GPU API has 80 functions. It is full-featured beyond its original 2D roots. I haven't followed the development enough to know where they are drawing the lines now, like would raytracing and mesh shaders be on their roadmap, or would those be a bridge too far.

dottrap

2 lata temudiscuss

This is a separate thing with the same name. Although both share some common ideas. The grimfang4/sdl-gpu is a separate library used with SDL, while the new SDL GPU API is directly part of SDL. grimfang4/sdl-gpu is much older and works with today's SDL 2.

The grimfang4/sdl-gpu was one good way to take advantage of modern GPUs in a simple way and workaround the holes/limitations of the old SDL 2D API. The new SDL 3 GPU API will likely make the need for things like grimfang4/sdl-gpu redundant.

dottrap

2 lata temudiscuss

The old SDL 2D API was not powerful enough. It was conceived in the rectangle sprite blitting days, when video hardware was designed very differently and had drastically different performance characteristics. If you wanted anything more, OpenGL used to be 'the best practice'. But today, the landscape competes between Vulkan, Metal, and Direct3D, and hardware is centered around batching and shaders. Trying to target OpenGL is more difficult because OpenGL fragmented between GL vs. GLES and platform support for OpenGL varies (e.g. Apple stopped updating GL after 4.1).

A good example demonstrating where the old SDL 2D API is too limited is with the 2D immediate mode GUI library, Nuklear. It has a few simple API stubs to fill in so it can be adapted to work with any graphics system. But for performance, it wants to batch submit all the vertices (triangle strip). But SDL's old API didn't support anything like that.

The reluctance was the SDL maintainers didn't want to create a monster and couldn't decide where to draw the line, so the line was held at the old 2D API. Then a few years ago, a user successfully changed the maintainers' minds after writing a demonstration showing how much could be achieved by just adding a simple batching API to SDL 2D. So that shifted the mindset and led to this current effort. I have not closely followed the development, but I think it still aims to be a simple API, and you will still be encouraged to pick a full blown 3D API if you go beyond 2D needs. But you no longer should need to go to one of the other APIs to do 2D things in modern ways on modern hardware.

dottrap

2 lata temudiscuss

Where did you see that? I'm skeptical of that claim because I know some embedded uses of Lua strongly utilize pre-compiling to Lua bytecode so they can keep their hardware as slim as possible. I know some will even strip out the Lua compiler from the binary they ship to shrink the profile even more. Also, many video games like to pre-compile their shipped Lua scripts to reduce their load times.

I know that the Lua team has internal private repositories, and that luac is developed in a separate repo for them. I've seen occasional reports on the Lua mailing list that luac.c is forgotten or not updated in non-official releases. That is because those source drops didn't go through the full official release process which includes merging in from their luac repo. Maybe you are confusing these intermediate source drops with deprecation? If there is deprecation, I would like to see the details on that. I presume they would be introducing some kind of replacement that addresses all the real world use cases that rely on the abilities of pre-compiling to Lua bytecode.

dottrap

2 lata temudiscuss

As another extremely simple idea, in my personal experience, just using regular Lua table syntax for serialization and then pre-compiling it with luac so it could be loaded quickly via dofile(), produced results just as fast for loading it in as using lua-protobuf. (I don't remember the difference between writing out Lua tables vs. lua-protobuf because my use case needed to read the data more often than generate it, but it must have not been big enough, if any, otherwise I would probably remember it.) I was loading gigabytes of data for large batch processing.

dottrap

3 lata temudiscuss

> IMHO there wasn’t any reason to bother fiddling with the definition of BOOL.

There were good reasons to change this to a real boolean. I think it was a WWDC, where kind of discussing this topic, one Apple engineer said they did an audit of production Obj-C code and found multiple instances where their BOOL values were values other than 0 or 1 (which was considered surprising and ultimately bugs).

This can lead to all sorts of subtle problems. One common one encountered by framework users is where something returns a BOOL and the user explicitly compared against == YES or == NO. If the value is say 2, then this code usually results in wrong decision.

dottrap

3 lata temudiscuss

As a historical note, this was also a thorny issue for language bridges to Objective-C, going beyond just Obj-C++. I'm thinking of bridges like PyObjC, RubyCocoa, CamelBones, and LuaCocoa.

BOOL was one of those things that would have been really nice to be a real bool because when bridging to other languages that had a real boolean type, the idioms could be completely natural when writing in the bridged language. But since BOOL was a 'signed char', using only the Obj-C runtime introspection, this by default would typically bridge to something weird like an integer.

In Mac OS X 10.5, Apple officially supported PyObjC and RubyCocoa, and introduced "BridgeSupport" which provided additional metadata and dylibs containing symbols for inline functions, so any language could create a full bridge to Cocoa. The metadata could be used to interpret if a 'signed char' could actually be used as a boolean or not. But BridgeSupport was not available for 3rd party APIs (unless the authors decided to support it, which was almost never).

There were bug requests filed for Apple to properly redefine BOOL to a real boolean for the 64-bit Mac ABI, before Apple had finalized it, but Apple didn't fix this in time. My memory is hazy, but I think when the iPhone ABI came around, they didn't have time to address this. So it would be another full arch ABI before there would be a chance to address this again.

dottrap

3 lata temudiscuss

I saw a few presentations from the 280 North guys. It was clearly impressive what these 3 guys built. Learning from Cocoa/Objective-C/Interface Builder well, they realized they needed to build 3 separate, but interconnected things, the framework (Cappuccino), the language (Objective-J), and the GUI builder (Atlas).

They sold to Motorola for $20 million in 2010, and that was the kind of the last I heard.

https://news.ycombinator.com/item?id=1631002

dottrap

3 lata temudiscuss

The food, including Cajun & Creole, crawfish, The French Quarter, Mardi Gras, voodoo, bayous, the music (birthplace of jazz), Louis Armstrong, Fats Domino, Jerry Lee Lewis, salt domes/caverns (which is why much of the US Strategic Petroleum Reserve is located there), the template for haunted mansions and graveyards.

Happy Turducken Day :)

dottrap

7 lat temudiscuss

And as another example, Mac OS X (10), which debuted in 2000, has had every subsequent version continued to be named 10.X. Just this week, macOS 10.15 Catalina was released.

Funny that the name Mac OS X went to OS X and then (back) to macOS, but the 10.X name persists.

Submissions

Lua 5.5.0 (rc1) has been released for testing

Lua 5.5.0 (Beta) Released

comments